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/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel