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'm not really a UI guy so I'm willing to defer this to Petr and/or Endi (and Adam). As long as any changes doesn't fundamentally change usability or cause massive changes in the XML-RPC/json framework it's fine with me. Making it easier to extend is definitely desirable.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to