[Freeipa-devel] Object structure for UI

[Adam Young]

I've been working with the "add host " and "host details" pages for the 
past couple of days. It is getting time to refactor how we do add and 
details, to avoid cutting and pasting. Here's the general structure I'm 
approach on taking.

For each collection (user, group, host, etc) there will be an instance 
of a SearchForm object that maps to that collection. This object will 
have a reference to at a minimum two other form objects, one for 
details, one for "add".

Here's changes for the Search Form Objects

    * objects will be held in global scoped variables, not inside
      function scope as it is currently done now.
    * Search Forms will not contain any state. All state will be
      contianed in the primary key, the json responses, and the form params.
    * Instead of rendering the search form in the constructor, it will
      have a "build" function that performs the same actions.

The same general approach will happen with the Add and Details approach. 
In general, each page will have an instance of some type of "Form" 
object. The difference between the user search form and the group search 
form is which instance all of the methods look for. so the Update button 
will be bound to

    function() { userDetailsForm.update() };

or

    function() { groupDetailsForm.update() };

appropriately. The goal here is to reduce duplicated code, and the 
corresponding copy-and-paste errors it introduces.  Ideally I'd like to 
do something like:

    var activeDetailsForm;
    ...
    activeDetails = userDetailsForm;
    ...
      $("#addEdit").click(
    function() { activeDetailsForm.addEdit() };
    );

my one concern is making sure that variables like activeDetailsForm get 
set correctly upon  back-button.

For now I am going to put the details work in the host.js file, as I 
don't want to get into a knarly merge with details.js. At some point, 
Pavel and I will coordinate moving it into details.js.

I am considering adding add.js for that functionality, but am reluctant 
to add yet another file, as that increased the download time for initial 
view of the site.

search, details, and add are all considered facets inside the code. If 
you look at the URL, you should see something like:

    #tab=user&facet=search

or

    #tab=group&facet=details&pkey=ipausers

Every collection will have these three facts, but will have a collection 
of 0 or more additional facets. For example, user will have a membership 
facet. This collection of facets will be used to create the links off of 
the details page at the top.

The general trend is going to be to divide code up into one of three 
categories: Framework, Domain Objects, Wiring. Thus, things like search, 
details, and navigation in the abstract are framework, user and groups 
and so forth are domain objects, and wiring is the population of things 
like the navigation and facets. There is obviously some blurring between 
wiring and domain objects, but the guiding principal will be that wiring 
is for Fitting together the overall site, such as how the navigation is 
set up, where as Domain is for UI behavior specific to a collection.

This will not be a single patch, but instead will be the target of 
several small refactorings as I implement features in the site.  I've 
already started with the DetailsForm, but need to create the AddForm, 
and will do so as I implement add hosts.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20100820/ff2ed5c9/attachment.htm>