On 4/20/2011 11:50 AM, Adam Young wrote:
Leave the factories as the top level object. For the factory name, say
'entitle' check that the object is in the metadata. If not, don't create
the entity. Then, when processing the tabs, if the entity does not
exist, drop the tab from the tab set. The explicit enumeration of
entities in webui.js is not necessary, nor is putting every entity's
factory into its own namespace.
I think it would be even better to create only the entities that are
actually needed. So entity creation should be done after we determine
the user and the tab set for that user. What do you think?
Absolutely. I think that the check should be something like:
that.start_entities = function(){
...
for (name in that.entity_factories){
if (!metadata.objects[name]) continue;
...
}
and then the tab gets dropped later if the entity doesn't exist.
I don't think this approach will work for DNS. If dns_is_enabled is
false the entity should not be created either. I'm not sure inserting
this logic in the IPA.start_entities() would be a good idea. The
start_entities() should read from a list of entities to be created
instead of filtering out the entities within the loop.
Creating a namespace for each entity is actually a separate but
related issue. It's mainly needed to avoid conflicts and we have done
that for certificates and entitlements. Sooner or later we'll create
name space for other entities anyway.
"You don't need it now" lets avoid introducing it for as long as
possible. The namespaces are not likely to be needed for most entities.
They are really the exception, not the rule.
The navigation is using a namespace too. It's not a rule, but more like
planning ahead rather than reactively fixing it when we encounter the
first problem. This is important since JavaScript will not alert us when
there's a conflict. User, Host, Service, DNS, HBAC, Sudo, ACI and
Widgets are strong candidates because they have a set of related
classes. This is similar to Python modules vs. C-style prefixes. We do
have the IPA namespace, but right now it's still mostly flat without
additional organization.
--
Endi S. Dewata
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
