[Freeipa-devel] [PATCH] 0100-top-nav-index

Adam Young ayoung at redhat.com
Tue Nov 23 19:57:47 UTC 2010


On 11/23/2010 02:15 PM, Endi Sukma Dewata wrote:
> On 11/22/2010 10:41 AM, Adam Young wrote:
>> Without reordering things now, I propose we allow for a three level
>> structure in the tab_set. Top level will not be an entity. Second level
>> will be an entity. third level will be a nested entity.
>
>> Nested entities are not related in any way to the entity that they are
>> nested under except by convention. Thus, sudocmd and sudocmdgrps may get
>> nested under sudorules, but they could easily be placed as peers.
>> Contrast these with DNS records, that require the the DNS Zone value.
>
>> For 3 level deep nesting, we will need a naming scheme to make these
>> work. something like
>> #subtab=sudorule&entity=sudocmd
>>
>> contrast this with
>>
>> #entity=sudorule
>>
>> Thus, the entity value always points to the object, not necessarily at
>> the leaf node of the navigation tree.
>
> I agree that the navigation should be decoupled from entity make it 
> more flexible. This is a more detailed proposal, I don't know if we 
> can fully implement this within the schedule, but at least we can go 
> toward this direction.
>
> Currently the navigation tree always points to entities. This should 
> be replaced by pages (you're calling it subtab). We can pick another 
> name if this is confusing, but for now let's use these terms: the 
> first level tabs are sections, the second level tabs are pages.
>
> A page defines anything you see below the tabs, including client area 
> and action panel. Each page can have one entity (e.g. users), multiple 
> entities (e.g. hbac), or special cases (e.g. krbtpolicy, config).
>
> We can have a base class (e.g. ipa_page) that defines the basic layout 
> where the UI components are located (e.g. the action panel, client 
> area, title, buttons), this way all pages will be consistent. Then we 
> can create subclasses that will customize each component depending on 
> the entity, facet, or entry being selected. Each page is responsible 
> to read the parameters it needs from the URL.
>
> We might also need a tree-like navigation for the action panel, but 
> that's for another discussion.
>
If I understand this correctly, it is pretty much in line what I am 
thinking.  For a first round, and to get this patch submitted, I think I 
am going to add entires to the tab set under HBAC and sudo that will be 
used for navigating to those entities, even though it won't be used for 
populating the action panel.  The action panel work can follow on.

For now, and through this release, we will only have one layout, what 
you are calling ipa_page.






More information about the Freeipa-devel mailing list