[Freeipa-devel] Custom Facets and Views

[Adam Young]

I have a proof of concept working for DNS records.  It has lead me to 
think about how we are going to deal with the UI components that we are 
currently calling facets, what the proper nomenclature should be, and 
how we are going to manage them moving forward.

Thus far, we have a few basic UI elements that probably best deserve the 
name 'views'.  These are: search, details, and associations.  I say view 
to distinguish them from facets, which we've not strictly defined, but 
seem to be our way of talking about Entities.  We've seemed to come to 
the conclusion that 'search' is not a 'facet'.

For DNS Records, I've developed a view that is fairly similar to the 
standard search view, but has enough differences that I've done it in a 
separate set of functions.  They started off as cut-and-past from 
search.js and add.js, but have morphed significantly from the origins 
that merging them back in would require significant  changes to the 
originals.  The differences are primarily based on the one-off nature of 
the DNS plug-in.  Since we are discussing a redo of that plug-in, I am 
reluctant to make changes to the core files that may go away again quickly.

This leads to two discussions.  First is how to make the core 
abstractions we have flexible enough to handle variations in the 
entities.  Second is and how to handle the assignment of views to an 
entity.   For the first part, we've already seen some of this with 
things like the callbacks for custom details/attributes.  The places 
that DNS records require customization is: always requiring the ZONE for 
other calls, specific fields for search, a small enough set of detail 
attributes that there is no reason to separate out the add and edit 
pages, and the inability to delete more than one Record at a time, 
leading to the method chaining that we see in the Serial Associator.

As an aside, I noticed that we could perhaps simplify things in the 
delete case by calling all of the delete ipa_cmds in a loop.  We then 
merely need to keep track of the number of responses we get.  Once there 
are zero outstanding responses, we can refresh the original search and 
close the modal. This will work, but leads to questions about the 
thjreading model in Javascript.  Basically, if there is no atomic 
decrement, and the callbacks can be interrupted, we have the potential 
for never reaching Zero, and hanging in the modal.

As for the assignment of views to an entity, I think we should create an 
abstraction, which for now I will call view.  I am open to better 
suggestions.  A given entity will have a series of views assigned to 
it.  This will be used to handle the facets list generations for the top 
navigation and the quick links.  By default, an entity will have search, 
details, and associations.  Certain entities will not have search or 
associations.  So far these are: Server Configuration and Kerberos 
Ticket policy.

To control this, we will need a top level abstraction.  Right now, each 
of the facet types have their own objects, which are basically 
dictionaries from entity name to the initialization information for each 
of the view.  For example, to add search, we call 
ipa_entity_set_search_definition, and pass in an array of the search 
columns, which gets added to the object in entity.js line 25: 
ipa_entity_search_list = {};

Instead, I think we should define an object in its entirety in one 
function call.  Something like:

ipa_register_entity() which will add it to ipa_entity_list = {};


The entity will have name, pkey, and facets.

ipa_register_entity({name:'user', pkey:'uid',facets:{ search: [...], 
detail: [...], association [...]  } } );

Another function ipa_register_view will register the views.  Again, each 
view will have a name, and then the code for rendering the view:

ipa_register_view({name:'search', create: function(){}, 
load:function(){}, display function(){}});

I think these are the only method we will need, but we might want to 
think about how to extend them, for example, the filter and search 
requirements for DNS I listed above.  I suspect that customization will 
be done when we register the entities, so that when an entity registers 
its search facet, it will specify a filter function.

Now, when an entity has acustom view, we will register it via 
ipa_register_view, and then provide a corresponding element inside the 
facets object.

This is not just theoretical.  I think that we are going to need this 
ability to support the UXD layout for HBAC, ACI, and SUDO.  It will also 
provide us more optionsfor UI layouts in the future.