It's an interesting idea, and you would have to provide some patches or something to demonstrate it.
The existing connector library has a very simple API - the functions accept HTML element references and CSV strings. I can't see why that can't be adapted to other JS libraries. If the tree structure is the only obstacle, then let's discuss it further. I am sure we can all collaborate on a solution. -Adrian --- On Thu, 6/4/09, guo weizhan <guo.weiz...@gmail.com> wrote: > From: guo weizhan <guo.weiz...@gmail.com> > Subject: Re: Use Prototype or JQuery for Ajax goodies > To: dev@ofbiz.apache.org > Date: Thursday, June 4, 2009, 8:58 PM > I notice that. but It's not easy to > change to other lib. > > How about this: > > We make those js files as the VisualThemeResource, and we > can implement the > function with the ajax lib we want and replace those files > easily. > > I think the selectall.js can do in this way, in fact we > have try to do this, > we change the pop up way and others. But the complicated > component is > difficult to do this, take the tree for example, the data > structure using by > different ajax lib is different, like the last dojo version > don't support > inline data structure, we have to generate a special data > store for dojo, I > don't know there is a common way for those complicated > component yet. > > 2009/6/4 Adrian Crum <adri...@hlmksw.com> > > > In the current trunk, selectall.js, starting at line > 211 there are some JS > > functions that use Prototype. The widgets call those > functions - they don't > > use Prototype directly. > > > > -Adrian > > > > > > guo weizhan wrote: > > > >> Can you explain more about the connector library? > >> > >> > >> 2009/6/4 Adrian Crum <adri...@hlmksw.com> > >> > >> The existing widget-Ajax code does that. The > widgets call JS functions in > >>> a > >>> "connector library" - which uses Prototype. > Someone wanting to use a > >>> different toolkit can replace the connector > library. > >>> > >>> -Adrian > >>> > >>> > >>> Brett Palmer wrote: > >>> > >>> I agree with Al. > >>>> > >>>> We need to provide an abstraction layer to > allow developers to > >>>> integrate their favorite AJAX library with > the existing screen widget > >>>> technology. This may mean the widget > is rendered in the browser > >>>> rather than the server as many of the MVC > operations move to the > >>>> client in AJAX tool kits, but it would be > nice to have a standard way > >>>> to represent those UI's in a generic > syntax that works across > >>>> technologies. > >>>> > >>>> > >>>> Brett > >>>> > >>>> On Wed, Jun 3, 2009 at 9:31 AM, Al Byers > <bye...@automationgroups.com> > >>>> wrote: > >>>> > >>>> Before we choose a UI library, it > might be better to determine what > >>>>> sort > >>>>> of > >>>>> advanced screens and features we are > shooting for (eg. trees, > >>>>> master/detail, > >>>>> heirarchical menus, etc.) so that we > can enhance the widget > >>>>> architecture > >>>>> to > >>>>> handle them. Then the widget component > can act as a common definition > >>>>> language for front-end systems built > on different libraries. > >>>>> > >>>>> When it comes to front-ends, I think > we should try to separate them > >>>>> from > >>>>> the > >>>>> rest of OFBiz, as people get very > religious about them. I have spent > >>>>> almost > >>>>> a year and a half with Dojo and liken > it to the amount of time it took > >>>>> to > >>>>> become familiar with OFBiz (which is > going on 8 years). I doubt that I > >>>>> would > >>>>> switch because OFBiz decided to go > with one library on another. > >>>>> > >>>>> -Al > >>>>> > >>>>> > >>>>> > >> >
