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.

Freeipa-devel mailing list

Reply via email to