[Freeipa-devel] Dojo and Web UI in 3.2

Dmitri Pal dpal at redhat.com
Wed Nov 7 20:15:58 UTC 2012


On 11/07/2012 01:16 PM, Petr Vobornik wrote:
> On 11/07/2012 05:30 PM, Dmitri Pal wrote:
>> On 11/07/2012 10:46 AM, Petr Vobornik wrote:
>>> We discussed some things on IRC. I wrote some comments below to allow
>>> others to chime in.
>>>
>>> Adam also created a public etherpad where we wrote most of the issues
>>> and possible solutions in some frameworks. I also wrote there short
>>> reviews of various JavaScript frameworks.
>>>
>>> https://etherpad.openstack.org/webui-idm
>>
>>
>> Good analyzes. But unfortunately I do not understand it well enough to
>> provide an opinion or guidance.
>> Let us step back and think about the goals.
>>
>> The UI works. It is not that it is broken.
>> We have several requirements for it though.
>>
>> 1) Do not redo it but refactor as needed
>> 2) Do not grow technical debt for long. If something really ugly and
>> prevents us from adding new capabilities or creates a bad user
>> experience let us fix it.
>> 3) We need to solve the problem of plugins/extensible UI so that
>> optional UI components can be dropped in.
>>
>> Untangling IPA specific things from common code is a nice goal but not a
>> priority.
>> With those requirements on the table what do you see is the best focused
>> approach?
>
> Sorted by priority:
> 1) Improve navigation extensibility (#3236), introduce a loader
> (dojo/require.js/custom) and extension registration (to know what to
> load) (#3235). These should solve requirement #3.
>
> 2) Refactor/introduce better model(persistance). IMO biggest technical
> debt. For this task I want to borrow a component from Dojo. It will
> make developing of enhancements and additional refactoring easier.
>
> 3) Along with 1) and 2) we can do additional refactoring of
> navigation. which will fix some ugly intermittent errors (#2741).
>
> 4) Optimize startup. Not a big task, IMO possibly very appreciated
> enhancement by admins. Tickets:  #2678, #2679, #112
>
> 5) I would really want to introduce AMD modules. Requires AMD loader
> (dojo/require.js) and a build tool (dojo/r.js) It should:
>     * make dependencies more clear
>     * easier development of third-party enhancements
>     * the build helps with 4)
>     * build will allow us to comment more so it might help new developers
>     * it's side effect is partial untangling of IPA specific things
> from common code
>     * better to do it sooner to avoid breaking of third party extensions.
>
> It's not a necessity but it should be worth the effort long-term.
>
> 6) Adopt different class system (from dojo or backbone.js) - fix
> issues in object initialization.
>     * very time-consuming task
>     * should be adopted gradually
>
>
> I've also considered to write a module with methods used by extension
> developers to extend existing pages easily - add one or two fields
> without studying the whole codebase. Something like
> add_field_after(new_field, entity, facet, section, after_field) or
> add_field(field, spec). Might be appreciated.
>

Does it make sense to everybody else besides me?
If yes let us agree with the plan.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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






More information about the Freeipa-devel mailing list