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 <[email protected]> > 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 <[email protected]> >> >> 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 <[email protected]> >>>> 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 >>>>> >>>>> >>>>> >>
