Discussion: Ajax Development

[Adrian Crum]

Since there seems to be some interest in Ajax development, and since
there seems to be several parallel Ajax development efforts, perhaps now
is a good time to come up with a coordinated plan for future Ajax
development.

I'll start things off by reviewing what we've discussed so far and what
work has been contributed so far. Everyone is welcome to join in and
offer suggestions and ideas!

1. The screen widget XML code used for Ajax support should be rendering
format agnostic and shouldn't tie the XML to a specific third party library.

2. Screen widgets should still output usable HTML when the user has
JavaScript disabled. In other words, an Ajax-enabled page should still
function properly with JavaScript turned off.

3. As much as possible, use new widget elements for Ajax support,
instead of new attributes.

I discovered this while working on the Ajax code that was already in
place. Having a widget attribute allows for only one Ajax event, where
more than one Ajax event may be desired. A good example is the Ajax
Example page in the Example component - two areas of the screen are
updated asynchronously when a new item is added.

I created two new widget elements: <on-event-update-area> for the form
widget, and <on-field-event-update-area> for the field elements. The
number of elements used in a form widget is unlimited, so any number of
Ajax events can be fired.

4. Decouple the widget Java code from the third party Ajax library via a
JavaScript "connector." I added ajaxXxxx functions to the selectall.js
file to do that. We're using the Prototype Ajax library now, but should
we decide to change to another library in the future, we only have to
rewrite the ajaxXxxx functions in selectall.js. It will be a simple
change to make.

--------------------

Here is the current screen widget Ajax support:

1. <container> elements can be updated periodically.
2. <form> elements can update screen areas asynchronously.
3. Text input fields can have server-side autocompletion.

There are two things I would like to see added:

1. A date/time input control that has drop-down controls for each field
(year, month, day, etc). As each drop-down is changed, the others are
updated with valid choices. The valid choices would depend upon the
user's locale.

2. "Smart" table headers that, when clicked, change the sort order of
the table.

--------------------

That's it so far.

What new features should be added? Where do we go from here? Who wants
to help?

-Adrian

[Bruno Busco]

Adrian,
I cannot resist to your invitation to express a couple of point from my wish
list:

1) In the "Smart" table header I would like to see the possibility to change
the column order, to remove a column, to add a column selecting the field to
be displayed from a list of available fields.
The table configuration should be saved for the user and retrieved to the
next user login.
This feature is available in the JIRA issue navigator.

2) For every table in ofbiz a first column with a check button should let
the user to select a subset of the displayed rows and run a command selected
from a combo box on all the selected rows (like gmail). For commands that
need more data to be input a new screen should be displayed.

What do you think about?

-Bruno



2008/6/2 Adrian Crum <[hidden email]>:

> Since there seems to be some interest in Ajax development, and since there
> seems to be several parallel Ajax development efforts, perhaps now is a good
> time to come up with a coordinated plan for future Ajax development.
>
> I'll start things off by reviewing what we've discussed so far and what
> work has been contributed so far. Everyone is welcome to join in and offer
> suggestions and ideas!
>
> 1. The screen widget XML code used for Ajax support should be rendering
> format agnostic and shouldn't tie the XML to a specific third party library.
>
> 2. Screen widgets should still output usable HTML when the user has
> JavaScript disabled. In other words, an Ajax-enabled page should still
> function properly with JavaScript turned off.
>
> 3. As much as possible, use new widget elements for Ajax support, instead
> of new attributes.
>
> I discovered this while working on the Ajax code that was already in place.
> Having a widget attribute allows for only one Ajax event, where more than
> one Ajax event may be desired. A good example is the Ajax Example page in
> the Example component - two areas of the screen are updated asynchronously
> when a new item is added.
>
> I created two new widget elements: <on-event-update-area> for the form
> widget, and <on-field-event-update-area> for the field elements. The number
> of elements used in a form widget is unlimited, so any number of Ajax events
> can be fired.
>
> 4. Decouple the widget Java code from the third party Ajax library via a
> JavaScript "connector." I added ajaxXxxx functions to the selectall.js file
> to do that. We're using the Prototype Ajax library now, but should we decide
> to change to another library in the future, we only have to rewrite the
> ajaxXxxx functions in selectall.js. It will be a simple change to make.
>
> --------------------
>
> Here is the current screen widget Ajax support:
>
> 1. <container> elements can be updated periodically.
> 2. <form> elements can update screen areas asynchronously.
> 3. Text input fields can have server-side autocompletion.
>
> There are two things I would like to see added:
>
> 1. A date/time input control that has drop-down controls for each field
> (year, month, day, etc). As each drop-down is changed, the others are
> updated with valid choices. The valid choices would depend upon the user's
> locale.
>
> 2. "Smart" table headers that, when clicked, change the sort order of the
> table.
>
> --------------------
>
> That's it so far.
>
> What new features should be added? Where do we go from here? Who wants to
> help?
>
> -Adrian
>

[byersa]

Hi Adrian,

I started a post to your reply that talked about what I would like to see
and whatever, but as I got into it, I realized that this whole thing could
get quite messy. As soon as you do anything that is "customer facing", I
think you are going to lose people (like me) because what we do with widgets
could never approach what their specific toolkit can do. I am using nearly
the full breadth of the Dojo Toolkit and the things that have been mentioned
so far are rather small compared to the Dojo capability and I imagine the
same is true with Prototype and others.

I just think the work of trying to add some common features that can be
supported by all tool kits will not be useful because it will never go far
enough. And it will be a lot of work that will not add much advantage over
just working in the toolkit (this is particularly true of Dojo since it has
an XML markup language that lets me mix it with the widget environment
within .ftl files.)

I am thinking that the effort should stick to things that would be useful in
an admin environment and things that could be done without any toolkit. The
thing that comes to mind is just allowing lookups as embedded panes (divs)
instead of opening a window. The date/time control is another useful one.
Sortable columns starts pushing my dividing line of doing stuff that does
not require a particular toolkit, but it would be useful in an admin
environment.

I guess I would just advocate not going too much farther than those
guidelines allow, but then I wasn't thinking that way an hour ago.

-Al

[byersa]

I would like to add that I do not think ofbiz can ignore the rich internet
app technology for long, but maybe it would be better to wait for a shake
out till there are 2-3 clear leaders and then choosing the best one and not
try to be compatible with others. In the end I think it would make ofbiz
more productive then trying to find common ground.

-Al

[Adrian Crum]

Al Byers wrote:
> I started a post to your reply that talked about what I would like to see
> and whatever, but as I got into it, I realized that this whole thing could
> get quite messy. As soon as you do anything that is "customer facing", I
> think you are going to lose people (like me) because what we do with widgets
> could never approach what their specific toolkit can do.

Well, the discussion is about adding Ajax capabilities to the screen
widgets - which aren't usually used in customer facing websites.

I picture this effort as something simpler than the type of work you
described. Let's add some bells and whistles to the screen widgets. The
screen widget XML to do it shouldn't be overly complicated. In other
words, add some fancy embellishments without a lot of extra coding.

> I just think the work of trying to add some common features that can be
> supported by all tool kits will not be useful because it will never go far
> enough. And it will be a lot of work that will not add much advantage over
> just working in the toolkit (this is particularly true of Dojo since it has
> an XML markup language that lets me mix it with the widget environment
> within .ftl files.)

There has been talk of doing that with Dojo and another XML based
library (I can't remember the name - Jacopo mentioned it).

Thanks for the reply - I appreciate your input!

-Adrian

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> Al Byers wrote:
>> I started a post to your reply that talked about what I would like to see
>> and whatever, but as I got into it, I realized that this whole thing could
>> get quite messy. As soon as you do anything that is "customer facing", I
>> think you are going to lose people (like me) because what we do with widgets
>> could never approach what their specific toolkit can do.
>
> Well, the discussion is about adding Ajax capabilities to the screen
> widgets - which aren't usually used in customer facing websites.
>
> I picture this effort as something simpler than the type of work you
> described. Let's add some bells and whistles to the screen widgets. The
> screen widget XML to do it shouldn't be overly complicated. In other
> words, add some fancy embellishments without a lot of extra coding.
>
>> I just think the work of trying to add some common features that can be
>> supported by all tool kits will not be useful because it will never go far
>> enough. And it will be a lot of work that will not add much advantage over
>> just working in the toolkit (this is particularly true of Dojo since it has
>> an XML markup language that lets me mix it with the widget environment
>> within .ftl files.)
>
> There has been talk of doing that with Dojo and another XML based
> library (I can't remember the name - Jacopo mentioned it).

I suppose you tall about Apache XAP ?

Jacques
 
> Thanks for the reply - I appreciate your input!
>
> -Adrian
>

[Anil Patel-3]

I think we should Ajax/Effects enable widgets where possible. Like,

Make Panels collapsable using Effects,
Ajax enable Tree widget,
Enhance Single form Layout to use div and css,
Use Model panel for Lookup windows,
Allow display fields to be inline editable etc.

Regards
Anil Patel




On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> Al Byers wrote:
>>> I started a post to your reply that talked about what I would like  
>>> to see
>>> and whatever, but as I got into it, I realized that this whole  
>>> thing could
>>> get quite messy. As soon as you do anything that is "customer  
>>> facing", I
>>> think you are going to lose people (like me) because what we do  
>>> with widgets
>>> could never approach what their specific toolkit can do.
>> Well, the discussion is about adding Ajax capabilities to the  
>> screen widgets - which aren't usually used in customer facing  
>> websites.
>> I picture this effort as something simpler than the type of work  
>> you described. Let's add some bells and whistles to the screen  
>> widgets. The screen widget XML to do it shouldn't be overly  
>> complicated. In other words, add some fancy embellishments without  
>> a lot of extra coding.
>>> I just think the work of trying to add some common features that  
>>> can be
>>> supported by all tool kits will not be useful because it will  
>>> never go far
>>> enough. And it will be a lot of work that will not add much  
>>> advantage over
>>> just working in the toolkit (this is particularly true of Dojo  
>>> since it has
>>> an XML markup language that lets me mix it with the widget  
>>> environment
>>> within .ftl files.)
>> There has been talk of doing that with Dojo and another XML based  
>> library (I can't remember the name - Jacopo mentioned it).
>
> I suppose you tall about Apache XAP ?
>
> Jacques
>> Thanks for the reply - I appreciate your input!
>> -Adrian
>>

[Jacopo Cappellato-3]

Here is my wish list:

1) when you select a value from a drop down box, automatically enable  
a new drop down box for the selection of further data available after  
the first selection is done; for example: you select the country, then  
you have the option to select the state-province in the country

2) when, using a lookup button you select an id (e.g. productId)  
another field (or label) is automatically populated with the  
descriptive content of the id (productName etc...)

Jacopo

On Jun 3, 2008, at 3:35 AM, Anil Patel wrote:

> I think we should Ajax/Effects enable widgets where possible. Like,
>
> Make Panels collapsable using Effects,
> Ajax enable Tree widget,
> Enhance Single form Layout to use div and css,
> Use Model panel for Lookup windows,
> Allow display fields to be inline editable etc.
>
> Regards
> Anil Patel
>
>
>
>
> On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:
>
>> From: "Adrian Crum" <[hidden email]>
>>> Al Byers wrote:
>>>> I started a post to your reply that talked about what I would  
>>>> like to see
>>>> and whatever, but as I got into it, I realized that this whole  
>>>> thing could
>>>> get quite messy. As soon as you do anything that is "customer  
>>>> facing", I
>>>> think you are going to lose people (like me) because what we do  
>>>> with widgets
>>>> could never approach what their specific toolkit can do.
>>> Well, the discussion is about adding Ajax capabilities to the  
>>> screen widgets - which aren't usually used in customer facing  
>>> websites.
>>> I picture this effort as something simpler than the type of work  
>>> you described. Let's add some bells and whistles to the screen  
>>> widgets. The screen widget XML to do it shouldn't be overly  
>>> complicated. In other words, add some fancy embellishments without  
>>> a lot of extra coding.
>>>> I just think the work of trying to add some common features that  
>>>> can be
>>>> supported by all tool kits will not be useful because it will  
>>>> never go far
>>>> enough. And it will be a lot of work that will not add much  
>>>> advantage over
>>>> just working in the toolkit (this is particularly true of Dojo  
>>>> since it has
>>>> an XML markup language that lets me mix it with the widget  
>>>> environment
>>>> within .ftl files.)
>>> There has been talk of doing that with Dojo and another XML based  
>>> library (I can't remember the name - Jacopo mentioned it).
>>
>> I suppose you tall about Apache XAP ?
>>
>> Jacques
>>> Thanks for the reply - I appreciate your input!
>>> -Adrian
>>>
>

[Anil Patel-3]

thinking on same lines, We should have a set of input boxes that get  
rendered to meet formating requirements, like

For phone number, I'll like to have a form widget that will render  
countryCode, areaCode, contactNumber input boxes in one row separated  
by some character  like "-". Similarly Date field may be required to  
be rendered in some cases. Or Credit Card numbers etc.

Regards
Anil Patel



On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote:

> Here is my wish list:
>
> 1) when you select a value from a drop down box, automatically  
> enable a new drop down box for the selection of further data  
> available after the first selection is done; for example: you select  
> the country, then you have the option to select the state-province  
> in the country
>
> 2) when, using a lookup button you select an id (e.g. productId)  
> another field (or label) is automatically populated with the  
> descriptive content of the id (productName etc...)
>
> Jacopo
>
> On Jun 3, 2008, at 3:35 AM, Anil Patel wrote:
>
>> I think we should Ajax/Effects enable widgets where possible. Like,
>>
>> Make Panels collapsable using Effects,
>> Ajax enable Tree widget,
>> Enhance Single form Layout to use div and css,
>> Use Model panel for Lookup windows,
>> Allow display fields to be inline editable etc.
>>
>> Regards
>> Anil Patel
>>
>>
>>
>>
>> On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:
>>
>>> From: "Adrian Crum" <[hidden email]>
>>>> Al Byers wrote:
>>>>> I started a post to your reply that talked about what I would  
>>>>> like to see
>>>>> and whatever, but as I got into it, I realized that this whole  
>>>>> thing could
>>>>> get quite messy. As soon as you do anything that is "customer  
>>>>> facing", I
>>>>> think you are going to lose people (like me) because what we do  
>>>>> with widgets
>>>>> could never approach what their specific toolkit can do.
>>>> Well, the discussion is about adding Ajax capabilities to the  
>>>> screen widgets - which aren't usually used in customer facing  
>>>> websites.
>>>> I picture this effort as something simpler than the type of work  
>>>> you described. Let's add some bells and whistles to the screen  
>>>> widgets. The screen widget XML to do it shouldn't be overly  
>>>> complicated. In other words, add some fancy embellishments  
>>>> without a lot of extra coding.
>>>>> I just think the work of trying to add some common features that  
>>>>> can be
>>>>> supported by all tool kits will not be useful because it will  
>>>>> never go far
>>>>> enough. And it will be a lot of work that will not add much  
>>>>> advantage over
>>>>> just working in the toolkit (this is particularly true of Dojo  
>>>>> since it has
>>>>> an XML markup language that lets me mix it with the widget  
>>>>> environment
>>>>> within .ftl files.)
>>>> There has been talk of doing that with Dojo and another XML based  
>>>> library (I can't remember the name - Jacopo mentioned it).
>>>
>>> I suppose you tall about Apache XAP ?
>>>
>>> Jacques
>>>> Thanks for the reply - I appreciate your input!
>>>> -Adrian
>>>>
>>
>

[Adrian Crum]

I've been thinking about this and I'm wondering if we need a container
element for the form and menu widgets, only have it operate more like
the section element - so you can have conditionals.

That way you could group fields or menu items together, have the group
displayed conditionally, and have them wrapped by the rendering classes
so they can be updated by Ajax calls.

-Adrian

Anil Patel wrote:

> thinking on same lines, We should have a set of input boxes that get
> rendered to meet formating requirements, like
>
> For phone number, I'll like to have a form widget that will render
> countryCode, areaCode, contactNumber input boxes in one row separated by
> some character  like "-". Similarly Date field may be required to be
> rendered in some cases. Or Credit Card numbers etc.
>
> Regards
> Anil Patel
>
>
>
> On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote:
>
>> Here is my wish list:
>>
>> 1) when you select a value from a drop down box, automatically enable
>> a new drop down box for the selection of further data available after
>> the first selection is done; for example: you select the country, then
>> you have the option to select the state-province in the country
>>
>> 2) when, using a lookup button you select an id (e.g. productId)
>> another field (or label) is automatically populated with the
>> descriptive content of the id (productName etc...)
>>
>> Jacopo
>>
>> On Jun 3, 2008, at 3:35 AM, Anil Patel wrote:
>>
>>> I think we should Ajax/Effects enable widgets where possible. Like,
>>>
>>> Make Panels collapsable using Effects,
>>> Ajax enable Tree widget,
>>> Enhance Single form Layout to use div and css,
>>> Use Model panel for Lookup windows,
>>> Allow display fields to be inline editable etc.
>>>
>>> Regards
>>> Anil Patel
>>>
>>>
>>>
>>>
>>> On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:
>>>
>>>> From: "Adrian Crum" <[hidden email]>
>>>>> Al Byers wrote:
>>>>>> I started a post to your reply that talked about what I would like
>>>>>> to see
>>>>>> and whatever, but as I got into it, I realized that this whole
>>>>>> thing could
>>>>>> get quite messy. As soon as you do anything that is "customer
>>>>>> facing", I
>>>>>> think you are going to lose people (like me) because what we do
>>>>>> with widgets
>>>>>> could never approach what their specific toolkit can do.
>>>>> Well, the discussion is about adding Ajax capabilities to the
>>>>> screen widgets - which aren't usually used in customer facing
>>>>> websites.
>>>>> I picture this effort as something simpler than the type of work
>>>>> you described. Let's add some bells and whistles to the screen
>>>>> widgets. The screen widget XML to do it shouldn't be overly
>>>>> complicated. In other words, add some fancy embellishments without
>>>>> a lot of extra coding.
>>>>>> I just think the work of trying to add some common features that
>>>>>> can be
>>>>>> supported by all tool kits will not be useful because it will
>>>>>> never go far
>>>>>> enough. And it will be a lot of work that will not add much
>>>>>> advantage over
>>>>>> just working in the toolkit (this is particularly true of Dojo
>>>>>> since it has
>>>>>> an XML markup language that lets me mix it with the widget
>>>>>> environment
>>>>>> within .ftl files.)
>>>>> There has been talk of doing that with Dojo and another XML based
>>>>> library (I can't remember the name - Jacopo mentioned it).
>>>>
>>>> I suppose you tall about Apache XAP ?
>>>>
>>>> Jacques
>>>>> Thanks for the reply - I appreciate your input!
>>>>> -Adrian
>>>>>
>>>
>>
>

[David E Jones]

In the form widget something similar to what you describe exists.  
After the field elements you can have a sort-order element which has a  
sort-field element in it for each field in the order you want it.  
Those sort-field elements can be put inside a field-group element, and  
the field-group element has the typical id and style attributes on it  
for CSS styling of a group of fields.

There are no conditions on the group, as conditions are on the  
individual fields right now, but we could add something as simple as a  
use-when attribute there or as complex as a condition element with the  
various conditional sub-elements under it like in a screen widget  
section. Unless we think those will be used a lot I like the idea of  
the use-when attribute more, BTW.

-David


On Jun 6, 2008, at 8:42 AM, Adrian Crum wrote:

> I've been thinking about this and I'm wondering if we need a  
> container element for the form and menu widgets, only have it  
> operate more like the section element - so you can have conditionals.
>
> That way you could group fields or menu items together, have the  
> group displayed conditionally, and have them wrapped by the  
> rendering classes so they can be updated by Ajax calls.
>
> -Adrian
>
> Anil Patel wrote:
>> thinking on same lines, We should have a set of input boxes that  
>> get rendered to meet formating requirements, like
>> For phone number, I'll like to have a form widget that will render  
>> countryCode, areaCode, contactNumber input boxes in one row  
>> separated by some character  like "-". Similarly Date field may be  
>> required to be rendered in some cases. Or Credit Card numbers etc.
>> Regards
>> Anil Patel
>> On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote:
>>> Here is my wish list:
>>>
>>> 1) when you select a value from a drop down box, automatically  
>>> enable a new drop down box for the selection of further data  
>>> available after the first selection is done; for example: you  
>>> select the country, then you have the option to select the state-
>>> province in the country
>>>
>>> 2) when, using a lookup button you select an id (e.g. productId)  
>>> another field (or label) is automatically populated with the  
>>> descriptive content of the id (productName etc...)
>>>
>>> Jacopo
>>>
>>> On Jun 3, 2008, at 3:35 AM, Anil Patel wrote:
>>>
>>>> I think we should Ajax/Effects enable widgets where possible. Like,
>>>>
>>>> Make Panels collapsable using Effects,
>>>> Ajax enable Tree widget,
>>>> Enhance Single form Layout to use div and css,
>>>> Use Model panel for Lookup windows,
>>>> Allow display fields to be inline editable etc.
>>>>
>>>> Regards
>>>> Anil Patel
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:
>>>>
>>>>> From: "Adrian Crum" <[hidden email]>
>>>>>> Al Byers wrote:
>>>>>>> I started a post to your reply that talked about what I would  
>>>>>>> like to see
>>>>>>> and whatever, but as I got into it, I realized that this whole  
>>>>>>> thing could
>>>>>>> get quite messy. As soon as you do anything that is "customer  
>>>>>>> facing", I
>>>>>>> think you are going to lose people (like me) because what we  
>>>>>>> do with widgets
>>>>>>> could never approach what their specific toolkit can do.
>>>>>> Well, the discussion is about adding Ajax capabilities to the  
>>>>>> screen widgets - which aren't usually used in customer facing  
>>>>>> websites.
>>>>>> I picture this effort as something simpler than the type of  
>>>>>> work you described. Let's add some bells and whistles to the  
>>>>>> screen widgets. The screen widget XML to do it shouldn't be  
>>>>>> overly complicated. In other words, add some fancy  
>>>>>> embellishments without a lot of extra coding.
>>>>>>> I just think the work of trying to add some common features  
>>>>>>> that can be
>>>>>>> supported by all tool kits will not be useful because it will  
>>>>>>> never go far
>>>>>>> enough. And it will be a lot of work that will not add much  
>>>>>>> advantage over
>>>>>>> just working in the toolkit (this is particularly true of Dojo  
>>>>>>> since it has
>>>>>>> an XML markup language that lets me mix it with the widget  
>>>>>>> environment
>>>>>>> within .ftl files.)
>>>>>> There has been talk of doing that with Dojo and another XML  
>>>>>> based library (I can't remember the name - Jacopo mentioned it).
>>>>>
>>>>> I suppose you tall about Apache XAP ?
>>>>>
>>>>> Jacques
>>>>>> Thanks for the reply - I appreciate your input!
>>>>>> -Adrian
>>>>>>
>>>>
>>>

[Adrian Crum]

David,

Thanks for the info. I was looking at the field-group element yesterday
but I wasn't sure how it was used. Your explanation helps.

I don't have a good example of using conditionals on groups of fields,
but the menu widget would be a prime candidate. Think of the application
menu and how groups of menu items are displayed depending on whether or
not the user is logged in. There are other places where groups of menu
items are dependent upon the user's permissions. Having one condition
controlling the group would be better than having the same condition
applied to every menu item.

-Adrian

David E Jones wrote:

>
> In the form widget something similar to what you describe exists. After
> the field elements you can have a sort-order element which has a
> sort-field element in it for each field in the order you want it. Those
> sort-field elements can be put inside a field-group element, and the
> field-group element has the typical id and style attributes on it for
> CSS styling of a group of fields.
>
> There are no conditions on the group, as conditions are on the
> individual fields right now, but we could add something as simple as a
> use-when attribute there or as complex as a condition element with the
> various conditional sub-elements under it like in a screen widget
> section. Unless we think those will be used a lot I like the idea of the
> use-when attribute more, BTW.
>
> -David
>
>
> On Jun 6, 2008, at 8:42 AM, Adrian Crum wrote:
>
>> I've been thinking about this and I'm wondering if we need a container
>> element for the form and menu widgets, only have it operate more like
>> the section element - so you can have conditionals.
>>
>> That way you could group fields or menu items together, have the group
>> displayed conditionally, and have them wrapped by the rendering
>> classes so they can be updated by Ajax calls.
>>
>> -Adrian
>>
>> Anil Patel wrote:
>>> thinking on same lines, We should have a set of input boxes that get
>>> rendered to meet formating requirements, like
>>> For phone number, I'll like to have a form widget that will render
>>> countryCode, areaCode, contactNumber input boxes in one row separated
>>> by some character  like "-". Similarly Date field may be required to
>>> be rendered in some cases. Or Credit Card numbers etc.
>>> Regards
>>> Anil Patel
>>> On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote:
>>>> Here is my wish list:
>>>>
>>>> 1) when you select a value from a drop down box, automatically
>>>> enable a new drop down box for the selection of further data
>>>> available after the first selection is done; for example: you select
>>>> the country, then you have the option to select the state-province
>>>> in the country
>>>>
>>>> 2) when, using a lookup button you select an id (e.g. productId)
>>>> another field (or label) is automatically populated with the
>>>> descriptive content of the id (productName etc...)
>>>>
>>>> Jacopo
>>>>
>>>> On Jun 3, 2008, at 3:35 AM, Anil Patel wrote:
>>>>
>>>>> I think we should Ajax/Effects enable widgets where possible. Like,
>>>>>
>>>>> Make Panels collapsable using Effects,
>>>>> Ajax enable Tree widget,
>>>>> Enhance Single form Layout to use div and css,
>>>>> Use Model panel for Lookup windows,
>>>>> Allow display fields to be inline editable etc.
>>>>>
>>>>> Regards
>>>>> Anil Patel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:
>>>>>
>>>>>> From: "Adrian Crum" <[hidden email]>
>>>>>>> Al Byers wrote:
>>>>>>>> I started a post to your reply that talked about what I would
>>>>>>>> like to see
>>>>>>>> and whatever, but as I got into it, I realized that this whole
>>>>>>>> thing could
>>>>>>>> get quite messy. As soon as you do anything that is "customer
>>>>>>>> facing", I
>>>>>>>> think you are going to lose people (like me) because what we do
>>>>>>>> with widgets
>>>>>>>> could never approach what their specific toolkit can do.
>>>>>>> Well, the discussion is about adding Ajax capabilities to the
>>>>>>> screen widgets - which aren't usually used in customer facing
>>>>>>> websites.
>>>>>>> I picture this effort as something simpler than the type of work
>>>>>>> you described. Let's add some bells and whistles to the screen
>>>>>>> widgets. The screen widget XML to do it shouldn't be overly
>>>>>>> complicated. In other words, add some fancy embellishments
>>>>>>> without a lot of extra coding.
>>>>>>>> I just think the work of trying to add some common features that
>>>>>>>> can be
>>>>>>>> supported by all tool kits will not be useful because it will
>>>>>>>> never go far
>>>>>>>> enough. And it will be a lot of work that will not add much
>>>>>>>> advantage over
>>>>>>>> just working in the toolkit (this is particularly true of Dojo
>>>>>>>> since it has
>>>>>>>> an XML markup language that lets me mix it with the widget
>>>>>>>> environment
>>>>>>>> within .ftl files.)
>>>>>>> There has been talk of doing that with Dojo and another XML based
>>>>>>> library (I can't remember the name - Jacopo mentioned it).
>>>>>>
>>>>>> I suppose you tall about Apache XAP ?
>>>>>>
>>>>>> Jacques
>>>>>>> Thanks for the reply - I appreciate your input!
>>>>>>> -Adrian
>>>>>>>
>>>>>
>>>>
>
>

[Harmeet Bedi]

One thing that may be worth considering is GWT.

We have been evaluating GWT internally and a conclusion we are reaching
is that it is significantly more efficient and
to develop and maintain with GWT that Ajax, JS, dhtml.
The best way to do get into GWT would be create value objects(column
names become class attributes) from ofbiz entity source.

We have also been evaluating using RIA. A clear winner for us was Flex.
There have been issues with it but.. exposing entities through XStream
was an approach we were thinking of going into.

I realize this is a bit abstract... but  for ofbiz i feel, jumping over
Ajax libraries to GWT may  give good benefit.

Harmeet

[BJ Freeman]

what you gain in upfront design is lose in maintainence.
if an entity is updated, it will not show without using entity aware
routines.
however if you can write a GWT handler, then it can integrate with ofbiz
nicey.

Harmeet Bedi sent the following on 8/13/2008 3:01 PM:

> One thing that may be worth considering is GWT.
>
> We have been evaluating GWT internally and a conclusion we are reaching
> is that it is significantly more efficient and
> to develop and maintain with GWT that Ajax, JS, dhtml.
> The best way to do get into GWT would be create value objects(column
> names become class attributes) from ofbiz entity source.
>
> We have also been evaluating using RIA. A clear winner for us was Flex.
> There have been issues with it but.. exposing entities through XStream
> was an approach we were thinking of going into.
>
> I realize this is a bit abstract... but  for ofbiz i feel, jumping over
> Ajax libraries to GWT may  give good benefit.
>
> Harmeet
>
>
>