[Freeipa-devel] Custom Facets and Views

[Dmitri Pal]

Adam Young wrote:
> 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.
>

You lost me in the middle since I am not in the code. I hope I can
summarize you proposal as: let us add an abstraction layer to control
what is shown on the "facet" line.
Search is a quick link back and should do the same thing as clicking on
the menu item so I am not sure it is something special. It should not be
show on the screens where there is no search like Kerberos policies or
configuration.
Details are usually needed - DNS is a special case I agree.
The other facets are "associations" of the object. This is how it was
speced and if this proposal changes this we need to get approval from UXD.

If it just the underlaying change without impact on the UI then I would
follow the following rules:
a) Do not over engineer things
b) Create abstraction if you already see commonality. I doubt we do at
the moment until we drill down into HBAC and ACIs.
c) Do only things that we must do at the moment and that would save time

So at this point I would say - may be look into something else, let the
HBAC & ACI get baked better, and then see the commonalities and
re-factor then.
Just a thought...


>
>
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/