On 10/27/2011 08:40 PM, Endi Sukma Dewata wrote:
On 10/27/2011 10:59 AM, Adam Young wrote:
The web UI can implement a similar mechanism. We do not want end sites
modifying the .js files shipped with the IPA server RPM, other wise,
they could inject columns and fields there, but they would be
susceptible to breaking during upgrade. Instead, we will provide an
extension mechanism similar to the Library back end:
The Apache server will provide access to the file
/etc/ipa/html/extensions.json. By default, this file will contain the
simplest valid JSON possible:
{}
This file will be fetched via AJAX and evaluated during the
initialization of Entities. THe format of the file will indicate what
fields will be hidden in the UI, and what fields to add. As much as
possible, the format will match the Java script that is used to poulated
the entities.
Something along the lines of:
{entity:user,
search:{add:['foo'],
hide:['manager']},
details:{add:[ {identity: ['foo','bar']}],
hide:['manager']},
}
I'd rather not use a descriptive language to perform object
modification because it's very limited. For example, the 'add'
operation doesn't say where the 'foo' should be added, whether it
should be at the beginning or the end, or before/after certain fields,
etc. We could continue expanding the language to support more complex
logic, but why not just use JS directly.
I think you are right. I'd like to focus on a form that looks as
declarative as possible, as it is likely going to be performed by
system administrators, and done in the context of editing a
configuration file.
This would add one field to the search results, and two fields to the
details page, inside the identity section.
For the first pass, all added fields would be added as text fields.
On the second pass, the JSON listed above can be extended to allow
custom widgets in the field declarations.
On the third pass, we add in a second file:
/etc/ipa/html/custom_widgets.js. By default it will be blank.
I'd say we go directly with custom JS file and provide a good
extensible JS API. It will require the least effort from us.
Somewhere in the code we can define the default entities:
IPA.register('user', IPA.user.User);
IPA.register('group', IPA.group.Group);
Then in the custom JS file we can override the default entity:
IPA.register('user', com.example.user.User);
The custom entity can be defined as follows:
com.example.user.User = function(spec) {
// extend the default entity
var that = IPA.user.User(spec);
var init = function() {
// replace the original search facet
that.add_facet(com.example.user.SearchFacet({
name: 'search'
});
};
init();
return that;
};
com.example.user.SearchFacet = function(spec) {
// extend the default search facet
var that = IPA.user.SearchFacet(spec);
var init = function() {
// find phone's position
var i = that.get_field_index('phone');
// add fax after phone
that.add_field(i+1, 'fax');
};
init();
return that;
};
Then later we can design a descriptive language that will cover most
common use cases.
Sounds like a plan. Just try to keep the descriptive approach in the
forefront of your mind so that we don't have to implement twice.
This file will be added to the index.html of the webUI, and evaluated
after all of the other widgets, but before the entities. This will allow
the end sites to not only add in their own widgets, but to possibly
change the definition of some of the baseline widgets as well.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
