Dev - Proposal for Ajax enhanced OFbiz

[Leon Torres-2]

Lately, I've been writing Ajax-enhanced applications using Ruby on Rails.
I'm amazed at some of the abilities of that platform, especially its Ajax
capabilities.  Now I'm interested in putting something together for OFBiz so
that we can leverage Ajax in the same way.

To get things rolling I propose the following,


1)  Create a place to collect all Ajax files:  framework/ajax

There will be new CSS, javascript and src/ libraries for handling ajax.  To
manage them, we need to have a centralized place to put everything, especially
the org.ofbiz.ajax code. This also helps keep the Ajax development
tidy and focused.

Since I'll be doing a lot of Ajax work in the near future, I'd like to have
commit access.  In this capacity, I will involve the community at large so
that we find the best practices and most pragmatic implementations.


2)  Identify Javascript libraries or ideas for libraries to help enrichen the
     user interface and to help manage the XMlHttpRequest() object.

     -  Autocomplete (Fred Forrester did some great work here)
     -  Drag and drop library (I wrote one recently)
     -  Replacement for lookup popup that's a DIV on the same page
     -  Calendar system library to replace our cal popup
     -  Google, Yahoo, other third party Ajax API libraries
     -  etc.

I'd like to work with others to determine which are best for OFBiz.


Thanks,

Leon Torres
Open Source Strategies
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

I have seen a lot of Ajax in libraries already in ofbiz.
how is what you are proposing different than say JMX or XUI which is
already in ofbiz?



Leon Torres sent the following on 6/9/06 5:55 PM:

> Lately, I've been writing Ajax-enhanced applications using Ruby on Rails.
> I'm amazed at some of the abilities of that platform, especially its Ajax
> capabilities.  Now I'm interested in putting something together for OFBiz so
> that we can leverage Ajax in the same way.
>
> To get things rolling I propose the following,
>
>
> 1)  Create a place to collect all Ajax files:  framework/ajax
>
> There will be new CSS, javascript and src/ libraries for handling ajax.  To
> manage them, we need to have a centralized place to put everything, especially
> the org.ofbiz.ajax code. This also helps keep the Ajax development
> tidy and focused.
>
> Since I'll be doing a lot of Ajax work in the near future, I'd like to have
> commit access.  In this capacity, I will involve the community at large so
> that we find the best practices and most pragmatic implementations.
>
>
> 2)  Identify Javascript libraries or ideas for libraries to help enrichen the
>      user interface and to help manage the XMlHttpRequest() object.
>
>      -  Autocomplete (Fred Forrester did some great work here)
>      -  Drag and drop library (I wrote one recently)
>      -  Replacement for lookup popup that's a DIV on the same page
>      -  Calendar system library to replace our cal popup
>      -  Google, Yahoo, other third party Ajax API libraries
>      -  etc.
>
> I'd like to work with others to determine which are best for OFBiz.
>
>
> Thanks,
>
> Leon Torres
> Open Source Strategies
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

How are JMX or XUI related to AJAX?

-David


BJ Freeman wrote:

> I have seen a lot of Ajax in libraries already in ofbiz.
> how is what you are proposing different than say JMX or XUI which is
> already in ofbiz?
>
>
>
> Leon Torres sent the following on 6/9/06 5:55 PM:
>> Lately, I've been writing Ajax-enhanced applications using Ruby on Rails.
>> I'm amazed at some of the abilities of that platform, especially its Ajax
>> capabilities.  Now I'm interested in putting something together for OFBiz so
>> that we can leverage Ajax in the same way.
>>
>> To get things rolling I propose the following,
>>
>>
>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>
>> There will be new CSS, javascript and src/ libraries for handling ajax.  To
>> manage them, we need to have a centralized place to put everything, especially
>> the org.ofbiz.ajax code. This also helps keep the Ajax development
>> tidy and focused.
>>
>> Since I'll be doing a lot of Ajax work in the near future, I'd like to have
>> commit access.  In this capacity, I will involve the community at large so
>> that we find the best practices and most pragmatic implementations.
>>
>>
>> 2)  Identify Javascript libraries or ideas for libraries to help enrichen the
>>      user interface and to help manage the XMlHttpRequest() object.
>>
>>      -  Autocomplete (Fred Forrester did some great work here)
>>      -  Drag and drop library (I wrote one recently)
>>      -  Replacement for lookup popup that's a DIV on the same page
>>      -  Calendar system library to replace our cal popup
>>      -  Google, Yahoo, other third party Ajax API libraries
>>      -  etc.
>>
>> I'd like to work with others to determine which are best for OFBiz.
>>
>>
>> Thanks,
>>
>> Leon Torres
>> Open Source Strategies
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

Ajax basically uses XML as a response to an HTTP request.
it has a engine that is part of the Client that keep refreshing the client.

The difference is the code used to do this.




David E. Jones sent the following on 6/10/06 11:49 AM:

> How are JMX or XUI related to AJAX?
>
> -David
>
>
> BJ Freeman wrote:
>
>>I have seen a lot of Ajax in libraries already in ofbiz.
>>how is what you are proposing different than say JMX or XUI which is
>>already in ofbiz?
>>
>>
>>
>>Leon Torres sent the following on 6/9/06 5:55 PM:
>>
>>>Lately, I've been writing Ajax-enhanced applications using Ruby on Rails.
>>>I'm amazed at some of the abilities of that platform, especially its Ajax
>>>capabilities.  Now I'm interested in putting something together for OFBiz so
>>>that we can leverage Ajax in the same way.
>>>
>>>To get things rolling I propose the following,
>>>
>>>
>>>1)  Create a place to collect all Ajax files:  framework/ajax
>>>
>>>There will be new CSS, javascript and src/ libraries for handling ajax.  To
>>>manage them, we need to have a centralized place to put everything, especially
>>>the org.ofbiz.ajax code. This also helps keep the Ajax development
>>>tidy and focused.
>>>
>>>Since I'll be doing a lot of Ajax work in the near future, I'd like to have
>>>commit access.  In this capacity, I will involve the community at large so
>>>that we find the best practices and most pragmatic implementations.
>>>
>>>
>>>2)  Identify Javascript libraries or ideas for libraries to help enrichen the
>>>     user interface and to help manage the XMlHttpRequest() object.
>>>
>>>     -  Autocomplete (Fred Forrester did some great work here)
>>>     -  Drag and drop library (I wrote one recently)
>>>     -  Replacement for lookup popup that's a DIV on the same page
>>>     -  Calendar system library to replace our cal popup
>>>     -  Google, Yahoo, other third party Ajax API libraries
>>>     -  etc.
>>>
>>>I'd like to work with others to determine which are best for OFBiz.
>>>
>>>
>>>Thanks,
>>>
>>>Leon Torres
>>>Open Source Strategies
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

I know what AJAX is: http://en.wikipedia.org/wiki/AJAX 

The question was how JMX and XUI are related to AJAX? I guess I'm not seeing the connection somehow...

JMX: http://java.sun.com/products/JavaManagement/
XUI: http://xui.sourceforge.net/

-David


BJ Freeman wrote:

> Ajax basically uses XML as a response to an HTTP request.
> it has a engine that is part of the Client that keep refreshing the client.
>
> The difference is the code used to do this.
>
>
>
>
> David E. Jones sent the following on 6/10/06 11:49 AM:
>> How are JMX or XUI related to AJAX?
>>
>> -David
>>
>>
>> BJ Freeman wrote:
>>
>>> I have seen a lot of Ajax in libraries already in ofbiz.
>>> how is what you are proposing different than say JMX or XUI which is
>>> already in ofbiz?
>>>
>>>
>>>
>>> Leon Torres sent the following on 6/9/06 5:55 PM:
>>>
>>>> Lately, I've been writing Ajax-enhanced applications using Ruby on Rails.
>>>> I'm amazed at some of the abilities of that platform, especially its Ajax
>>>> capabilities.  Now I'm interested in putting something together for OFBiz so
>>>> that we can leverage Ajax in the same way.
>>>>
>>>> To get things rolling I propose the following,
>>>>
>>>>
>>>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>>>
>>>> There will be new CSS, javascript and src/ libraries for handling ajax.  To
>>>> manage them, we need to have a centralized place to put everything, especially
>>>> the org.ofbiz.ajax code. This also helps keep the Ajax development
>>>> tidy and focused.
>>>>
>>>> Since I'll be doing a lot of Ajax work in the near future, I'd like to have
>>>> commit access.  In this capacity, I will involve the community at large so
>>>> that we find the best practices and most pragmatic implementations.
>>>>
>>>>
>>>> 2)  Identify Javascript libraries or ideas for libraries to help enrichen the
>>>>     user interface and to help manage the XMlHttpRequest() object.
>>>>
>>>>     -  Autocomplete (Fred Forrester did some great work here)
>>>>     -  Drag and drop library (I wrote one recently)
>>>>     -  Replacement for lookup popup that's a DIV on the same page
>>>>     -  Calendar system library to replace our cal popup
>>>>     -  Google, Yahoo, other third party Ajax API libraries
>>>>     -  etc.
>>>>
>>>> I'd like to work with others to determine which are best for OFBiz.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Leon Torres
>>>> Open Source Strategies
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Leon Torres wrote:

> 1)  Create a place to collect all Ajax files:  framework/ajax
>
> There will be new CSS, javascript and src/ libraries for handling ajax.  To
> manage them, we need to have a centralized place to put everything, especially
> the org.ofbiz.ajax code. This also helps keep the Ajax development
> tidy and focused.
>
> Since I'll be doing a lot of Ajax work in the near future, I'd like to have
> commit access.  In this capacity, I will involve the community at large so
> that we find the best practices and most pragmatic implementations.

Is there any reason to not put it in the framework/webapp component? The point of that component is to put web application specific infrastructure there, as opposed to the guiapp component which is for desktop client (Swing, SWT, whatever) related infrastructure.

As far as commit access goes, that can probably be arranged but the PPMC would need to vote on it.

-David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

>
> I know what AJAX is: http://en.wikipedia.org/wiki/AJAX
>
> The question was how JMX and XUI are related to AJAX? I guess I'm not seeing
the connection somehow...
>
> JMX: http://java.sun.com/products/JavaManagement/
> XUI: http://xui.sourceforge.net/
>
> -David

What xoetrope think about Ajax

Carousel versus AJAX
AJAX isn't a new kid on the block, having been around in many guises for several
years. AJAX is essentially a technique for updating a web page without having to
request a page refresh. AJAX can update a fragment of the page and the end user
has the impression of a more responsive environment as only some of the page
updates. Indeed AJAX may be a little more efficient than vanilla HTML as the
fragments of HTML/XML it pulls down during updates will conserve some bandwidth.

AJAX can enable some client side processing of data but it is at heart still a
scripting technology, still burdened with all the drawbacks of scripting and of
being browser based.



Found on :
http://www.xoetrope.com/zone/manual/article.php?zone=XUI&article=4&articleid=18



Jacques

>
> BJ Freeman wrote:
> > Ajax basically uses XML as a response to an HTTP request.
> > it has a engine that is part of the Client that keep refreshing the client.
> >
> > The difference is the code used to do this.
> >
> >
> >
> >
> > David E. Jones sent the following on 6/10/06 11:49 AM:
> >> How are JMX or XUI related to AJAX?
> >>
> >> -David
> >>
> >>
> >> BJ Freeman wrote:
> >>
> >>> I have seen a lot of Ajax in libraries already in ofbiz.
> >>> how is what you are proposing different than say JMX or XUI which is
> >>> already in ofbiz?
> >>>
> >>>
> >>>
> >>> Leon Torres sent the following on 6/9/06 5:55 PM:
> >>>
> >>>> Lately, I've been writing Ajax-enhanced applications using Ruby on Rails.
> >>>> I'm amazed at some of the abilities of that platform, especially its Ajax
> >>>> capabilities.  Now I'm interested in putting something together for OFBiz

so
> >>>> that we can leverage Ajax in the same way.
> >>>>
> >>>> To get things rolling I propose the following,
> >>>>
> >>>>
> >>>> 1)  Create a place to collect all Ajax files:  framework/ajax
> >>>>
> >>>> There will be new CSS, javascript and src/ libraries for handling ajax.
To
> >>>> manage them, we need to have a centralized place to put everything,
especially
> >>>> the org.ofbiz.ajax code. This also helps keep the Ajax development
> >>>> tidy and focused.
> >>>>
> >>>> Since I'll be doing a lot of Ajax work in the near future, I'd like to
have
> >>>> commit access.  In this capacity, I will involve the community at large
so
> >>>> that we find the best practices and most pragmatic implementations.
> >>>>
> >>>>
> >>>> 2)  Identify Javascript libraries or ideas for libraries to help enrichen
the

> >>>>     user interface and to help manage the XMlHttpRequest() object.
> >>>>
> >>>>     -  Autocomplete (Fred Forrester did some great work here)
> >>>>     -  Drag and drop library (I wrote one recently)
> >>>>     -  Replacement for lookup popup that's a DIV on the same page
> >>>>     -  Calendar system library to replace our cal popup
> >>>>     -  Google, Yahoo, other third party Ajax API libraries
> >>>>     -  etc.
> >>>>
> >>>> I'd like to work with others to determine which are best for OFBiz.
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Leon Torres
> >>>> Open Source Strategies
> >>>>
> >>>> _______________________________________________
> >>>> Dev mailing list
> >>>> [hidden email]
> >>>> http://lists.ofbiz.org/mailman/listinfo/dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> Dev mailing list
> >>> [hidden email]
> >>> http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

I don't believe JMX/XUI offer the same functionality as AJAX. Although AJAX
has XML as part of its name, the latest trend uses JSON encoding instead of
XML. A technical link is here
http://www-128.ibm.com/developerworks/java/library/j-ajax2/#resources.

I think it will be wonderful to have an AJAX framework as part of OFBiz so
that we have opportunity to start developing richer UI. But it is equally
important to have the "right" AJAX framework since one can not take parts
from one framework and use them in another. In addition, the framework must
have development tools.

>From my research, the leader framework is--dojo at http://dojotoolkit.org
for which IBM provides a free Eclipse plugin. Not too many frameworks have
development tools provided by a major vendor.

Regards,
Vinay Agarwal


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Jacques Le Roux
Sent: Saturday, June 10, 2006 1:03 PM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Proposal for Ajax enhanced OFbiz

>
> I know what AJAX is: http://en.wikipedia.org/wiki/AJAX
>
> The question was how JMX and XUI are related to AJAX? I guess I'm not
> seeing
the connection somehow...
>
> JMX: http://java.sun.com/products/JavaManagement/
> XUI: http://xui.sourceforge.net/
>
> -David

What xoetrope think about Ajax

Carousel versus AJAX
AJAX isn't a new kid on the block, having been around in many guises for
several years. AJAX is essentially a technique for updating a web page
without having to request a page refresh. AJAX can update a fragment of the
page and the end user has the impression of a more responsive environment as
only some of the page updates. Indeed AJAX may be a little more efficient
than vanilla HTML as the fragments of HTML/XML it pulls down during updates
will conserve some bandwidth.

AJAX can enable some client side processing of data but it is at heart still
a scripting technology, still burdened with all the drawbacks of scripting
and of being browser based.



Found on :
http://www.xoetrope.com/zone/manual/article.php?zone=XUI&article=4&articleid
=18



Jacques


>
> BJ Freeman wrote:
> > Ajax basically uses XML as a response to an HTTP request.
> > it has a engine that is part of the Client that keep refreshing the
client.

> >
> > The difference is the code used to do this.
> >
> >
> >
> >
> > David E. Jones sent the following on 6/10/06 11:49 AM:
> >> How are JMX or XUI related to AJAX?
> >>
> >> -David
> >>
> >>
> >> BJ Freeman wrote:
> >>
> >>> I have seen a lot of Ajax in libraries already in ofbiz.
> >>> how is what you are proposing different than say JMX or XUI which
> >>> is already in ofbiz?
> >>>
> >>>
> >>>
> >>> Leon Torres sent the following on 6/9/06 5:55 PM:
> >>>
> >>>> Lately, I've been writing Ajax-enhanced applications using Ruby on

Rails.
> >>>> I'm amazed at some of the abilities of that platform, especially
> >>>> its Ajax capabilities.  Now I'm interested in putting something
> >>>> together for OFBiz
so
> >>>> that we can leverage Ajax in the same way.
> >>>>
> >>>> To get things rolling I propose the following,
> >>>>
> >>>>
> >>>> 1)  Create a place to collect all Ajax files:  framework/ajax
> >>>>
> >>>> There will be new CSS, javascript and src/ libraries for handling
ajax.
To
> >>>> manage them, we need to have a centralized place to put
> >>>> everything,
especially
> >>>> the org.ofbiz.ajax code. This also helps keep the Ajax
> >>>> development tidy and focused.
> >>>>
> >>>> Since I'll be doing a lot of Ajax work in the near future, I'd
> >>>> like to
have
> >>>> commit access.  In this capacity, I will involve the community at
> >>>> large
so
> >>>> that we find the best practices and most pragmatic implementations.
> >>>>
> >>>>
> >>>> 2)  Identify Javascript libraries or ideas for libraries to help
> >>>> enrichen
the

> >>>>     user interface and to help manage the XMlHttpRequest() object.
> >>>>
> >>>>     -  Autocomplete (Fred Forrester did some great work here)
> >>>>     -  Drag and drop library (I wrote one recently)
> >>>>     -  Replacement for lookup popup that's a DIV on the same page
> >>>>     -  Calendar system library to replace our cal popup
> >>>>     -  Google, Yahoo, other third party Ajax API libraries
> >>>>     -  etc.
> >>>>
> >>>> I'd like to work with others to determine which are best for OFBiz.
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Leon Torres
> >>>> Open Source Strategies
> >>>>
> >>>> _______________________________________________
> >>>> Dev mailing list
> >>>> [hidden email]
> >>>> http://lists.ofbiz.org/mailman/listinfo/dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> Dev mailing list
> >>> [hidden email]
> >>> http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

Thanks Vinay,

After some quick reading this sound good to me too.

Though it does not solve problems like "recreate a new UI to ease user help in
correction of localised categ/product names/descriptions after some large xml
import" it may help ...

BTW I'd like to work soon on something like that (i10n of  names/descriptions of
categ/product). I'll think about it and create a new Jira issue if none already
exists. It could be an opportunity to test the tandem JSON-RPC-Java/Dojo in such
a task.

Jacques

> I don't believe JMX/XUI offer the same functionality as AJAX. Although AJAX
> has XML as part of its name, the latest trend uses JSON encoding instead of
> XML. A technical link is here
> http://www-128.ibm.com/developerworks/java/library/j-ajax2/#resources.
>
> I think it will be wonderful to have an AJAX framework as part of OFBiz so
> that we have opportunity to start developing richer UI. But it is equally
> important to have the "right" AJAX framework since one can not take parts
> from one framework and use them in another. In addition, the framework must
> have development tools.
>
> >From my research, the leader framework is--dojo at http://dojotoolkit.org
> for which IBM provides a free Eclipse plugin. Not too many frameworks have
> development tools provided by a major vendor.
>
> Regards,
> Vinay Agarwal
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Jacques Le Roux
> Sent: Saturday, June 10, 2006 1:03 PM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Proposal for Ajax enhanced OFbiz
>
> >
> > I know what AJAX is: http://en.wikipedia.org/wiki/AJAX
> >
> > The question was how JMX and XUI are related to AJAX? I guess I'm not
> > seeing
> the connection somehow...
> >
> > JMX: http://java.sun.com/products/JavaManagement/
> > XUI: http://xui.sourceforge.net/
> >
> > -David
>
> What xoetrope think about Ajax
>
> Carousel versus AJAX
> AJAX isn't a new kid on the block, having been around in many guises for
> several years. AJAX is essentially a technique for updating a web page
> without having to request a page refresh. AJAX can update a fragment of the
> page and the end user has the impression of a more responsive environment as
> only some of the page updates. Indeed AJAX may be a little more efficient
> than vanilla HTML as the fragments of HTML/XML it pulls down during updates
> will conserve some bandwidth.
>
> AJAX can enable some client side processing of data but it is at heart still
> a scripting technology, still burdened with all the drawbacks of scripting
> and of being browser based.
>
>
>
> Found on :
> http://www.xoetrope.com/zone/manual/article.php?zone=XUI&article=4&articleid
> =18
>
>
>
> Jacques
>
>
> >
> > BJ Freeman wrote:
> > > Ajax basically uses XML as a response to an HTTP request.
> > > it has a engine that is part of the Client that keep refreshing the
> client.
> > >
> > > The difference is the code used to do this.
> > >
> > >
> > >
> > >
> > > David E. Jones sent the following on 6/10/06 11:49 AM:
> > >> How are JMX or XUI related to AJAX?
> > >>
> > >> -David
> > >>
> > >>
> > >> BJ Freeman wrote:
> > >>
> > >>> I have seen a lot of Ajax in libraries already in ofbiz.
> > >>> how is what you are proposing different than say JMX or XUI which
> > >>> is already in ofbiz?
> > >>>
> > >>>
> > >>>
> > >>> Leon Torres sent the following on 6/9/06 5:55 PM:
> > >>>
> > >>>> Lately, I've been writing Ajax-enhanced applications using Ruby on
> Rails.
> > >>>> I'm amazed at some of the abilities of that platform, especially
> > >>>> its Ajax capabilities.  Now I'm interested in putting something
> > >>>> together for OFBiz
> so
> > >>>> that we can leverage Ajax in the same way.
> > >>>>
> > >>>> To get things rolling I propose the following,
> > >>>>
> > >>>>
> > >>>> 1)  Create a place to collect all Ajax files:  framework/ajax
> > >>>>
> > >>>> There will be new CSS, javascript and src/ libraries for handling
> ajax.
> To
> > >>>> manage them, we need to have a centralized place to put
> > >>>> everything,
> especially
> > >>>> the org.ofbiz.ajax code. This also helps keep the Ajax
> > >>>> development tidy and focused.
> > >>>>
> > >>>> Since I'll be doing a lot of Ajax work in the near future, I'd
> > >>>> like to
> have
> > >>>> commit access.  In this capacity, I will involve the community at
> > >>>> large
> so
> > >>>> that we find the best practices and most pragmatic implementations.
> > >>>>
> > >>>>
> > >>>> 2)  Identify Javascript libraries or ideas for libraries to help
> > >>>> enrichen
> the
> > >>>>     user interface and to help manage the XMlHttpRequest() object.
> > >>>>
> > >>>>     -  Autocomplete (Fred Forrester did some great work here)
> > >>>>     -  Drag and drop library (I wrote one recently)
> > >>>>     -  Replacement for lookup popup that's a DIV on the same page
> > >>>>     -  Calendar system library to replace our cal popup
> > >>>>     -  Google, Yahoo, other third party Ajax API libraries
> > >>>>     -  etc.
> > >>>>
> > >>>> I'd like to work with others to determine which are best for OFBiz.
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Leon Torres
> > >>>> Open Source Strategies
> > >>>>
> > >>>> _______________________________________________
> > >>>> Dev mailing list
> > >>>> [hidden email]
> > >>>> http://lists.ofbiz.org/mailman/listinfo/dev
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> Dev mailing list
> > >>> [hidden email]
> > >>> http://lists.ofbiz.org/mailman/listinfo/dev
> > >>
> > >> _______________________________________________
> > >> Dev mailing list
> > >> [hidden email]
> > >> http://lists.ofbiz.org/mailman/listinfo/dev
> > >>
> > >
> > > _______________________________________________
> > > Dev mailing list
> > > [hidden email]
> > > http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

David,

It could go into the framework/webapp/ directory.  One reason to keep  
it outside is that the ajax tools could also be used by other webapp  
frameworks.  The other reason is so that it could have separate  
commit privileges than the other framework/ directories.

Should I write this to the PPMC then?

Si


On Jun 10, 2006, at 12:31 PM, David E. Jones wrote:

>
>
> Leon Torres wrote:
>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>
>> There will be new CSS, javascript and src/ libraries for handling  
>> ajax.  To
>> manage them, we need to have a centralized place to put  
>> everything, especially
>> the org.ofbiz.ajax code. This also helps keep the Ajax development
>> tidy and focused.
>>
>> Since I'll be doing a lot of Ajax work in the near future, I'd  
>> like to have
>> commit access.  In this capacity, I will involve the community at  
>> large so
>> that we find the best practices and most pragmatic implementations.
>
> Is there any reason to not put it in the framework/webapp  
> component? The point of that component is to put web application  
> specific infrastructure there, as opposed to the guiapp component  
> which is for desktop client (Swing, SWT, whatever) related  
> infrastructure.
>
> As far as commit access goes, that can probably be arranged but the  
> PPMC would need to vote on it.
>
> -David
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Si,

I guess I'm not seeing the whole picture. What would be going in there that might be usable by other webapp frameworks? Is this something generic enough that it should perhaps be part of a more AJAX specific project? In other words, even if there is something generic in OFBiz that is not dependent on the framework, OFBiz is not exactly a likely spot for people to look for such a thing. Not that we don't want it in the project, I just don't think it'll drive much of an audience if that's the hope.

I'm fine with granting Leon commit privileges for this component. If that's the direction we all want to go then yes, we should move this part of the discussion to the PPMC mailing list for a vote.

-David


Si Chen wrote:

> David,
>
> It could go into the framework/webapp/ directory.  One reason to keep  
> it outside is that the ajax tools could also be used by other webapp  
> frameworks.  The other reason is so that it could have separate  
> commit privileges than the other framework/ directories.
>
> Should I write this to the PPMC then?
>
> Si
>
>
> On Jun 10, 2006, at 12:31 PM, David E. Jones wrote:
>
>>
>> Leon Torres wrote:
>>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>>
>>> There will be new CSS, javascript and src/ libraries for handling  
>>> ajax.  To
>>> manage them, we need to have a centralized place to put  
>>> everything, especially
>>> the org.ofbiz.ajax code. This also helps keep the Ajax development
>>> tidy and focused.
>>>
>>> Since I'll be doing a lot of Ajax work in the near future, I'd  
>>> like to have
>>> commit access.  In this capacity, I will involve the community at  
>>> large so
>>> that we find the best practices and most pragmatic implementations.
>> Is there any reason to not put it in the framework/webapp  
>> component? The point of that component is to put web application  
>> specific infrastructure there, as opposed to the guiapp component  
>> which is for desktop client (Swing, SWT, whatever) related  
>> infrastructure.
>>
>> As far as commit access goes, that can probably be arranged but the  
>> PPMC would need to vote on it.
>>
>> -David
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[davidnwelton]

As someone who doesn't vote, I think some Ajax could spice things up
some, although I think prettifying up the HTML some would also be a
noble thing to do.

I'd like to remind whoever works on this stuff that many entities
could potentially hold thousands or millions of records, so perhaps
something that makes certain ajax patterns optional would be best.
Auto complete on party names might be really handy, for example, if
you're dealing with suppliers, but not with the system's users...

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Well, I guess there isn't really any other webapp per se right now,  
though it is possible (in theory) to write another webapp framework  
around OFBiz.  If that ever happened, it might be nice to have a  
separate framework/ajax directory.  Maybe I'm just preparing for too  
many eventualities.

A separate ajax directory would permit us to have a separate set of  
committers for it (say, our "Ajax gurus") versus the rest of  
framework/webapp (who'd be our "framework gurus.")  They might end up  
being different people in the community.  Again, though, I might be  
thinking too far ahead.

As long as we can commit to wherever the ajax files are, we'd be  
happy.  :)  So should I just write to ofbiz-ppmc?

Si

On Jun 13, 2006, at 11:06 AM, David E Jones wrote:

>
> Si,
>
> I guess I'm not seeing the whole picture. What would be going in  
> there that might be usable by other webapp frameworks? Is this  
> something generic enough that it should perhaps be part of a more  
> AJAX specific project? In other words, even if there is something  
> generic in OFBiz that is not dependent on the framework, OFBiz is  
> not exactly a likely spot for people to look for such a thing. Not  
> that we don't want it in the project, I just don't think it'll  
> drive much of an audience if that's the hope.
>
> I'm fine with granting Leon commit privileges for this component.  
> If that's the direction we all want to go then yes, we should move  
> this part of the discussion to the PPMC mailing list for a vote.
>
> -David
>
>
> Si Chen wrote:
>> David,
>>
>> It could go into the framework/webapp/ directory.  One reason to keep
>> it outside is that the ajax tools could also be used by other webapp
>> frameworks.  The other reason is so that it could have separate
>> commit privileges than the other framework/ directories.
>>
>> Should I write this to the PPMC then?
>>
>> Si
>>
>>
>> On Jun 10, 2006, at 12:31 PM, David E. Jones wrote:
>>
>>>
>>> Leon Torres wrote:
>>>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>>>
>>>> There will be new CSS, javascript and src/ libraries for handling
>>>> ajax.  To
>>>> manage them, we need to have a centralized place to put
>>>> everything, especially
>>>> the org.ofbiz.ajax code. This also helps keep the Ajax development
>>>> tidy and focused.
>>>>
>>>> Since I'll be doing a lot of Ajax work in the near future, I'd
>>>> like to have
>>>> commit access.  In this capacity, I will involve the community at
>>>> large so
>>>> that we find the best practices and most pragmatic implementations.
>>> Is there any reason to not put it in the framework/webapp
>>> component? The point of that component is to put web application
>>> specific infrastructure there, as opposed to the guiapp component
>>> which is for desktop client (Swing, SWT, whatever) related
>>> infrastructure.
>>>
>>> As far as commit access goes, that can probably be arranged but the
>>> PPMC would need to vote on it.
>>>
>>> -David
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

I would also like to point out that it is important to choose the AJAX
framework to use with OFBiz. Of course, we can have multiple frameworks, but
in order to really benefit from each other's work, we should agree on one
(at most two). I would highly recommend a discussion on frameworks.

Regards,
Vinay Agarwal


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Si Chen
Sent: Tuesday, June 13, 2006 1:05 PM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Proposal for Ajax enhanced OFbiz

Well, I guess there isn't really any other webapp per se right now, though
it is possible (in theory) to write another webapp framework around OFBiz.
If that ever happened, it might be nice to have a separate framework/ajax
directory.  Maybe I'm just preparing for too many eventualities.

A separate ajax directory would permit us to have a separate set of
committers for it (say, our "Ajax gurus") versus the rest of
framework/webapp (who'd be our "framework gurus.")  They might end up being
different people in the community.  Again, though, I might be thinking too
far ahead.

As long as we can commit to wherever the ajax files are, we'd be happy.  :)
So should I just write to ofbiz-ppmc?

Si

On Jun 13, 2006, at 11:06 AM, David E Jones wrote:

>
> Si,
>
> I guess I'm not seeing the whole picture. What would be going in there
> that might be usable by other webapp frameworks? Is this something
> generic enough that it should perhaps be part of a more AJAX specific
> project? In other words, even if there is something generic in OFBiz
> that is not dependent on the framework, OFBiz is not exactly a likely
> spot for people to look for such a thing. Not that we don't want it in
> the project, I just don't think it'll drive much of an audience if
> that's the hope.
>
> I'm fine with granting Leon commit privileges for this component.  
> If that's the direction we all want to go then yes, we should move
> this part of the discussion to the PPMC mailing list for a vote.
>
> -David
>
>
> Si Chen wrote:
>> David,
>>
>> It could go into the framework/webapp/ directory.  One reason to keep
>> it outside is that the ajax tools could also be used by other webapp
>> frameworks.  The other reason is so that it could have separate
>> commit privileges than the other framework/ directories.
>>
>> Should I write this to the PPMC then?
>>
>> Si
>>
>>
>> On Jun 10, 2006, at 12:31 PM, David E. Jones wrote:
>>
>>>
>>> Leon Torres wrote:
>>>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>>>
>>>> There will be new CSS, javascript and src/ libraries for handling
>>>> ajax.  To manage them, we need to have a centralized place to put
>>>> everything, especially the org.ofbiz.ajax code. This also helps
>>>> keep the Ajax development tidy and focused.
>>>>
>>>> Since I'll be doing a lot of Ajax work in the near future, I'd like
>>>> to have commit access.  In this capacity, I will involve the
>>>> community at large so that we find the best practices and most
>>>> pragmatic implementations.
>>> Is there any reason to not put it in the framework/webapp component?
>>> The point of that component is to put web application specific
>>> infrastructure there, as opposed to the guiapp component which is
>>> for desktop client (Swing, SWT, whatever) related infrastructure.
>>>
>>> As far as commit access goes, that can probably be arranged but the
>>> PPMC would need to vote on it.
>>>
>>> -David
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Yes, I agree.  That's the first thing we should do.  A common ajax/  
repository allows us to standardize for OFBIZ.



On Jun 13, 2006, at 3:02 PM, Vinay Agarwal wrote:

> I would also like to point out that it is important to choose the AJAX
> framework to use with OFBiz. Of course, we can have multiple  
> frameworks, but
> in order to really benefit from each other's work, we should agree  
> on one
> (at most two). I would highly recommend a discussion on frameworks.
>
> Regards,
> Vinay Agarwal
>
>
> -----Original Message-----
> From: [hidden email] [mailto:dev-
> [hidden email]] On
> Behalf Of Si Chen
> Sent: Tuesday, June 13, 2006 1:05 PM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Proposal for Ajax enhanced OFbiz
>
> Well, I guess there isn't really any other webapp per se right now,  
> though
> it is possible (in theory) to write another webapp framework around  
> OFBiz.
> If that ever happened, it might be nice to have a separate  
> framework/ajax
> directory.  Maybe I'm just preparing for too many eventualities.
>
> A separate ajax directory would permit us to have a separate set of
> committers for it (say, our "Ajax gurus") versus the rest of
> framework/webapp (who'd be our "framework gurus.")  They might end  
> up being
> different people in the community.  Again, though, I might be  
> thinking too
> far ahead.
>
> As long as we can commit to wherever the ajax files are, we'd be  
> happy.  :)
> So should I just write to ofbiz-ppmc?
>
> Si
>
> On Jun 13, 2006, at 11:06 AM, David E Jones wrote:
>
>>
>> Si,
>>
>> I guess I'm not seeing the whole picture. What would be going in  
>> there
>> that might be usable by other webapp frameworks? Is this something
>> generic enough that it should perhaps be part of a more AJAX specific
>> project? In other words, even if there is something generic in OFBiz
>> that is not dependent on the framework, OFBiz is not exactly a likely
>> spot for people to look for such a thing. Not that we don't want  
>> it in
>> the project, I just don't think it'll drive much of an audience if
>> that's the hope.
>>
>> I'm fine with granting Leon commit privileges for this component.
>> If that's the direction we all want to go then yes, we should move
>> this part of the discussion to the PPMC mailing list for a vote.
>>
>> -David
>>
>>
>> Si Chen wrote:
>>> David,
>>>
>>> It could go into the framework/webapp/ directory.  One reason to  
>>> keep
>>> it outside is that the ajax tools could also be used by other webapp
>>> frameworks.  The other reason is so that it could have separate
>>> commit privileges than the other framework/ directories.
>>>
>>> Should I write this to the PPMC then?
>>>
>>> Si
>>>
>>>
>>> On Jun 10, 2006, at 12:31 PM, David E. Jones wrote:
>>>
>>>>
>>>> Leon Torres wrote:
>>>>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>>>>
>>>>> There will be new CSS, javascript and src/ libraries for handling
>>>>> ajax.  To manage them, we need to have a centralized place to put
>>>>> everything, especially the org.ofbiz.ajax code. This also helps
>>>>> keep the Ajax development tidy and focused.
>>>>>
>>>>> Since I'll be doing a lot of Ajax work in the near future, I'd  
>>>>> like
>>>>> to have commit access.  In this capacity, I will involve the
>>>>> community at large so that we find the best practices and most
>>>>> pragmatic implementations.
>>>> Is there any reason to not put it in the framework/webapp  
>>>> component?
>>>> The point of that component is to put web application specific
>>>> infrastructure there, as opposed to the guiapp component which is
>>>> for desktop client (Swing, SWT, whatever) related infrastructure.
>>>>
>>>> As far as commit access goes, that can probably be arranged but the
>>>> PPMC would need to vote on it.
>>>>
>>>> -David
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi,

this is an interesting discussion and I'd like to see some of the Ajax
code in action in OFBiz very soon.
I still have not played with Ajax and so I've not a clear understanding
of what kind of integration we will need to implement in the framework.
However, I agree with Vinay, before starting to work on a new component
or inside an existing one in svn, I think we should take a decision
about the Ajax framework to use with OFBiz.
There are some developers in this list that did some tests with this,
now I think that the next steps should be:

1) prepare a list of Ajax toolkits (with Apache compatible licenses)
with pros and cons
2) make a few integration tests over them off-svn server: it would be
really nice if each developer could provide an extended custom component
(that can be dropped in the hot-deploy) with a simple Ajax exercise
based on an Ajax framework
3) compare the results, comment on them and choose the best framework
4) add it somewhere in SVN and start working on it

About granting commit access to Leon for his work on the AJAX
integration: I know he is a skilled developer and also that he is in
close contact with Si Chen - a wise adviser :-) - and so for me it would
be ok.

Jacopo
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

I guess I just don't see "AJAX" (or AJAJSON as the case may be) as that big of a deal. In fact, the most significant part of the effort will be JavaScript and DHTML stuff that runs on the client side, with a few supporting things on the server side.

In other words, it's not that much different in scope from what already exists, just an extension to it, so I really don't think an AJAX component is necessary and the distinction between the webapp and ajax component would be confusing.

Perhaps more importantly over time AJAX will become as meaningless as most similarly overused acronyms, and perhaps be little more than a somewhat embarrassing representation of the era where this category of functionality was first pushed forward.... ;)

-David


Si Chen wrote:

> Well, I guess there isn't really any other webapp per se right now,  
> though it is possible (in theory) to write another webapp framework  
> around OFBiz.  If that ever happened, it might be nice to have a  
> separate framework/ajax directory.  Maybe I'm just preparing for too  
> many eventualities.
>
> A separate ajax directory would permit us to have a separate set of  
> committers for it (say, our "Ajax gurus") versus the rest of  
> framework/webapp (who'd be our "framework gurus.")  They might end up  
> being different people in the community.  Again, though, I might be  
> thinking too far ahead.
>
> As long as we can commit to wherever the ajax files are, we'd be  
> happy.  :)  So should I just write to ofbiz-ppmc?
>
> Si
>
> On Jun 13, 2006, at 11:06 AM, David E Jones wrote:
>
>> Si,
>>
>> I guess I'm not seeing the whole picture. What would be going in  
>> there that might be usable by other webapp frameworks? Is this  
>> something generic enough that it should perhaps be part of a more  
>> AJAX specific project? In other words, even if there is something  
>> generic in OFBiz that is not dependent on the framework, OFBiz is  
>> not exactly a likely spot for people to look for such a thing. Not  
>> that we don't want it in the project, I just don't think it'll  
>> drive much of an audience if that's the hope.
>>
>> I'm fine with granting Leon commit privileges for this component.  
>> If that's the direction we all want to go then yes, we should move  
>> this part of the discussion to the PPMC mailing list for a vote.
>>
>> -David
>>
>>
>> Si Chen wrote:
>>> David,
>>>
>>> It could go into the framework/webapp/ directory.  One reason to keep
>>> it outside is that the ajax tools could also be used by other webapp
>>> frameworks.  The other reason is so that it could have separate
>>> commit privileges than the other framework/ directories.
>>>
>>> Should I write this to the PPMC then?
>>>
>>> Si
>>>
>>>
>>> On Jun 10, 2006, at 12:31 PM, David E. Jones wrote:
>>>
>>>> Leon Torres wrote:
>>>>> 1)  Create a place to collect all Ajax files:  framework/ajax
>>>>>
>>>>> There will be new CSS, javascript and src/ libraries for handling
>>>>> ajax.  To
>>>>> manage them, we need to have a centralized place to put
>>>>> everything, especially
>>>>> the org.ofbiz.ajax code. This also helps keep the Ajax development
>>>>> tidy and focused.
>>>>>
>>>>> Since I'll be doing a lot of Ajax work in the near future, I'd
>>>>> like to have
>>>>> commit access.  In this capacity, I will involve the community at
>>>>> large so
>>>>> that we find the best practices and most pragmatic implementations.
>>>> Is there any reason to not put it in the framework/webapp
>>>> component? The point of that component is to put web application
>>>> specific infrastructure there, as opposed to the guiapp component
>>>> which is for desktop client (Swing, SWT, whatever) related
>>>> infrastructure.
>>>>
>>>> As far as commit access goes, that can probably be arranged but the
>>>> PPMC would need to vote on it.
>>>>
>>>> -David
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

It's probably also a good idea to list what the requirements for AJAX
are.

So far no one really seems to be saying what they want AJAX for. It
seems that a solid convincing reason should form the backbone of a plan
to integrate a new technology...

Do we want...
- auto completes
- form submits
- live tables (like the openrico thing)
- other stuff I can't think of...

Since we're at the "blue sky thinking" phase still (I think), here's an
off the wall thought. Would it be better if we had our own AJAX library
that could render Form Widgets?
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

> It's probably also a good idea to list what the requirements for AJAX
> are.
>
> So far no one really seems to be saying what they want AJAX for. It
> seems that a solid convincing reason should form the backbone of a plan
> to integrate a new technology...
>
> Do we want...
> - auto completes
> - form submits
> - live tables (like the openrico thing)
> - other stuff I can't think of...
>
> Since we're at the "blue sky thinking" phase still (I think), here's an
> off the wall thought. Would it be better if we had our own AJAX library
> that could render Form Widgets?

*TreeView* and other such widgets ...

Why ? Mmm are you serious ?

Jacques


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

Jacques,

> Why ? Mmm are you serious ?

Heh, I thought I might get a response like that :-)

It seems that to take advantage of any Ajax stuff properly, it would
require adding stuff to the Form Widgets e.g. <input
ajax="autocomplete" />, So I got to thinking perhaps JS could actually
render these, no reason why not! - Apart from all the work involved!

It's not a well formed idea, I was just hoping that if I mentioned it,
someone would either see the value of it, or tell me to shut up!
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev