[Freeipa-devel] [PATCH] 0227-2-automount-UI

[Adam Young]

On 05/25/2011 12:28 AM, Endi Sukma Dewata wrote:
> On 5/24/2011 5:32 PM, Adam Young wrote:
>> On 05/24/2011 05:06 PM, Endi Sukma Dewata wrote:
>>> On 5/24/2011 1:11 PM, Adam Young wrote:
>>>> Known issues: the back to list links are broken. Add and delete for 
>>>> keys
>>>> not working due to API issues discussed elsewhere.
>
>>> 1. The 3rd level tabs (Location, Maps, Keys) can be removed because
>>> there's already a breadcrumb which provides the functionality needed.
>>> It's not possible to go to a map or key directly without selecting a
>>> location, so having a tab for Maps or Keys doesn't quite make sense.
>
>> Tabs are necessary for navigation. IN the future, we can add nested
>> settings and deeply nested search facets that should allow us to
>> navigate on down, but that is a lot more work.
>
> I think the breadcrumb is sufficient for navigation, but I'll leave the
> final decision to UXD. Would it be difficult to remove the 3rd level
> tabs if we decide not to use it? Or is this tied to the nested entity
> definition?

Yes, I agree  the breadcrumb it sufficient.  This is a case of the 
navigation tag being tied I to one with entity.  This made sense for all 
of the other entities, but not automount.  I think we open a ticket for 
doing  "nested settings"  or even a generic "nested facet"  approach, 
and if we get to it in Sprint 2, do it then.

>
>>> 2. The prefix in the page title keeps changing which forces you to
>>> re-read the title to make sure you're in the right page.
>>> - Automount Location:BOS
>>> - Automount Maps:BOS > auto.direct
>>> - Automount Keys:BOS > auto.direct > nfsserver:/var/log/dirsrv
>>> /var/log/dirsrv
>>>
>>> This can be simplified by removing the entity name:
>>> - Automount: BOS
>>> - Automount: BOS > auto.direct
>>> - Automount: BOS > auto.direct > nfsserver:/var/log/dirsrv
>>> /var/log/dirsrv
>>>
>>> This way it will look more like a breadcrumb and be less confusing.
>>> The "Automount" itself could be made a link to go to locations.
>>
>> Agreed, but for now, the only way to make that happen is to modify the
>> lable fields for location, keys, and maps. That will mess things up
>> elsewhere. Alternative is a lot of messy one-off code.
>
> One way to do this cleanly is to explicitly specify the 'Automount'
> label in the factory and store it as a member variable in the entity,
> then modify the entity_header to use this variable in the page title
> instead of taking the entity label directly from metadata.
OK, I can do that.

>
> 7. The automount key in the breadcrumb is capitalized. Since the key
>    contains a Unix path it should preserve the case.
Ah..this is a transform in the style sheet.  Yeah, we can drop that 
transform.  I'm guessing this isn't the only place it will mess things up.

>
> 8. The column in the maps search facet doesn't have a title.
>
> 9. The keys search facet only has one column: description. It would be
>    better to use key and mount information since those are the fields
>    that you entered during add.
Yeah, but right now the description field has both of those others 
encapsulated in it, and is the primary key.

>
> 10. The code assumes that the primary keys will be specified as command
>     arguments, which we know doesn't match the API for automount keys.
>     Suppose we decide not to change the API, there should be a way to
>     invoke the current API without writing one-off code in the common
>     code. I think this can be done by defining a generic finder method
>     for all entities, then override this method in the subclass for
>     automount keys. What do you think?
>