[Freeipa-devel] Dojo and Web UI in 3.2

[Simo Sorce]

On Wed, 2012-11-07 at 15:15 -0500, Dmitri Pal wrote:
> 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.

I do see a lot of research seem have one into this.
I am not a webui expert so I'll defer to the current people working on
it.

As long as the changes to the web ui do not impact the framework and
break compatibility of the xmlrpc api I think anything is on the table
and acceptable if it moves us forward toward better code and better UI.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York