status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
consul/ui-v2/app/templates/dc/intentions/index.hbs

85 lines
3.8 KiB
Handlebars
Raw Normal View History

WIP: First draft intentions 1. Listing, filtering by action and searching by source name and destination name 2. Edit/Create page, edits ping the API double fine, need to work through creates and deletes 3. Currently uses a `Precedence` intention keyname that doesn't yet exist in the real API
2018-05-22 15:03:45 +00:00
{{#app-view class="intention list"}}
UI: Simplify/refactor the actions/notification layer (#4572) + (#4573) * Move notification texts to a slightly different layer (#4572) * Further Simplify/refactor the actions/notification layer (#4573) 1. Move the 'with-feedback' actions to a 'with-blocking-action' mixin which better describes what it does 2. Additional set of unit tests almost over the entire layer to prove things work/add confidence for further changes The multiple 'with-action' mixins used for every 'index/edit' combo are now reduced down to only contain the functionality related to their specific routes, i.e. where to redirect. The actual functionality to block and carry out the action and then notify are 'almost' split out so that their respective classes/objects do one thing and one thing 'well'. Mixins are chosen for the moment as the decoration approach used by mixins feels better than multiple levels of inheritence, but I would like to take this fuether in the future to a 'compositional' based approach. There is still possible further work to be done here, but I'm a lot happier now this is reduced down into separate parts.
2018-08-29 18:14:31 +00:00
{{#block-slot 'notification' as |status type|}}
{{partial 'dc/intentions/notifications'}}
{{/block-slot}}
WIP: First draft intentions 1. Listing, filtering by action and searching by source name and destination name 2. Edit/Create page, edits ping the API double fine, need to work through creates and deletes 3. Currently uses a `Precedence` intention keyname that doesn't yet exist in the real API
2018-05-22 15:03:45 +00:00
{{#block-slot 'header'}}
<h1>
Intentions
</h1>
UI: CSS Additions (mainly %frames) (#4623) * Move almost everything to use %frames * Fix pill styles of ACL types * Remove horizontal scrollbars from dom recycling scroller component * Make text areas look ok in Firefox * Remove ember-bulma-css * New form elements, break out %toggle * %button design tweaks * %form-element design tweaks * Better hashicorp logo * Small screen CSS improvements (#4624) 1. Reduce header size when there are no breadcrumbs 2. Make the filters toggleable, closed by default 3. Reduce the size of the footer on small screens 4. Hide all non-primary columns for forms 5. Slightly change the layout of various items, mainly buttons within forms 6. Make some confirmation dialogs work vertically on small screens. Guessing we might be better just using native confirmations on small screens
2018-09-21 09:18:32 +00:00
<label for="toolbar-toggle"></label>
WIP: First draft intentions 1. Listing, filtering by action and searching by source name and destination name 2. Edit/Create page, edits ping the API double fine, need to work through creates and deletes 3. Currently uses a `Precedence` intention keyname that doesn't yet exist in the real API
2018-05-22 15:03:45 +00:00
{{/block-slot}}
{{#block-slot 'actions'}}
Add some navigation testing for back buttons and create buttons
2018-07-04 16:23:33 +00:00
<a data-test-create href="{{href-to 'dc.intentions.create'}}" class="type-create">Create</a>
WIP: First draft intentions 1. Listing, filtering by action and searching by source name and destination name 2. Edit/Create page, edits ping the API double fine, need to work through creates and deletes 3. Currently uses a `Precedence` intention keyname that doesn't yet exist in the real API
2018-05-22 15:03:45 +00:00
{{/block-slot}}
{{#block-slot 'toolbar'}}
{{#if (gt items.length 0) }}
ui: Async Search (#4859) This does several things to make improving the search experience easier moving forwards: 1. Separate searching off from filtering. 'Searching' can be thought of as specifically 'text searching' whilst filtering is more of a boolean/flag search. 2. Decouple the actual searching functionality to almost pure, isolated / unit testable units and unit test. (I still import embers get which, once I upgrade to 3.5, I shouldn't need) 3. Searching rules are now configurable from the outside, i.e. not wrapped in Controllers or Components. 4. General searching itself now can use an asynchronous approach based on events. This prepares for future possibilities of handing off the searching to a web worker or elsewhere, which should aid in large scale searching and prepares the way for other searching methods. 5. Adds the possibility of have multiple searches in one template/route/page. Additionally, this adds a WithSearching mixin to aid linking the searching to ember in an ember-like way in a single place. Plus a WithListeners mixin to aid with cleaning up of event listeners on Controller/Component destruction. Post-initial work I slightly changed the API of create listeners: Returning the handler from a `remover` means you can re-add it again if you want to, this avoids having to save a reference to the handler elsewhere to do the same. The `remove` method itself now returns an array of handlers, again you might want to use these again or something, and its also more useful then just returning an empty array. The more I look at this the more I doubt that you'll ever use `remove` to remove individual handlers, you may aswell just use the `remover` returned from add. I've added some comments to reflect this, but they'll likely be removed once I'm absolutely sure of this. I also added some comments for WithSearching to explain possible further work re: moving `searchParams` so it can be `hung` off the controller object
2018-11-06 09:10:20 +00:00
{{intention-filter searchable=searchable filters=actionFilters search=filters.s type=filters.action onchange=(action 'filter')}}
WIP: First draft intentions 1. Listing, filtering by action and searching by source name and destination name 2. Edit/Create page, edits ping the API double fine, need to work through creates and deletes 3. Currently uses a `Precedence` intention keyname that doesn't yet exist in the real API
2018-05-22 15:03:45 +00:00
{{/if}}
{{/block-slot}}
{{#block-slot 'content'}}
ui: Async Search (#4859) This does several things to make improving the search experience easier moving forwards: 1. Separate searching off from filtering. 'Searching' can be thought of as specifically 'text searching' whilst filtering is more of a boolean/flag search. 2. Decouple the actual searching functionality to almost pure, isolated / unit testable units and unit test. (I still import embers get which, once I upgrade to 3.5, I shouldn't need) 3. Searching rules are now configurable from the outside, i.e. not wrapped in Controllers or Components. 4. General searching itself now can use an asynchronous approach based on events. This prepares for future possibilities of handing off the searching to a web worker or elsewhere, which should aid in large scale searching and prepares the way for other searching methods. 5. Adds the possibility of have multiple searches in one template/route/page. Additionally, this adds a WithSearching mixin to aid linking the searching to ember in an ember-like way in a single place. Plus a WithListeners mixin to aid with cleaning up of event listeners on Controller/Component destruction. Post-initial work I slightly changed the API of create listeners: Returning the handler from a `remover` means you can re-add it again if you want to, this avoids having to save a reference to the handler elsewhere to do the same. The `remove` method itself now returns an array of handlers, again you might want to use these again or something, and its also more useful then just returning an empty array. The more I look at this the more I doubt that you'll ever use `remove` to remove individual handlers, you may aswell just use the `remover` returned from add. I've added some comments to reflect this, but they'll likely be removed once I'm absolutely sure of this. I also added some comments for WithSearching to explain possible further work re: moving `searchParams` so it can be `hung` off the controller object
2018-11-06 09:10:20 +00:00
{{#changeable-set dispatcher=searchable}}
{{#block-slot 'set' as |filtered|}}
{{#tabular-collection
route='dc.intentions.edit'
key='SourceName'
items=filtered as |item index|
}}
{{#block-slot 'header'}}
<th>Source</th>
<th>&nbsp;</th>
<th>Destination</th>
<th>Precedence</th>
{{/block-slot}}
{{#block-slot 'row'}}
<td class="source" data-test-intention="{{item.ID}}">
<a href={{href-to 'dc.intentions.edit' item.ID}} data-test-intention-source="{{item.SourceName}}">
{{#if (eq item.SourceName '*') }}
All Services (*)
{{else}}
{{item.SourceName}}
{{/if}}
</a>
</td>
<td class="intent-{{item.Action}}" data-test-intention-action="{{item.Action}}">
<strong>{{item.Action}}</strong>
</td>
<td class="destination" data-test-intention-destination="{{item.DestinationName}}">
{{#if (eq item.DestinationName '*') }}
All Services (*)
{{else}}
{{item.DestinationName}}
{{/if}}
</td>
<td class="precedence">
{{item.Precedence}}
</td>
{{/block-slot}}
{{#block-slot 'actions' as |index change checked|}}
{{#confirmation-dialog confirming=false index=index message='Are you sure you want to delete this intention?'}}
{{#block-slot 'action' as |confirm|}}
{{#action-group index=index onchange=(action change) checked=(if (eq checked index) 'checked')}}
<ul>
<li>
<a href={{href-to 'dc.intentions.edit' item.ID}}>Edit</a>
</li>
<li>
UI: Use buttons instead of anchors where appropriate (#4939) Use buttons instead of anchors where appropriate
2018-11-19 14:57:22 +00:00
<button type="button" class="type-delete" data-test-delete {{action confirm 'delete' item}}>Delete</button>
ui: Async Search (#4859) This does several things to make improving the search experience easier moving forwards: 1. Separate searching off from filtering. 'Searching' can be thought of as specifically 'text searching' whilst filtering is more of a boolean/flag search. 2. Decouple the actual searching functionality to almost pure, isolated / unit testable units and unit test. (I still import embers get which, once I upgrade to 3.5, I shouldn't need) 3. Searching rules are now configurable from the outside, i.e. not wrapped in Controllers or Components. 4. General searching itself now can use an asynchronous approach based on events. This prepares for future possibilities of handing off the searching to a web worker or elsewhere, which should aid in large scale searching and prepares the way for other searching methods. 5. Adds the possibility of have multiple searches in one template/route/page. Additionally, this adds a WithSearching mixin to aid linking the searching to ember in an ember-like way in a single place. Plus a WithListeners mixin to aid with cleaning up of event listeners on Controller/Component destruction. Post-initial work I slightly changed the API of create listeners: Returning the handler from a `remover` means you can re-add it again if you want to, this avoids having to save a reference to the handler elsewhere to do the same. The `remove` method itself now returns an array of handlers, again you might want to use these again or something, and its also more useful then just returning an empty array. The more I look at this the more I doubt that you'll ever use `remove` to remove individual handlers, you may aswell just use the `remover` returned from add. I've added some comments to reflect this, but they'll likely be removed once I'm absolutely sure of this. I also added some comments for WithSearching to explain possible further work re: moving `searchParams` so it can be `hung` off the controller object
2018-11-06 09:10:20 +00:00
</li>
</ul>
{{/action-group}}
{{/block-slot}}
{{#block-slot 'dialog' as |execute cancel message|}}
{{delete-confirmation message=message execute=execute cancel=cancel}}
{{/block-slot}}
{{/confirmation-dialog}}
{{/block-slot}}
{{/tabular-collection}}
{{/block-slot}}
{{#block-slot 'empty'}}
<p>
There are no intentions.
</p>
{{/block-slot}}
{{/changeable-set}}
WIP: First draft intentions 1. Listing, filtering by action and searching by source name and destination name 2. Edit/Create page, edits ping the API double fine, need to work through creates and deletes 3. Currently uses a `Precedence` intention keyname that doesn't yet exist in the real API
2018-05-22 15:03:45 +00:00
{{/block-slot}}
{{/app-view}}