[Freeipa-devel] Dojo and Web UI in 3.2

[Petr Vobornik]

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.

-- 
Petr Vobornik