[Freeipa-devel] Extending the IPA-API

[Adam Young]

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.
>