On 11/23/2010 02:15 PM, Endi Sukma Dewata wrote:
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.
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
contrast this with
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.
For now, and through this release, we will only have one layout, what
you are calling ipa_page.
Freeipa-devel mailing list