Use Prototype or JQuery for Ajax goodies

[Anil Patel-3]

Hi,
We have been using Prototype and associated UI components for  
Javascript effects/Ajax. I am interested in few screens that will need  
Tree widget and few other will be best done using TreeTable widget.  
For sometime I have been looking for widgets build using Prototype.js  
but have not found any that l like.

JQuery on other hand has much bigger community and much bigger library  
of UI widgets that can make developing fancy screens lot easy.  
Sometimes I am tempted to start using JQuery, but fear that after  
while we'll know few bads about it and might regret decision.

I'll like to know what others think about it.

Is it ok to add JQuery library to Ofbiz trunk?
Should Prototype library be removed from trunk once all code is  
migrated to use JQuery?
Should keep both because JQuery can live side by side with Prototype?

Regards
Anil Patel

[guo weizhan]

There is dojo too, ofbiz should choose one of them as the basic ajax
framework  and kick the others out!

And I like dojo :)

2009/6/3 Anil Patel <[hidden email]>

> Hi,
> We have been using Prototype and associated UI components for Javascript
> effects/Ajax. I am interested in few screens that will need Tree widget and
> few other will be best done using TreeTable widget. For sometime I have been
> looking for widgets build using Prototype.js but have not found any that l
> like.
>
> JQuery on other hand has much bigger community and much bigger library of
> UI widgets that can make developing fancy screens lot easy. Sometimes I am
> tempted to start using JQuery, but fear that after while we'll know few bads
> about it and might regret decision.
>
> I'll like to know what others think about it.
>
> Is it ok to add JQuery library to Ofbiz trunk?
> Should Prototype library be removed from trunk once all code is migrated to
> use JQuery?
> Should keep both because JQuery can live side by side with Prototype?
>
> Regards
> Anil Patel
>
>

[Ashish Vijaywargiya]

Hello Anil,

+1 for adding Jquery to the trunk.
For more details please see my comments inline:

On Wed, Jun 3, 2009 at 7:26 AM, Anil Patel <[hidden email]>wrote:

> Hi,
> We have been using Prototype and associated UI components for Javascript
> effects/Ajax. I am interested in few screens that will need Tree widget and
> few other will be best done using TreeTable widget. For sometime I have been
> looking for widgets build using Prototype.js but have not found any that l
> like.
>
> JQuery on other hand has much bigger community and much bigger library of
> UI widgets that can make developing fancy screens lot easy. Sometimes I am
> tempted to start using JQuery, but fear that after while we'll know few bads
> about it and might regret decision.
>
> I'll like to know what others think about it.
>
> Is it ok to add JQuery library to Ofbiz trunk?

IMO this will be totally fine as it is associated with two license one is
MIT and other one is GPL. It depends on user or community which best suite
for their requirement. So I think we can opt MIT. For more details please
have a look on:

http://docs.jquery.com/License


>
> Should Prototype library be removed from trunk once all code is migrated to
> use JQuery?
>

> Should keep both because JQuery can live side by side with Prototype?


I liked this approach instead of removing one because some features could be
handled very nicely in Protype and some in JQuery.
It is my personal opinion but I am also fine if we remove Prototype after
migration is done to JQuery.


>
>
> Regards
> Anil Patel
>
>

[rajsaini]

> I liked this approach instead of removing one because some features could be
> handled very nicely in Protype and some in JQuery.
> It is my personal opinion but I am also fine if we remove Prototype after
> migration is done to JQuery.
>
>
>  
There is some conflict in JQuery and Prototype (I think init method
called on page load) and it may not be possible keep them side by side.

Thanks,

Raj

[Ashish Vijaywargiya]

Inline:

On Wed, Jun 3, 2009 at 10:52 AM, Raj Saini <[hidden email]> wrote:

>
>  I liked this approach instead of removing one because some features could
>> be
>> handled very nicely in Protype and some in JQuery.
>> It is my personal opinion but I am also fine if we remove Prototype after
>> migration is done to JQuery.
>>
>>
>>
>>
> There is some conflict in JQuery and Prototype (I think init method called
> on page load) and it may not be possible keep them side by side.

Raj, Thanks for sharing your thoughts on this. I haven't looked too much
details about JQuery.
What about your vote? Which one is good to become part of OFBiz trunk
Prototype or JQuery ?

--
Ashish


>
>
> Thanks,
>
> Raj
>
>

[rajsaini]

Hi Ashish,
> Raj, Thanks for sharing your thoughts on this. I haven't looked too much
> details about JQuery.
> What about your vote? Which one is good to become part of OFBiz trunk
> Prototype or JQuery ?
>
> --
> Ashish
>
>  
I would like go with JQuery as it is light weight, modular and feature
rich. Dojo is good but some time it is a overkill. I have not worked
much with Prototype though.

Thanks,

Raj

[Ryan Foster]

Jquery and Prototype can and do live relatively easily along side each  
other...
http://docs.jquery.com/Using_jQuery_with_Other_Libraries

As for what to maintain in the trunk, I would like to offer option C:  
none of the above, but rather suggest using the Google JS API to load  
in the library of the users choosing:

http://code.google.com/apis/ajaxlibs/

Ryan Foster
HotWax Media
801.671.0769
[hidden email]




On Jun 3, 2009, at 12:19 AM, Raj Saini wrote:

> Hi Ashish,
>> Raj, Thanks for sharing your thoughts on this. I haven't looked too  
>> much
>> details about JQuery.
>> What about your vote? Which one is good to become part of OFBiz trunk
>> Prototype or JQuery ?
>>
>> --
>> Ashish
>>
>>
> I would like go with JQuery as it is light weight, modular and  
> feature rich. Dojo is good but some time it is a overkill. I have  
> not worked much with Prototype though.
>
> Thanks,
>
> Raj
>

[Jacopo Cappellato-4]

Hi Ryan,

this is interesting, and maybe I didn't fully get how Google JS API  
works, but what about OFBiz instances that are in internal lan with no  
access to the Internet? What about the license?

Cheers,

Jacopo

On Jun 3, 2009, at 9:02 AM, Ryan Foster wrote:

> Jquery and Prototype can and do live relatively easily along side  
> each other...
> http://docs.jquery.com/Using_jQuery_with_Other_Libraries
>
> As for what to maintain in the trunk, I would like to offer option  
> C: none of the above, but rather suggest using the Google JS API to  
> load in the library of the users choosing:
>
> http://code.google.com/apis/ajaxlibs/
>
> Ryan Foster
> HotWax Media
> 801.671.0769
> [hidden email]
>
>
>
>
> On Jun 3, 2009, at 12:19 AM, Raj Saini wrote:
>
>> Hi Ashish,
>>> Raj, Thanks for sharing your thoughts on this. I haven't looked  
>>> too much
>>> details about JQuery.
>>> What about your vote? Which one is good to become part of OFBiz  
>>> trunk
>>> Prototype or JQuery ?
>>>
>>> --
>>> Ashish
>>>
>>>
>> I would like go with JQuery as it is light weight, modular and  
>> feature rich. Dojo is good but some time it is a overkill. I have  
>> not worked much with Prototype though.
>>
>> Thanks,
>>
>> Raj
>>
>

[Adam Heath-2]

guo weizhan wrote:
> There is dojo too, ofbiz should choose one of them as the basic ajax
> framework  and kick the others out!
>
> And I like dojo :)

We(brainfood) use jquery, with a smagering of gwt thrown in.

[Mridul Pathak-2]

IMO, we should consider community support with faster responses.  
Sometimes we come across improvements, enhancements and bug fixes in  
the available API, while using it for OFBiz and all that code should  
make its way into the API, so that we can always be in sync with the  
new releases of that API.

+1 for JQuery.

--
Thanks,
Mridul Pathak


On 03-Jun-09, at 11:49 AM, Raj Saini wrote:

> Hi Ashish,
>> Raj, Thanks for sharing your thoughts on this. I haven't looked too  
>> much
>> details about JQuery.
>> What about your vote? Which one is good to become part of OFBiz trunk
>> Prototype or JQuery ?
>>
>> --
>> Ashish
>>
>>
> I would like go with JQuery as it is light weight, modular and  
> feature rich. Dojo is good but some time it is a overkill. I have  
> not worked much with Prototype though.
>
> Thanks,
>
> Raj
>

[byersa]

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

[Brett]

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

[Adrian Crum]

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

[Ryan Foster]

Jacopo,

The Google API works by calling the available library from Google,  
rather than from your instance of OFBiz.  So rather that including  
javascript like OFBiz current does, instead it would pull in the  
library in this method:

<script src="http://www.google.com/jsapi" type="text/javascript"></
script>
<script type="text/javascript">google.load("prototype", "1.6.0.3");</
script>
<script type="text/javascript">google.load("scriptaculous", "1.8.2");</
script>

You would simply substitute prototype and scriptaculous with jquery  
(or dojo or mootools, depending on your preference).

There are several advantages to this approach, with one big  
disadvantage, which you alluded to:

PRO: It taps into Google's existing server network, with the JS being  
served up by the server that is closest to you, which in many cases  
may allow the library to load faster.
PRO: If the user previously visited a site that was also using the  
Google API, then the library would simply be loaded in for the users  
cache instead of the server, making the load time tremendously faster
PRO: No need to maintain the library in the trunk.  As a new version  
is released and becomes available from the Google API, you simply  
update the version number.
PRO: Availability of all major Javascript Frameworks. Dojo, Mootools,  
Prototype/Scriptaculous, and YUI are supported.

CON: Lack of availability if the user does not have an internet  
connection.

That last one is obviously a big one, and may be a deal breaker since  
OFBiz instances in Internal LANs would not be able to use this  
option.  But maybe we could try a hybrid approach; try requesting the  
library from Google first, and if not available, request from the  
trunk.  Or, make it a configurable user option, allowing the user to  
turn the Google API feature on or off at install/implementation.


Ryan Foster
HotWax Media
801.671.0769
[hidden email]




On Jun 3, 2009, at 2:22 AM, Jacopo Cappellato wrote:

> Hi Ryan,
>
> this is interesting, and maybe I didn't fully get how Google JS API  
> works, but what about OFBiz instances that are in internal lan with  
> no access to the Internet? What about the license?
>
> Cheers,
>
> Jacopo
>
> On Jun 3, 2009, at 9:02 AM, Ryan Foster wrote:
>
>> Jquery and Prototype can and do live relatively easily along side  
>> each other...
>> http://docs.jquery.com/Using_jQuery_with_Other_Libraries
>>
>> As for what to maintain in the trunk, I would like to offer option  
>> C: none of the above, but rather suggest using the Google JS API to  
>> load in the library of the users choosing:
>>
>> http://code.google.com/apis/ajaxlibs/
>>
>> Ryan Foster
>> HotWax Media
>> 801.671.0769
>> [hidden email]
>>
>>
>>
>>
>> On Jun 3, 2009, at 12:19 AM, Raj Saini wrote:
>>
>>> Hi Ashish,
>>>> Raj, Thanks for sharing your thoughts on this. I haven't looked  
>>>> too much
>>>> details about JQuery.
>>>> What about your vote? Which one is good to become part of OFBiz  
>>>> trunk
>>>> Prototype or JQuery ?
>>>>
>>>> --
>>>> Ashish
>>>>
>>>>
>>> I would like go with JQuery as it is light weight, modular and  
>>> feature rich. Dojo is good but some time it is a overkill. I have  
>>> not worked much with Prototype though.
>>>
>>> Thanks,
>>>
>>> Raj
>>>
>>
>

[byersa]

Adrian,

I am wondering if we need to expand the scope of the current schema to cover
things that Ajax does that were not practical when the original widget
component was produced?

It would be good to discuss what those components would be? Ones that come
to mind are trees, master/detail windows, more advanced menus.

Any other suggestions from anyone?

-Al

[guo weizhan]

Can you explain more about the connector library?


2009/6/4 Adrian Crum <[hidden email]>

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

[Adrian Crum]

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

[guo weizhan]

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

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

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: guo weizhan <[hidden email]>
> Subject: Re: Use Prototype or JQuery for Ajax goodies
> To: [hidden email]
> 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 <[hidden email]>
>
> > 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 <[hidden email]>
> >>
> >>  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
> <[hidden email]>
> >>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>
>

[guo weizhan]

2009/6/5 Adrian Crum <[hidden email]>

>
> It's an interesting idea, and you would have to provide some patches or
> something to demonstrate it.


OK, I will try to provide some patches about this with the trunk.


>
> 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.


I'm trying to make it work with the dojo, and will create patches about this
if I finished.

>
> 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 <[hidden email]> wrote:
>
> > From: guo weizhan <[hidden email]>
> > Subject: Re: Use Prototype or JQuery for Ajax goodies
> > To: [hidden email]
> > 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 <[hidden email]>
> >
> > > 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 <[hidden email]>
> > >>
> > >>  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
> > <[hidden email]>
> > >>>> 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
> > >>>>>
> > >>>>>
> > >>>>>
> > >>
> >
>
>
>
>