Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@yahoo.com>]

In order to accommodate 3rd party rendering libraries (Ajax, Dojo, etc) in the screen widgets, we need to discuss how that support will appear in the screen widget XML files.

I'll start things off with a suggestion I made in another thread. Everyone is welcome to join in and offer their ideas. When we reach an agreement, we can submit the results to Jira and begin building it out.

I was thinking we could simply extend the existing widgets with additional attributes. The new attributes would pass 3rd party specific data to the rendering classes. The new attributes are ignored by rendering classes that don't need them. All rendering classes render all widgets in some form - some rendering classes might have additional bells and whistles based upon the additional attributes, while others downgrade gracefully and still provide a usable screen rendering.


So, the widget XML would look something like this:


<container id="some-id" style="some-style" dojo="some Dojo data" ajax="some Ajax data" foo="some foo data">
  ...
</container>

The additional attributes could be applied to any screen widget element, not just the container element.

The advantage I see to this approach is it is fully backwards compatible. We can add attributes to any screen widget element without breaking existing rendering code.

That's it. Like I said, please add your ideas.

-Adrian





       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacques Le Roux <ja...@les7arts.com>]

Sounds like a good idea to me

Jacques

From: "Adrian Crum" <ad...@hlmksw.com>
> I'm resurrecting this thread because I've spent some time looking into 
> the whole third party rendering library support idea and I think I have 
> a simple solution.
> 
> I thought about David's suggestion of having new widgets that are 
> effects based. I don't think that will be a good strategy because not 
> all browsers will have javascript enabled - which would render those 
> widgets useless.
> 
> A better approach I would like to propose is to use the Prototype 
> javascript library in combination with EXISTING widgets to improve their 
> response and functionality. The widget rendering code would detect if 
> the browser supports javascript, and output the correct HTML to 
> accommodate the browser.
> 
> Instead of a "live-form" widget, the existing form widget would detect 
> browser support, and render an improved form if the browser supports it. 
> The current paginated tables would use Ajax calls to scroll through 
> pages instead of refreshing the whole screen.
> 
> Basically, I'd like to see the cool effects and improved response 
> implemented without any additional work on the widget XML files.
> 
> What do you think?
> 
> -Adrian
> 
> David E Jones wrote:
>> 
>> I guess this is a continuation of the discussion in the thread "uilabels 
>> and screenlet widget", and is related somewhat to part of the stuff in 
>> issue OFBIZ-1648.
>> 
>> The general goal of the widgets is simple: no platform specific 
>> artifacts. Unfortunately this isn't entirely possible, which is why we 
>> have a very big and ugly "platform-specific" tag to delineate things 
>> that are not generic and provide for the possible of having alternative 
>> platform things specified together so that when rendering for a 
>> different target the appropriate option can be selected.
>> 
>> As far as that applies to this topic, I'd say the best approach is to 
>> never have any element or attribute called "dojo" or "ajax" or "rico" or 
>> anything. In the dojo attribute for the container elements, I'm not sure 
>> what you'd propose to put in it, ie the "some Dojo data", but in general 
>> I'd prefer to never have anything that is so dependent on a particular 
>> underlying technology, the widget artifacts gain efficiency by their 
>> focus on different effects, with the underlying software taking care of 
>> the "causes", or rather how the effects are brought about.
>> 
>> In other words while we wouldn't want elements that have anything to do 
>> with "dojo" or "openrico" we would want elements to describe the effects 
>> from those libraries we'd like to have available through the widget, and 
>> the most appropriate is probably the Form Widget with different form and 
>> field types (though some would certainly go elsewhere and are not form 
>> related).
>> 
>> Examples of that would be a new form type like "live-grid" or a new form 
>> field type like "live-combobox" (or "dynamic-combobox" or 
>> "server-side-combobox" or something). If we add elements like that then 
>> it doesn't matter which AJAX library we use underneath and generate 
>> HTML/etc for, and we can change libraries without requiring any change 
>> to the higher level artifacts, like the form definitions.
>> 
>> -David
>> 
>> 
>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>> 
>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo, 
>>> etc) in the screen widgets, we need to discuss how that support will 
>>> appear in the screen widget XML files.
>>>
>>> I'll start things off with a suggestion I made in another thread. 
>>> Everyone is welcome to join in and offer their ideas. When we reach an 
>>> agreement, we can submit the results to Jira and begin building it out.
>>>
>>> I was thinking we could simply extend the existing widgets with 
>>> additional attributes. The new attributes would pass 3rd party 
>>> specific data to the rendering classes. The new attributes are ignored 
>>> by rendering classes that don't need them. All rendering classes 
>>> render all widgets in some form - some rendering classes might have 
>>> additional bells and whistles based upon the additional attributes, 
>>> while others downgrade gracefully and still provide a usable screen 
>>> rendering.
>>>
>>>
>>> So, the widget XML would look something like this:
>>>
>>>
>>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>>> ajax="some Ajax data" foo="some foo data">
>>>  ...
>>> </container>
>>>
>>> The additional attributes could be applied to any screen widget 
>>> element, not just the container element.
>>>
>>> The advantage I see to this approach is it is fully backwards 
>>> compatible. We can add attributes to any screen widget element without 
>>> breaking existing rendering code.
>>>
>>> That's it. Like I said, please add your ideas.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------
>>> Looking for last minute shopping deals?  Find them fast with Yahoo! 
>>> Search.
>> 
>> 
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacques Le Roux <ja...@les7arts.com>]

Also it seems that Ajax promise of degrading gracefully is not yet reached (and will maybe never)
http://blogs.pathf.com/agileajax/2006/09/degrading_grace.html
But (in the meantime?) we could use what is already existing and described in these articles

Jacques

From: "David E Jones" <jo...@hotwaxmedia.com>
> 
> Adrian,
> 
> This sounds great for the elements that have some sort of natural JS/ 
> AJAX extension that doesn't change what the form means or offers to  
> the user but instead just improves the user experience and/or  
> efficiency.
> 
> With cases like I agree it would be great, and a REALLY cool feature,  
> to upgrade automatically and not require form changes or anything.
> 
> However, there are many cases where we can't automatically add JS/AJAX  
> extensions, but instead they represent a possible widget that is  
> different enough from the concept behind any of the existing form  
> field types that it would be weird to piggy back the functionality and  
> try to automatically shoe-horn it into the existing functionality.
> 
> Some of the stuff I played with recently and added, like an auto- 
> refresh on a screen container, is not something we would want to  
> automatically turn on. The other one I added recently, to submit a  
> form in the background and not refresh the page, is also something  
> that I don't think we would want to automatically turn on.
> 
> So, yes, I agree we should add some of the automatic extensions that  
> we can and it would be a really cool set of new features.
> 
> Stepping back to the original thingy, how does using alternate  
> HtmlFormRenderer classes help with this? Maybe you're not still  
> considering that, but I'd say if we did default fancy things (which  
> again, I love the idea of), we should just do those all the time  
> unless, like you wrote, the browser identifier is clearly one that  
> won't support it (some of that might need to be client side too  
> though... I'm not sure about all of the nuances there).
> 
> -David
> 
> 
> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
> 
>> I'm resurrecting this thread because I've spent some time looking  
>> into the whole third party rendering library support idea and I  
>> think I have a simple solution.
>>
>> I thought about David's suggestion of having new widgets that are  
>> effects based. I don't think that will be a good strategy because  
>> not all browsers will have javascript enabled - which would render  
>> those widgets useless.
>>
>> A better approach I would like to propose is to use the Prototype  
>> javascript library in combination with EXISTING widgets to improve  
>> their response and functionality. The widget rendering code would  
>> detect if the browser supports javascript, and output the correct  
>> HTML to accommodate the browser.
>>
>> Instead of a "live-form" widget, the existing form widget would  
>> detect browser support, and render an improved form if the browser  
>> supports it. The current paginated tables would use Ajax calls to  
>> scroll through pages instead of refreshing the whole screen.
>>
>> Basically, I'd like to see the cool effects and improved response  
>> implemented without any additional work on the widget XML files.
>>
>> What do you think?
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> I guess this is a continuation of the discussion in the thread  
>>> "uilabels and screenlet widget", and is related somewhat to part of  
>>> the stuff in issue OFBIZ-1648.
>>> The general goal of the widgets is simple: no platform specific  
>>> artifacts. Unfortunately this isn't entirely possible, which is why  
>>> we have a very big and ugly "platform-specific" tag to delineate  
>>> things that are not generic and provide for the possible of having  
>>> alternative platform things specified together so that when  
>>> rendering for a different target the appropriate option can be  
>>> selected.
>>> As far as that applies to this topic, I'd say the best approach is  
>>> to never have any element or attribute called "dojo" or "ajax" or  
>>> "rico" or anything. In the dojo attribute for the container  
>>> elements, I'm not sure what you'd propose to put in it, ie the  
>>> "some Dojo data", but in general I'd prefer to never have anything  
>>> that is so dependent on a particular underlying technology, the  
>>> widget artifacts gain efficiency by their focus on different  
>>> effects, with the underlying software taking care of the "causes",  
>>> or rather how the effects are brought about.
>>> In other words while we wouldn't want elements that have anything  
>>> to do with "dojo" or "openrico" we would want elements to describe  
>>> the effects from those libraries we'd like to have available  
>>> through the widget, and the most appropriate is probably the Form  
>>> Widget with different form and field types (though some would  
>>> certainly go elsewhere and are not form related).
>>> Examples of that would be a new form type like "live-grid" or a new  
>>> form field type like "live-combobox" (or "dynamic-combobox" or  
>>> "server-side-combobox" or something). If we add elements like that  
>>> then it doesn't matter which AJAX library we use underneath and  
>>> generate HTML/etc for, and we can change libraries without  
>>> requiring any change to the higher level artifacts, like the form  
>>> definitions.
>>> -David
>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo,  
>>>> etc) in the screen widgets, we need to discuss how that support  
>>>> will appear in the screen widget XML files.
>>>>
>>>> I'll start things off with a suggestion I made in another thread.  
>>>> Everyone is welcome to join in and offer their ideas. When we  
>>>> reach an agreement, we can submit the results to Jira and begin  
>>>> building it out.
>>>>
>>>> I was thinking we could simply extend the existing widgets with  
>>>> additional attributes. The new attributes would pass 3rd party  
>>>> specific data to the rendering classes. The new attributes are  
>>>> ignored by rendering classes that don't need them. All rendering  
>>>> classes render all widgets in some form - some rendering classes  
>>>> might have additional bells and whistles based upon the additional  
>>>> attributes, while others downgrade gracefully and still provide a  
>>>> usable screen rendering.
>>>>
>>>>
>>>> So, the widget XML would look something like this:
>>>>
>>>>
>>>> <container id="some-id" style="some-style" dojo="some Dojo data"  
>>>> ajax="some Ajax data" foo="some foo data">
>>>> ...
>>>> </container>
>>>>
>>>> The additional attributes could be applied to any screen widget  
>>>> element, not just the container element.
>>>>
>>>> The advantage I see to this approach is it is fully backwards  
>>>> compatible. We can add attributes to any screen widget element  
>>>> without breaking existing rendering code.
>>>>
>>>> That's it. Like I said, please add your ideas.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------
>>>> Looking for last minute shopping deals?  Find them fast with  
>>>> Yahoo! Search.
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Daniel Martínez <da...@paradisosistemas.es>]

Well, guess my words caused some polemic. Maybe my first approach was 
too simplistic.

Of course the features of XAP and Screen/Form widgets differ greatly, 
but , from my point of view they share the objective. They provide a 
technology-independent declarative XML for the UI and separate 
presentation from behavior.

No worries, XAP is no competition to OfBiz widgets.
--
Daniel

David E Jones escribió:
>
> Maybe there are some misconceptions about XAP, or maybe I am 
> misunderstanding what I've seen and reviewed of it. Taking a quick 
> look to make sure I found this on the XAP home page:
>
> =================================
> XAP works with any web server
>
> XAP is a client side offering that you can use with any web server - 
> PHP, .NET, etc.  It does not have any specific server requirements.
>
> Event handling can take place at the client, using managed code 
> objects (MCOs) written in JavaScript, or on the server with event 
> handlers written in any language supported by the server environment. 
> The MCO mechanism provides life cycle management and object 
> orientation for future development of business and user interface 
> logic - another step to simplifying development.
>
> We're not re-inventing the wheel (XAP will use any UI toolkit)
>
> Because XAP architecture is based on a "plugin architecture" that 
> leverages a component bridges concept, XML UI markup can be connected 
> to virtually any user interface toolkit. Initial XAP releases will 
> support integration with toolkits such as Kabuki and Dojo. Future 
> releases will focus on other full-featured, high-performance UI toolkits.
> =================================
>
> I don't think XAP is a replacement for the Screen Widget or the Form 
> Widget, or any of the server-side tools in OFBiz. In a way it's an 
> alternative to HTML meant to be interpreted on the client side and 
> HTML and other browser artifacts would be generated from the XAP XML.
>
> If we wanted to use it I think we would use it like any other client 
> side toolkit, like Prototype.
>
> We could have FTL templates that generate XAP instead of (or in 
> addition to) HTML, and we could have an alternate form renderer that 
> generates XAP instead of HTML.
>
> That's how I understand it anyway....
>
> -David
>
>
> On May 7, 2008, at 12:06 PM, Jacopo Cappellato wrote:
>
>> Daniel,
>>
>> thank you for your interest and comments. What I had in mind was not 
>> to replace the form widget but instead to integrate XAP with it.
>> I'm sorry, I don't have a clear picture but there could be more ways 
>> to do this:
>> 1) including the XAP tags in form widget definitions
>> 2) let the form widgets generate XAP tags and then pass the output to 
>> the XAP parser to get the final output (Ajax pages)
>>
>> My 2 cents,
>>
>> Jacopo
>>
>> On May 7, 2008, at 7:42 PM, Daniel Martínez wrote:
>>
>>> Jacopo,
>>>
>>> From what I have looked about XAP (since your mail) it seems to me 
>>> as it could be used a replacement for OfBiz screen/widgets. Its most 
>>> interesting features are the declarative UI in XML (like OfBiz 
>>> screens/forms, except for the AJAX ;) and the independence of AJAX 
>>> library.
>>>
>>> XAP is what I would like OfBiz widgets to be :)
>>> -- 
>>> Daniel
>>>
>>> Jacopo Cappellato escribió:
>>>> Adrian,
>>>>
>>>> it is really great to see you are putting effort on this.
>>>> As a side note, as I've already mentioned this in one of my mails 
>>>> some time ago, I'm still wondering if the usage of XAP (one of the 
>>>> incubating projects at Apache) could help us in this effort.
>>>> Unfortunately I had no time to seriously look into it but if you 
>>>> are interested you can get a quick overview of the tool here:
>>>>
>>>> http://incubator.apache.org/xap/overview.html
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>>>>
>>>>> David,
>>>>>
>>>>> I agree that there are some cool Ajax like features that won't map 
>>>>> exactly to existing widgets. In that case we'll create a new 
>>>>> widget and try to find an HTML equivalent. So, I'm not tossing out 
>>>>> the idea of new widgets that have improved features, I'm 
>>>>> suggesting let's start with adding new features to existing widgets.
>>>>>
>>>>> I have seen the Ajax work done in the Example component.
>>>>>
>>>>> Regarding the alternate HTML rendering classes, I don't think 
>>>>> those will be needed. My thinking right now is to just evolve the 
>>>>> existing HTML rendering classes.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> Adrian,
>>>>>> This sounds great for the elements that have some sort of natural 
>>>>>> JS/AJAX extension that doesn't change what the form means or 
>>>>>> offers to the user but instead just improves the user experience 
>>>>>> and/or efficiency.
>>>>>> With cases like I agree it would be great, and a REALLY cool 
>>>>>> feature, to upgrade automatically and not require form changes or 
>>>>>> anything.
>>>>>> However, there are many cases where we can't automatically add 
>>>>>> JS/AJAX extensions, but instead they represent a possible widget 
>>>>>> that is different enough from the concept behind any of the 
>>>>>> existing form field types that it would be weird to piggy back 
>>>>>> the functionality and try to automatically shoe-horn it into the 
>>>>>> existing functionality.
>>>>>> Some of the stuff I played with recently and added, like an 
>>>>>> auto-refresh on a screen container, is not something we would 
>>>>>> want to automatically turn on. The other one I added recently, to 
>>>>>> submit a form in the background and not refresh the page, is also 
>>>>>> something that I don't think we would want to automatically turn on.
>>>>>> So, yes, I agree we should add some of the automatic extensions 
>>>>>> that we can and it would be a really cool set of new features.
>>>>>> Stepping back to the original thingy, how does using alternate 
>>>>>> HtmlFormRenderer classes help with this? Maybe you're not still 
>>>>>> considering that, but I'd say if we did default fancy things 
>>>>>> (which again, I love the idea of), we should just do those all 
>>>>>> the time unless, like you wrote, the browser identifier is 
>>>>>> clearly one that won't support it (some of that might need to be 
>>>>>> client side too though... I'm not sure about all of the nuances 
>>>>>> there).
>>>>>> -David
>>>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>>>> I'm resurrecting this thread because I've spent some time 
>>>>>>> looking into the whole third party rendering library support 
>>>>>>> idea and I think I have a simple solution.
>>>>>>>
>>>>>>> I thought about David's suggestion of having new widgets that 
>>>>>>> are effects based. I don't think that will be a good strategy 
>>>>>>> because not all browsers will have javascript enabled - which 
>>>>>>> would render those widgets useless.
>>>>>>>
>>>>>>> A better approach I would like to propose is to use the 
>>>>>>> Prototype javascript library in combination with EXISTING 
>>>>>>> widgets to improve their response and functionality. The widget 
>>>>>>> rendering code would detect if the browser supports javascript, 
>>>>>>> and output the correct HTML to accommodate the browser.
>>>>>>>
>>>>>>> Instead of a "live-form" widget, the existing form widget would 
>>>>>>> detect browser support, and render an improved form if the 
>>>>>>> browser supports it. The current paginated tables would use Ajax 
>>>>>>> calls to scroll through pages instead of refreshing the whole 
>>>>>>> screen.
>>>>>>>
>>>>>>> Basically, I'd like to see the cool effects and improved 
>>>>>>> response implemented without any additional work on the widget 
>>>>>>> XML files.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> David E Jones wrote:
>>>>>>>> I guess this is a continuation of the discussion in the thread 
>>>>>>>> "uilabels and screenlet widget", and is related somewhat to 
>>>>>>>> part of the stuff in issue OFBIZ-1648.
>>>>>>>> The general goal of the widgets is simple: no platform specific 
>>>>>>>> artifacts. Unfortunately this isn't entirely possible, which is 
>>>>>>>> why we have a very big and ugly "platform-specific" tag to 
>>>>>>>> delineate things that are not generic and provide for the 
>>>>>>>> possible of having alternative platform things specified 
>>>>>>>> together so that when rendering for a different target the 
>>>>>>>> appropriate option can be selected.
>>>>>>>> As far as that applies to this topic, I'd say the best approach 
>>>>>>>> is to never have any element or attribute called "dojo" or 
>>>>>>>> "ajax" or "rico" or anything. In the dojo attribute for the 
>>>>>>>> container elements, I'm not sure what you'd propose to put in 
>>>>>>>> it, ie the "some Dojo data", but in general I'd prefer to never 
>>>>>>>> have anything that is so dependent on a particular underlying 
>>>>>>>> technology, the widget artifacts gain efficiency by their focus 
>>>>>>>> on different effects, with the underlying software taking care 
>>>>>>>> of the "causes", or rather how the effects are brought about.
>>>>>>>> In other words while we wouldn't want elements that have 
>>>>>>>> anything to do with "dojo" or "openrico" we would want elements 
>>>>>>>> to describe the effects from those libraries we'd like to have 
>>>>>>>> available through the widget, and the most appropriate is 
>>>>>>>> probably the Form Widget with different form and field types 
>>>>>>>> (though some would certainly go elsewhere and are not form 
>>>>>>>> related).
>>>>>>>> Examples of that would be a new form type like "live-grid" or a 
>>>>>>>> new form field type like "live-combobox" (or "dynamic-combobox" 
>>>>>>>> or "server-side-combobox" or something). If we add elements 
>>>>>>>> like that then it doesn't matter which AJAX library we use 
>>>>>>>> underneath and generate HTML/etc for, and we can change 
>>>>>>>> libraries without requiring any change to the higher level 
>>>>>>>> artifacts, like the form definitions.
>>>>>>>> -David
>>>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, 
>>>>>>>>> Dojo, etc) in the screen widgets, we need to discuss how that 
>>>>>>>>> support will appear in the screen widget XML files.
>>>>>>>>>
>>>>>>>>> I'll start things off with a suggestion I made in another 
>>>>>>>>> thread. Everyone is welcome to join in and offer their ideas. 
>>>>>>>>> When we reach an agreement, we can submit the results to Jira 
>>>>>>>>> and begin building it out.
>>>>>>>>>
>>>>>>>>> I was thinking we could simply extend the existing widgets 
>>>>>>>>> with additional attributes. The new attributes would pass 3rd 
>>>>>>>>> party specific data to the rendering classes. The new 
>>>>>>>>> attributes are ignored by rendering classes that don't need 
>>>>>>>>> them. All rendering classes render all widgets in some form - 
>>>>>>>>> some rendering classes might have additional bells and 
>>>>>>>>> whistles based upon the additional attributes, while others 
>>>>>>>>> downgrade gracefully and still provide a usable screen rendering.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, the widget XML would look something like this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo 
>>>>>>>>> data" ajax="some Ajax data" foo="some foo data">
>>>>>>>>> ...
>>>>>>>>> </container>
>>>>>>>>>
>>>>>>>>> The additional attributes could be applied to any screen 
>>>>>>>>> widget element, not just the container element.
>>>>>>>>>
>>>>>>>>> The advantage I see to this approach is it is fully backwards 
>>>>>>>>> compatible. We can add attributes to any screen widget element 
>>>>>>>>> without breaking existing rendering code.
>>>>>>>>>
>>>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------
>>>>>>>>> Looking for last minute shopping deals?  Find them fast with 
>>>>>>>>> Yahoo! Search.
>>>>
>>>
>>
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[David E Jones <jo...@hotwaxmedia.com>]

Maybe there are some misconceptions about XAP, or maybe I am  
misunderstanding what I've seen and reviewed of it. Taking a quick  
look to make sure I found this on the XAP home page:

=================================
XAP works with any web server

XAP is a client side offering that you can use with any web server -  
PHP, .NET, etc.  It does not have any specific server requirements.

Event handling can take place at the client, using managed code  
objects (MCOs) written in JavaScript, or on the server with event  
handlers written in any language supported by the server environment.  
The MCO mechanism provides life cycle management and object  
orientation for future development of business and user interface  
logic - another step to simplifying development.

We're not re-inventing the wheel (XAP will use any UI toolkit)

Because XAP architecture is based on a "plugin architecture" that  
leverages a component bridges concept, XML UI markup can be connected  
to virtually any user interface toolkit. Initial XAP releases will  
support integration with toolkits such as Kabuki and Dojo. Future  
releases will focus on other full-featured, high-performance UI  
toolkits.
=================================

I don't think XAP is a replacement for the Screen Widget or the Form  
Widget, or any of the server-side tools in OFBiz. In a way it's an  
alternative to HTML meant to be interpreted on the client side and  
HTML and other browser artifacts would be generated from the XAP XML.

If we wanted to use it I think we would use it like any other client  
side toolkit, like Prototype.

We could have FTL templates that generate XAP instead of (or in  
addition to) HTML, and we could have an alternate form renderer that  
generates XAP instead of HTML.

That's how I understand it anyway....

-David


On May 7, 2008, at 12:06 PM, Jacopo Cappellato wrote:

> Daniel,
>
> thank you for your interest and comments. What I had in mind was not  
> to replace the form widget but instead to integrate XAP with it.
> I'm sorry, I don't have a clear picture but there could be more ways  
> to do this:
> 1) including the XAP tags in form widget definitions
> 2) let the form widgets generate XAP tags and then pass the output  
> to the XAP parser to get the final output (Ajax pages)
>
> My 2 cents,
>
> Jacopo
>
> On May 7, 2008, at 7:42 PM, Daniel Martínez wrote:
>
>> Jacopo,
>>
>> From what I have looked about XAP (since your mail) it seems to me  
>> as it could be used a replacement for OfBiz screen/widgets. Its  
>> most interesting features are the declarative UI in XML (like OfBiz  
>> screens/forms, except for the AJAX ;) and the independence of AJAX  
>> library.
>>
>> XAP is what I would like OfBiz widgets to be :)
>> --
>> Daniel
>>
>> Jacopo Cappellato escribió:
>>> Adrian,
>>>
>>> it is really great to see you are putting effort on this.
>>> As a side note, as I've already mentioned this in one of my mails  
>>> some time ago, I'm still wondering if the usage of XAP (one of the  
>>> incubating projects at Apache) could help us in this effort.
>>> Unfortunately I had no time to seriously look into it but if you  
>>> are interested you can get a quick overview of the tool here:
>>>
>>> http://incubator.apache.org/xap/overview.html
>>>
>>> Jacopo
>>>
>>>
>>> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>>>
>>>> David,
>>>>
>>>> I agree that there are some cool Ajax like features that won't  
>>>> map exactly to existing widgets. In that case we'll create a new  
>>>> widget and try to find an HTML equivalent. So, I'm not tossing  
>>>> out the idea of new widgets that have improved features, I'm  
>>>> suggesting let's start with adding new features to existing  
>>>> widgets.
>>>>
>>>> I have seen the Ajax work done in the Example component.
>>>>
>>>> Regarding the alternate HTML rendering classes, I don't think  
>>>> those will be needed. My thinking right now is to just evolve the  
>>>> existing HTML rendering classes.
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> Adrian,
>>>>> This sounds great for the elements that have some sort of  
>>>>> natural JS/AJAX extension that doesn't change what the form  
>>>>> means or offers to the user but instead just improves the user  
>>>>> experience and/or efficiency.
>>>>> With cases like I agree it would be great, and a REALLY cool  
>>>>> feature, to upgrade automatically and not require form changes  
>>>>> or anything.
>>>>> However, there are many cases where we can't automatically add  
>>>>> JS/AJAX extensions, but instead they represent a possible widget  
>>>>> that is different enough from the concept behind any of the  
>>>>> existing form field types that it would be weird to piggy back  
>>>>> the functionality and try to automatically shoe-horn it into the  
>>>>> existing functionality.
>>>>> Some of the stuff I played with recently and added, like an auto- 
>>>>> refresh on a screen container, is not something we would want to  
>>>>> automatically turn on. The other one I added recently, to submit  
>>>>> a form in the background and not refresh the page, is also  
>>>>> something that I don't think we would want to automatically turn  
>>>>> on.
>>>>> So, yes, I agree we should add some of the automatic extensions  
>>>>> that we can and it would be a really cool set of new features.
>>>>> Stepping back to the original thingy, how does using alternate  
>>>>> HtmlFormRenderer classes help with this? Maybe you're not still  
>>>>> considering that, but I'd say if we did default fancy things  
>>>>> (which again, I love the idea of), we should just do those all  
>>>>> the time unless, like you wrote, the browser identifier is  
>>>>> clearly one that won't support it (some of that might need to be  
>>>>> client side too though... I'm not sure about all of the nuances  
>>>>> there).
>>>>> -David
>>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>>> I'm resurrecting this thread because I've spent some time  
>>>>>> looking into the whole third party rendering library support  
>>>>>> idea and I think I have a simple solution.
>>>>>>
>>>>>> I thought about David's suggestion of having new widgets that  
>>>>>> are effects based. I don't think that will be a good strategy  
>>>>>> because not all browsers will have javascript enabled - which  
>>>>>> would render those widgets useless.
>>>>>>
>>>>>> A better approach I would like to propose is to use the  
>>>>>> Prototype javascript library in combination with EXISTING  
>>>>>> widgets to improve their response and functionality. The widget  
>>>>>> rendering code would detect if the browser supports javascript,  
>>>>>> and output the correct HTML to accommodate the browser.
>>>>>>
>>>>>> Instead of a "live-form" widget, the existing form widget would  
>>>>>> detect browser support, and render an improved form if the  
>>>>>> browser supports it. The current paginated tables would use  
>>>>>> Ajax calls to scroll through pages instead of refreshing the  
>>>>>> whole screen.
>>>>>>
>>>>>> Basically, I'd like to see the cool effects and improved  
>>>>>> response implemented without any additional work on the widget  
>>>>>> XML files.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> I guess this is a continuation of the discussion in the thread  
>>>>>>> "uilabels and screenlet widget", and is related somewhat to  
>>>>>>> part of the stuff in issue OFBIZ-1648.
>>>>>>> The general goal of the widgets is simple: no platform  
>>>>>>> specific artifacts. Unfortunately this isn't entirely  
>>>>>>> possible, which is why we have a very big and ugly "platform- 
>>>>>>> specific" tag to delineate things that are not generic and  
>>>>>>> provide for the possible of having alternative platform things  
>>>>>>> specified together so that when rendering for a different  
>>>>>>> target the appropriate option can be selected.
>>>>>>> As far as that applies to this topic, I'd say the best  
>>>>>>> approach is to never have any element or attribute called  
>>>>>>> "dojo" or "ajax" or "rico" or anything. In the dojo attribute  
>>>>>>> for the container elements, I'm not sure what you'd propose to  
>>>>>>> put in it, ie the "some Dojo data", but in general I'd prefer  
>>>>>>> to never have anything that is so dependent on a particular  
>>>>>>> underlying technology, the widget artifacts gain efficiency by  
>>>>>>> their focus on different effects, with the underlying software  
>>>>>>> taking care of the "causes", or rather how the effects are  
>>>>>>> brought about.
>>>>>>> In other words while we wouldn't want elements that have  
>>>>>>> anything to do with "dojo" or "openrico" we would want  
>>>>>>> elements to describe the effects from those libraries we'd  
>>>>>>> like to have available through the widget, and the most  
>>>>>>> appropriate is probably the Form Widget with different form  
>>>>>>> and field types (though some would certainly go elsewhere and  
>>>>>>> are not form related).
>>>>>>> Examples of that would be a new form type like "live-grid" or  
>>>>>>> a new form field type like "live-combobox" (or "dynamic- 
>>>>>>> combobox" or "server-side-combobox" or something). If we add  
>>>>>>> elements like that then it doesn't matter which AJAX library  
>>>>>>> we use underneath and generate HTML/etc for, and we can change  
>>>>>>> libraries without requiring any change to the higher level  
>>>>>>> artifacts, like the form definitions.
>>>>>>> -David
>>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax,  
>>>>>>>> Dojo, etc) in the screen widgets, we need to discuss how that  
>>>>>>>> support will appear in the screen widget XML files.
>>>>>>>>
>>>>>>>> I'll start things off with a suggestion I made in another  
>>>>>>>> thread. Everyone is welcome to join in and offer their ideas.  
>>>>>>>> When we reach an agreement, we can submit the results to Jira  
>>>>>>>> and begin building it out.
>>>>>>>>
>>>>>>>> I was thinking we could simply extend the existing widgets  
>>>>>>>> with additional attributes. The new attributes would pass 3rd  
>>>>>>>> party specific data to the rendering classes. The new  
>>>>>>>> attributes are ignored by rendering classes that don't need  
>>>>>>>> them. All rendering classes render all widgets in some form -  
>>>>>>>> some rendering classes might have additional bells and  
>>>>>>>> whistles based upon the additional attributes, while others  
>>>>>>>> downgrade gracefully and still provide a usable screen  
>>>>>>>> rendering.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, the widget XML would look something like this:
>>>>>>>>
>>>>>>>>
>>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo  
>>>>>>>> data" ajax="some Ajax data" foo="some foo data">
>>>>>>>> ...
>>>>>>>> </container>
>>>>>>>>
>>>>>>>> The additional attributes could be applied to any screen  
>>>>>>>> widget element, not just the container element.
>>>>>>>>
>>>>>>>> The advantage I see to this approach is it is fully backwards  
>>>>>>>> compatible. We can add attributes to any screen widget  
>>>>>>>> element without breaking existing rendering code.
>>>>>>>>
>>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------
>>>>>>>> Looking for last minute shopping deals?  Find them fast with  
>>>>>>>> Yahoo! Search.
>>>
>>
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Daniel Martínez <da...@paradisosistemas.es>]

Jacopo,

I did not intent my message to propose XAP as a replacement for OfBiz 
screens/forms, but to present its possibilities.
Comments follow...

Jacopo Cappellato escribió:
> Daniel,
>
> thank you for your interest and comments. What I had in mind was not 
> to replace the form widget but instead to integrate XAP with it.
> I'm sorry, I don't have a clear picture but there could be more ways 
> to do this:
> 1) including the XAP tags in form widget definitions
I haven't thought of this. I am not really aware of the effort to 
integrate and maintain with the XML forms, but I don't like the idea of 
mixing tags, but that's probably just my opinion.
> 2) let the form widgets generate XAP tags and then pass the output to 
> the XAP parser to get the final output (Ajax pages)
I have thought of this, but I doubt about the advantages over making the 
same with dojo or prototype.

--
Daniel
>
> My 2 cents,
>
> Jacopo
>
> On May 7, 2008, at 7:42 PM, Daniel Martínez wrote:
>
>> Jacopo,
>>
>> From what I have looked about XAP (since your mail) it seems to me as 
>> it could be used a replacement for OfBiz screen/widgets. Its most 
>> interesting features are the declarative UI in XML (like OfBiz 
>> screens/forms, except for the AJAX ;) and the independence of AJAX 
>> library.
>>
>> XAP is what I would like OfBiz widgets to be :)
>> -- 
>> Daniel
>>
>> Jacopo Cappellato escribió:
>>> Adrian,
>>>
>>> it is really great to see you are putting effort on this.
>>> As a side note, as I've already mentioned this in one of my mails 
>>> some time ago, I'm still wondering if the usage of XAP (one of the 
>>> incubating projects at Apache) could help us in this effort.
>>> Unfortunately I had no time to seriously look into it but if you are 
>>> interested you can get a quick overview of the tool here:
>>>
>>> http://incubator.apache.org/xap/overview.html
>>>
>>> Jacopo
>>>
>>>
>>> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>>>
>>>> David,
>>>>
>>>> I agree that there are some cool Ajax like features that won't map 
>>>> exactly to existing widgets. In that case we'll create a new widget 
>>>> and try to find an HTML equivalent. So, I'm not tossing out the 
>>>> idea of new widgets that have improved features, I'm suggesting 
>>>> let's start with adding new features to existing widgets.
>>>>
>>>> I have seen the Ajax work done in the Example component.
>>>>
>>>> Regarding the alternate HTML rendering classes, I don't think those 
>>>> will be needed. My thinking right now is to just evolve the 
>>>> existing HTML rendering classes.
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> Adrian,
>>>>> This sounds great for the elements that have some sort of natural 
>>>>> JS/AJAX extension that doesn't change what the form means or 
>>>>> offers to the user but instead just improves the user experience 
>>>>> and/or efficiency.
>>>>> With cases like I agree it would be great, and a REALLY cool 
>>>>> feature, to upgrade automatically and not require form changes or 
>>>>> anything.
>>>>> However, there are many cases where we can't automatically add 
>>>>> JS/AJAX extensions, but instead they represent a possible widget 
>>>>> that is different enough from the concept behind any of the 
>>>>> existing form field types that it would be weird to piggy back the 
>>>>> functionality and try to automatically shoe-horn it into the 
>>>>> existing functionality.
>>>>> Some of the stuff I played with recently and added, like an 
>>>>> auto-refresh on a screen container, is not something we would want 
>>>>> to automatically turn on. The other one I added recently, to 
>>>>> submit a form in the background and not refresh the page, is also 
>>>>> something that I don't think we would want to automatically turn on.
>>>>> So, yes, I agree we should add some of the automatic extensions 
>>>>> that we can and it would be a really cool set of new features.
>>>>> Stepping back to the original thingy, how does using alternate 
>>>>> HtmlFormRenderer classes help with this? Maybe you're not still 
>>>>> considering that, but I'd say if we did default fancy things 
>>>>> (which again, I love the idea of), we should just do those all the 
>>>>> time unless, like you wrote, the browser identifier is clearly one 
>>>>> that won't support it (some of that might need to be client side 
>>>>> too though... I'm not sure about all of the nuances there).
>>>>> -David
>>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>>> I'm resurrecting this thread because I've spent some time looking 
>>>>>> into the whole third party rendering library support idea and I 
>>>>>> think I have a simple solution.
>>>>>>
>>>>>> I thought about David's suggestion of having new widgets that are 
>>>>>> effects based. I don't think that will be a good strategy because 
>>>>>> not all browsers will have javascript enabled - which would 
>>>>>> render those widgets useless.
>>>>>>
>>>>>> A better approach I would like to propose is to use the Prototype 
>>>>>> javascript library in combination with EXISTING widgets to 
>>>>>> improve their response and functionality. The widget rendering 
>>>>>> code would detect if the browser supports javascript, and output 
>>>>>> the correct HTML to accommodate the browser.
>>>>>>
>>>>>> Instead of a "live-form" widget, the existing form widget would 
>>>>>> detect browser support, and render an improved form if the 
>>>>>> browser supports it. The current paginated tables would use Ajax 
>>>>>> calls to scroll through pages instead of refreshing the whole 
>>>>>> screen.
>>>>>>
>>>>>> Basically, I'd like to see the cool effects and improved response 
>>>>>> implemented without any additional work on the widget XML files.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> I guess this is a continuation of the discussion in the thread 
>>>>>>> "uilabels and screenlet widget", and is related somewhat to part 
>>>>>>> of the stuff in issue OFBIZ-1648.
>>>>>>> The general goal of the widgets is simple: no platform specific 
>>>>>>> artifacts. Unfortunately this isn't entirely possible, which is 
>>>>>>> why we have a very big and ugly "platform-specific" tag to 
>>>>>>> delineate things that are not generic and provide for the 
>>>>>>> possible of having alternative platform things specified 
>>>>>>> together so that when rendering for a different target the 
>>>>>>> appropriate option can be selected.
>>>>>>> As far as that applies to this topic, I'd say the best approach 
>>>>>>> is to never have any element or attribute called "dojo" or 
>>>>>>> "ajax" or "rico" or anything. In the dojo attribute for the 
>>>>>>> container elements, I'm not sure what you'd propose to put in 
>>>>>>> it, ie the "some Dojo data", but in general I'd prefer to never 
>>>>>>> have anything that is so dependent on a particular underlying 
>>>>>>> technology, the widget artifacts gain efficiency by their focus 
>>>>>>> on different effects, with the underlying software taking care 
>>>>>>> of the "causes", or rather how the effects are brought about.
>>>>>>> In other words while we wouldn't want elements that have 
>>>>>>> anything to do with "dojo" or "openrico" we would want elements 
>>>>>>> to describe the effects from those libraries we'd like to have 
>>>>>>> available through the widget, and the most appropriate is 
>>>>>>> probably the Form Widget with different form and field types 
>>>>>>> (though some would certainly go elsewhere and are not form 
>>>>>>> related).
>>>>>>> Examples of that would be a new form type like "live-grid" or a 
>>>>>>> new form field type like "live-combobox" (or "dynamic-combobox" 
>>>>>>> or "server-side-combobox" or something). If we add elements like 
>>>>>>> that then it doesn't matter which AJAX library we use underneath 
>>>>>>> and generate HTML/etc for, and we can change libraries without 
>>>>>>> requiring any change to the higher level artifacts, like the 
>>>>>>> form definitions.
>>>>>>> -David
>>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, 
>>>>>>>> Dojo, etc) in the screen widgets, we need to discuss how that 
>>>>>>>> support will appear in the screen widget XML files.
>>>>>>>>
>>>>>>>> I'll start things off with a suggestion I made in another 
>>>>>>>> thread. Everyone is welcome to join in and offer their ideas. 
>>>>>>>> When we reach an agreement, we can submit the results to Jira 
>>>>>>>> and begin building it out.
>>>>>>>>
>>>>>>>> I was thinking we could simply extend the existing widgets with 
>>>>>>>> additional attributes. The new attributes would pass 3rd party 
>>>>>>>> specific data to the rendering classes. The new attributes are 
>>>>>>>> ignored by rendering classes that don't need them. All 
>>>>>>>> rendering classes render all widgets in some form - some 
>>>>>>>> rendering classes might have additional bells and whistles 
>>>>>>>> based upon the additional attributes, while others downgrade 
>>>>>>>> gracefully and still provide a usable screen rendering.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, the widget XML would look something like this:
>>>>>>>>
>>>>>>>>
>>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo 
>>>>>>>> data" ajax="some Ajax data" foo="some foo data">
>>>>>>>> ...
>>>>>>>> </container>
>>>>>>>>
>>>>>>>> The additional attributes could be applied to any screen widget 
>>>>>>>> element, not just the container element.
>>>>>>>>
>>>>>>>> The advantage I see to this approach is it is fully backwards 
>>>>>>>> compatible. We can add attributes to any screen widget element 
>>>>>>>> without breaking existing rendering code.
>>>>>>>>
>>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------
>>>>>>>> Looking for last minute shopping deals?  Find them fast with 
>>>>>>>> Yahoo! Search.
>>>
>>
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacopo Cappellato <ja...@gmail.com>]

Daniel,

thank you for your interest and comments. What I had in mind was not  
to replace the form widget but instead to integrate XAP with it.
I'm sorry, I don't have a clear picture but there could be more ways  
to do this:
1) including the XAP tags in form widget definitions
2) let the form widgets generate XAP tags and then pass the output to  
the XAP parser to get the final output (Ajax pages)

My 2 cents,

Jacopo

On May 7, 2008, at 7:42 PM, Daniel Martínez wrote:

> Jacopo,
>
> From what I have looked about XAP (since your mail) it seems to me  
> as it could be used a replacement for OfBiz screen/widgets. Its most  
> interesting features are the declarative UI in XML (like OfBiz  
> screens/forms, except for the AJAX ;) and the independence of AJAX  
> library.
>
> XAP is what I would like OfBiz widgets to be :)
> --
> Daniel
>
> Jacopo Cappellato escribió:
>> Adrian,
>>
>> it is really great to see you are putting effort on this.
>> As a side note, as I've already mentioned this in one of my mails  
>> some time ago, I'm still wondering if the usage of XAP (one of the  
>> incubating projects at Apache) could help us in this effort.
>> Unfortunately I had no time to seriously look into it but if you  
>> are interested you can get a quick overview of the tool here:
>>
>> http://incubator.apache.org/xap/overview.html
>>
>> Jacopo
>>
>>
>> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>>
>>> David,
>>>
>>> I agree that there are some cool Ajax like features that won't map  
>>> exactly to existing widgets. In that case we'll create a new  
>>> widget and try to find an HTML equivalent. So, I'm not tossing out  
>>> the idea of new widgets that have improved features, I'm  
>>> suggesting let's start with adding new features to existing widgets.
>>>
>>> I have seen the Ajax work done in the Example component.
>>>
>>> Regarding the alternate HTML rendering classes, I don't think  
>>> those will be needed. My thinking right now is to just evolve the  
>>> existing HTML rendering classes.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> Adrian,
>>>> This sounds great for the elements that have some sort of natural  
>>>> JS/AJAX extension that doesn't change what the form means or  
>>>> offers to the user but instead just improves the user experience  
>>>> and/or efficiency.
>>>> With cases like I agree it would be great, and a REALLY cool  
>>>> feature, to upgrade automatically and not require form changes or  
>>>> anything.
>>>> However, there are many cases where we can't automatically add JS/ 
>>>> AJAX extensions, but instead they represent a possible widget  
>>>> that is different enough from the concept behind any of the  
>>>> existing form field types that it would be weird to piggy back  
>>>> the functionality and try to automatically shoe-horn it into the  
>>>> existing functionality.
>>>> Some of the stuff I played with recently and added, like an auto- 
>>>> refresh on a screen container, is not something we would want to  
>>>> automatically turn on. The other one I added recently, to submit  
>>>> a form in the background and not refresh the page, is also  
>>>> something that I don't think we would want to automatically turn  
>>>> on.
>>>> So, yes, I agree we should add some of the automatic extensions  
>>>> that we can and it would be a really cool set of new features.
>>>> Stepping back to the original thingy, how does using alternate  
>>>> HtmlFormRenderer classes help with this? Maybe you're not still  
>>>> considering that, but I'd say if we did default fancy things  
>>>> (which again, I love the idea of), we should just do those all  
>>>> the time unless, like you wrote, the browser identifier is  
>>>> clearly one that won't support it (some of that might need to be  
>>>> client side too though... I'm not sure about all of the nuances  
>>>> there).
>>>> -David
>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>> I'm resurrecting this thread because I've spent some time  
>>>>> looking into the whole third party rendering library support  
>>>>> idea and I think I have a simple solution.
>>>>>
>>>>> I thought about David's suggestion of having new widgets that  
>>>>> are effects based. I don't think that will be a good strategy  
>>>>> because not all browsers will have javascript enabled - which  
>>>>> would render those widgets useless.
>>>>>
>>>>> A better approach I would like to propose is to use the  
>>>>> Prototype javascript library in combination with EXISTING  
>>>>> widgets to improve their response and functionality. The widget  
>>>>> rendering code would detect if the browser supports javascript,  
>>>>> and output the correct HTML to accommodate the browser.
>>>>>
>>>>> Instead of a "live-form" widget, the existing form widget would  
>>>>> detect browser support, and render an improved form if the  
>>>>> browser supports it. The current paginated tables would use Ajax  
>>>>> calls to scroll through pages instead of refreshing the whole  
>>>>> screen.
>>>>>
>>>>> Basically, I'd like to see the cool effects and improved  
>>>>> response implemented without any additional work on the widget  
>>>>> XML files.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> I guess this is a continuation of the discussion in the thread  
>>>>>> "uilabels and screenlet widget", and is related somewhat to  
>>>>>> part of the stuff in issue OFBIZ-1648.
>>>>>> The general goal of the widgets is simple: no platform specific  
>>>>>> artifacts. Unfortunately this isn't entirely possible, which is  
>>>>>> why we have a very big and ugly "platform-specific" tag to  
>>>>>> delineate things that are not generic and provide for the  
>>>>>> possible of having alternative platform things specified  
>>>>>> together so that when rendering for a different target the  
>>>>>> appropriate option can be selected.
>>>>>> As far as that applies to this topic, I'd say the best approach  
>>>>>> is to never have any element or attribute called "dojo" or  
>>>>>> "ajax" or "rico" or anything. In the dojo attribute for the  
>>>>>> container elements, I'm not sure what you'd propose to put in  
>>>>>> it, ie the "some Dojo data", but in general I'd prefer to never  
>>>>>> have anything that is so dependent on a particular underlying  
>>>>>> technology, the widget artifacts gain efficiency by their focus  
>>>>>> on different effects, with the underlying software taking care  
>>>>>> of the "causes", or rather how the effects are brought about.
>>>>>> In other words while we wouldn't want elements that have  
>>>>>> anything to do with "dojo" or "openrico" we would want elements  
>>>>>> to describe the effects from those libraries we'd like to have  
>>>>>> available through the widget, and the most appropriate is  
>>>>>> probably the Form Widget with different form and field types  
>>>>>> (though some would certainly go elsewhere and are not form  
>>>>>> related).
>>>>>> Examples of that would be a new form type like "live-grid" or a  
>>>>>> new form field type like "live-combobox" (or "dynamic-combobox"  
>>>>>> or "server-side-combobox" or something). If we add elements  
>>>>>> like that then it doesn't matter which AJAX library we use  
>>>>>> underneath and generate HTML/etc for, and we can change  
>>>>>> libraries without requiring any change to the higher level  
>>>>>> artifacts, like the form definitions.
>>>>>> -David
>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax,  
>>>>>>> Dojo, etc) in the screen widgets, we need to discuss how that  
>>>>>>> support will appear in the screen widget XML files.
>>>>>>>
>>>>>>> I'll start things off with a suggestion I made in another  
>>>>>>> thread. Everyone is welcome to join in and offer their ideas.  
>>>>>>> When we reach an agreement, we can submit the results to Jira  
>>>>>>> and begin building it out.
>>>>>>>
>>>>>>> I was thinking we could simply extend the existing widgets  
>>>>>>> with additional attributes. The new attributes would pass 3rd  
>>>>>>> party specific data to the rendering classes. The new  
>>>>>>> attributes are ignored by rendering classes that don't need  
>>>>>>> them. All rendering classes render all widgets in some form -  
>>>>>>> some rendering classes might have additional bells and  
>>>>>>> whistles based upon the additional attributes, while others  
>>>>>>> downgrade gracefully and still provide a usable screen  
>>>>>>> rendering.
>>>>>>>
>>>>>>>
>>>>>>> So, the widget XML would look something like this:
>>>>>>>
>>>>>>>
>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo  
>>>>>>> data" ajax="some Ajax data" foo="some foo data">
>>>>>>> ...
>>>>>>> </container>
>>>>>>>
>>>>>>> The additional attributes could be applied to any screen  
>>>>>>> widget element, not just the container element.
>>>>>>>
>>>>>>> The advantage I see to this approach is it is fully backwards  
>>>>>>> compatible. We can add attributes to any screen widget element  
>>>>>>> without breaking existing rendering code.
>>>>>>>
>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------
>>>>>>> Looking for last minute shopping deals?  Find them fast with  
>>>>>>> Yahoo! Search.
>>
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@hlmksw.com>]

If there is enough interest in XAP, we could create a XAP view handler.

-Adrian

Daniel Martínez wrote:
> Jacopo,
> 
>  From what I have looked about XAP (since your mail) it seems to me as 
> it could be used a replacement for OfBiz screen/widgets. Its most 
> interesting features are the declarative UI in XML (like OfBiz 
> screens/forms, except for the AJAX ;) and the independence of AJAX library.
> 
> XAP is what I would like OfBiz widgets to be :)
> -- 
> Daniel
> 
> Jacopo Cappellato escribió:
>> Adrian,
>>
>> it is really great to see you are putting effort on this.
>> As a side note, as I've already mentioned this in one of my mails some 
>> time ago, I'm still wondering if the usage of XAP (one of the 
>> incubating projects at Apache) could help us in this effort.
>> Unfortunately I had no time to seriously look into it but if you are 
>> interested you can get a quick overview of the tool here:
>>
>> http://incubator.apache.org/xap/overview.html
>>
>> Jacopo
>>
>>
>> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>>
>>> David,
>>>
>>> I agree that there are some cool Ajax like features that won't map 
>>> exactly to existing widgets. In that case we'll create a new widget 
>>> and try to find an HTML equivalent. So, I'm not tossing out the idea 
>>> of new widgets that have improved features, I'm suggesting let's 
>>> start with adding new features to existing widgets.
>>>
>>> I have seen the Ajax work done in the Example component.
>>>
>>> Regarding the alternate HTML rendering classes, I don't think those 
>>> will be needed. My thinking right now is to just evolve the existing 
>>> HTML rendering classes.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> Adrian,
>>>> This sounds great for the elements that have some sort of natural 
>>>> JS/AJAX extension that doesn't change what the form means or offers 
>>>> to the user but instead just improves the user experience and/or 
>>>> efficiency.
>>>> With cases like I agree it would be great, and a REALLY cool 
>>>> feature, to upgrade automatically and not require form changes or 
>>>> anything.
>>>> However, there are many cases where we can't automatically add 
>>>> JS/AJAX extensions, but instead they represent a possible widget 
>>>> that is different enough from the concept behind any of the existing 
>>>> form field types that it would be weird to piggy back the 
>>>> functionality and try to automatically shoe-horn it into the 
>>>> existing functionality.
>>>> Some of the stuff I played with recently and added, like an 
>>>> auto-refresh on a screen container, is not something we would want 
>>>> to automatically turn on. The other one I added recently, to submit 
>>>> a form in the background and not refresh the page, is also something 
>>>> that I don't think we would want to automatically turn on.
>>>> So, yes, I agree we should add some of the automatic extensions that 
>>>> we can and it would be a really cool set of new features.
>>>> Stepping back to the original thingy, how does using alternate 
>>>> HtmlFormRenderer classes help with this? Maybe you're not still 
>>>> considering that, but I'd say if we did default fancy things (which 
>>>> again, I love the idea of), we should just do those all the time 
>>>> unless, like you wrote, the browser identifier is clearly one that 
>>>> won't support it (some of that might need to be client side too 
>>>> though... I'm not sure about all of the nuances there).
>>>> -David
>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>> I'm resurrecting this thread because I've spent some time looking 
>>>>> into the whole third party rendering library support idea and I 
>>>>> think I have a simple solution.
>>>>>
>>>>> I thought about David's suggestion of having new widgets that are 
>>>>> effects based. I don't think that will be a good strategy because 
>>>>> not all browsers will have javascript enabled - which would render 
>>>>> those widgets useless.
>>>>>
>>>>> A better approach I would like to propose is to use the Prototype 
>>>>> javascript library in combination with EXISTING widgets to improve 
>>>>> their response and functionality. The widget rendering code would 
>>>>> detect if the browser supports javascript, and output the correct 
>>>>> HTML to accommodate the browser.
>>>>>
>>>>> Instead of a "live-form" widget, the existing form widget would 
>>>>> detect browser support, and render an improved form if the browser 
>>>>> supports it. The current paginated tables would use Ajax calls to 
>>>>> scroll through pages instead of refreshing the whole screen.
>>>>>
>>>>> Basically, I'd like to see the cool effects and improved response 
>>>>> implemented without any additional work on the widget XML files.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> I guess this is a continuation of the discussion in the thread 
>>>>>> "uilabels and screenlet widget", and is related somewhat to part 
>>>>>> of the stuff in issue OFBIZ-1648.
>>>>>> The general goal of the widgets is simple: no platform specific 
>>>>>> artifacts. Unfortunately this isn't entirely possible, which is 
>>>>>> why we have a very big and ugly "platform-specific" tag to 
>>>>>> delineate things that are not generic and provide for the possible 
>>>>>> of having alternative platform things specified together so that 
>>>>>> when rendering for a different target the appropriate option can 
>>>>>> be selected.
>>>>>> As far as that applies to this topic, I'd say the best approach is 
>>>>>> to never have any element or attribute called "dojo" or "ajax" or 
>>>>>> "rico" or anything. In the dojo attribute for the container 
>>>>>> elements, I'm not sure what you'd propose to put in it, ie the 
>>>>>> "some Dojo data", but in general I'd prefer to never have anything 
>>>>>> that is so dependent on a particular underlying technology, the 
>>>>>> widget artifacts gain efficiency by their focus on different 
>>>>>> effects, with the underlying software taking care of the "causes", 
>>>>>> or rather how the effects are brought about.
>>>>>> In other words while we wouldn't want elements that have anything 
>>>>>> to do with "dojo" or "openrico" we would want elements to describe 
>>>>>> the effects from those libraries we'd like to have available 
>>>>>> through the widget, and the most appropriate is probably the Form 
>>>>>> Widget with different form and field types (though some would 
>>>>>> certainly go elsewhere and are not form related).
>>>>>> Examples of that would be a new form type like "live-grid" or a 
>>>>>> new form field type like "live-combobox" (or "dynamic-combobox" or 
>>>>>> "server-side-combobox" or something). If we add elements like that 
>>>>>> then it doesn't matter which AJAX library we use underneath and 
>>>>>> generate HTML/etc for, and we can change libraries without 
>>>>>> requiring any change to the higher level artifacts, like the form 
>>>>>> definitions.
>>>>>> -David
>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, 
>>>>>>> Dojo, etc) in the screen widgets, we need to discuss how that 
>>>>>>> support will appear in the screen widget XML files.
>>>>>>>
>>>>>>> I'll start things off with a suggestion I made in another thread. 
>>>>>>> Everyone is welcome to join in and offer their ideas. When we 
>>>>>>> reach an agreement, we can submit the results to Jira and begin 
>>>>>>> building it out.
>>>>>>>
>>>>>>> I was thinking we could simply extend the existing widgets with 
>>>>>>> additional attributes. The new attributes would pass 3rd party 
>>>>>>> specific data to the rendering classes. The new attributes are 
>>>>>>> ignored by rendering classes that don't need them. All rendering 
>>>>>>> classes render all widgets in some form - some rendering classes 
>>>>>>> might have additional bells and whistles based upon the 
>>>>>>> additional attributes, while others downgrade gracefully and 
>>>>>>> still provide a usable screen rendering.
>>>>>>>
>>>>>>>
>>>>>>> So, the widget XML would look something like this:
>>>>>>>
>>>>>>>
>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>>>>>>> ajax="some Ajax data" foo="some foo data">
>>>>>>> ...
>>>>>>> </container>
>>>>>>>
>>>>>>> The additional attributes could be applied to any screen widget 
>>>>>>> element, not just the container element.
>>>>>>>
>>>>>>> The advantage I see to this approach is it is fully backwards 
>>>>>>> compatible. We can add attributes to any screen widget element 
>>>>>>> without breaking existing rendering code.
>>>>>>>
>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------
>>>>>>> Looking for last minute shopping deals?  Find them fast with 
>>>>>>> Yahoo! Search.
>>
> 
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Daniel Martínez <da...@paradisosistemas.es>]

Jacopo,

 From what I have looked about XAP (since your mail) it seems to me as 
it could be used a replacement for OfBiz screen/widgets. Its most 
interesting features are the declarative UI in XML (like OfBiz 
screens/forms, except for the AJAX ;) and the independence of AJAX library.

XAP is what I would like OfBiz widgets to be :)
--
Daniel

Jacopo Cappellato escribió:
> Adrian,
>
> it is really great to see you are putting effort on this.
> As a side note, as I've already mentioned this in one of my mails some 
> time ago, I'm still wondering if the usage of XAP (one of the 
> incubating projects at Apache) could help us in this effort.
> Unfortunately I had no time to seriously look into it but if you are 
> interested you can get a quick overview of the tool here:
>
> http://incubator.apache.org/xap/overview.html
>
> Jacopo
>
>
> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>
>> David,
>>
>> I agree that there are some cool Ajax like features that won't map 
>> exactly to existing widgets. In that case we'll create a new widget 
>> and try to find an HTML equivalent. So, I'm not tossing out the idea 
>> of new widgets that have improved features, I'm suggesting let's 
>> start with adding new features to existing widgets.
>>
>> I have seen the Ajax work done in the Example component.
>>
>> Regarding the alternate HTML rendering classes, I don't think those 
>> will be needed. My thinking right now is to just evolve the existing 
>> HTML rendering classes.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Adrian,
>>> This sounds great for the elements that have some sort of natural 
>>> JS/AJAX extension that doesn't change what the form means or offers 
>>> to the user but instead just improves the user experience and/or 
>>> efficiency.
>>> With cases like I agree it would be great, and a REALLY cool 
>>> feature, to upgrade automatically and not require form changes or 
>>> anything.
>>> However, there are many cases where we can't automatically add 
>>> JS/AJAX extensions, but instead they represent a possible widget 
>>> that is different enough from the concept behind any of the existing 
>>> form field types that it would be weird to piggy back the 
>>> functionality and try to automatically shoe-horn it into the 
>>> existing functionality.
>>> Some of the stuff I played with recently and added, like an 
>>> auto-refresh on a screen container, is not something we would want 
>>> to automatically turn on. The other one I added recently, to submit 
>>> a form in the background and not refresh the page, is also something 
>>> that I don't think we would want to automatically turn on.
>>> So, yes, I agree we should add some of the automatic extensions that 
>>> we can and it would be a really cool set of new features.
>>> Stepping back to the original thingy, how does using alternate 
>>> HtmlFormRenderer classes help with this? Maybe you're not still 
>>> considering that, but I'd say if we did default fancy things (which 
>>> again, I love the idea of), we should just do those all the time 
>>> unless, like you wrote, the browser identifier is clearly one that 
>>> won't support it (some of that might need to be client side too 
>>> though... I'm not sure about all of the nuances there).
>>> -David
>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>> I'm resurrecting this thread because I've spent some time looking 
>>>> into the whole third party rendering library support idea and I 
>>>> think I have a simple solution.
>>>>
>>>> I thought about David's suggestion of having new widgets that are 
>>>> effects based. I don't think that will be a good strategy because 
>>>> not all browsers will have javascript enabled - which would render 
>>>> those widgets useless.
>>>>
>>>> A better approach I would like to propose is to use the Prototype 
>>>> javascript library in combination with EXISTING widgets to improve 
>>>> their response and functionality. The widget rendering code would 
>>>> detect if the browser supports javascript, and output the correct 
>>>> HTML to accommodate the browser.
>>>>
>>>> Instead of a "live-form" widget, the existing form widget would 
>>>> detect browser support, and render an improved form if the browser 
>>>> supports it. The current paginated tables would use Ajax calls to 
>>>> scroll through pages instead of refreshing the whole screen.
>>>>
>>>> Basically, I'd like to see the cool effects and improved response 
>>>> implemented without any additional work on the widget XML files.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> I guess this is a continuation of the discussion in the thread 
>>>>> "uilabels and screenlet widget", and is related somewhat to part 
>>>>> of the stuff in issue OFBIZ-1648.
>>>>> The general goal of the widgets is simple: no platform specific 
>>>>> artifacts. Unfortunately this isn't entirely possible, which is 
>>>>> why we have a very big and ugly "platform-specific" tag to 
>>>>> delineate things that are not generic and provide for the possible 
>>>>> of having alternative platform things specified together so that 
>>>>> when rendering for a different target the appropriate option can 
>>>>> be selected.
>>>>> As far as that applies to this topic, I'd say the best approach is 
>>>>> to never have any element or attribute called "dojo" or "ajax" or 
>>>>> "rico" or anything. In the dojo attribute for the container 
>>>>> elements, I'm not sure what you'd propose to put in it, ie the 
>>>>> "some Dojo data", but in general I'd prefer to never have anything 
>>>>> that is so dependent on a particular underlying technology, the 
>>>>> widget artifacts gain efficiency by their focus on different 
>>>>> effects, with the underlying software taking care of the "causes", 
>>>>> or rather how the effects are brought about.
>>>>> In other words while we wouldn't want elements that have anything 
>>>>> to do with "dojo" or "openrico" we would want elements to describe 
>>>>> the effects from those libraries we'd like to have available 
>>>>> through the widget, and the most appropriate is probably the Form 
>>>>> Widget with different form and field types (though some would 
>>>>> certainly go elsewhere and are not form related).
>>>>> Examples of that would be a new form type like "live-grid" or a 
>>>>> new form field type like "live-combobox" (or "dynamic-combobox" or 
>>>>> "server-side-combobox" or something). If we add elements like that 
>>>>> then it doesn't matter which AJAX library we use underneath and 
>>>>> generate HTML/etc for, and we can change libraries without 
>>>>> requiring any change to the higher level artifacts, like the form 
>>>>> definitions.
>>>>> -David
>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, 
>>>>>> Dojo, etc) in the screen widgets, we need to discuss how that 
>>>>>> support will appear in the screen widget XML files.
>>>>>>
>>>>>> I'll start things off with a suggestion I made in another thread. 
>>>>>> Everyone is welcome to join in and offer their ideas. When we 
>>>>>> reach an agreement, we can submit the results to Jira and begin 
>>>>>> building it out.
>>>>>>
>>>>>> I was thinking we could simply extend the existing widgets with 
>>>>>> additional attributes. The new attributes would pass 3rd party 
>>>>>> specific data to the rendering classes. The new attributes are 
>>>>>> ignored by rendering classes that don't need them. All rendering 
>>>>>> classes render all widgets in some form - some rendering classes 
>>>>>> might have additional bells and whistles based upon the 
>>>>>> additional attributes, while others downgrade gracefully and 
>>>>>> still provide a usable screen rendering.
>>>>>>
>>>>>>
>>>>>> So, the widget XML would look something like this:
>>>>>>
>>>>>>
>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>>>>>> ajax="some Ajax data" foo="some foo data">
>>>>>> ...
>>>>>> </container>
>>>>>>
>>>>>> The additional attributes could be applied to any screen widget 
>>>>>> element, not just the container element.
>>>>>>
>>>>>> The advantage I see to this approach is it is fully backwards 
>>>>>> compatible. We can add attributes to any screen widget element 
>>>>>> without breaking existing rendering code.
>>>>>>
>>>>>> That's it. Like I said, please add your ideas.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------
>>>>>> Looking for last minute shopping deals?  Find them fast with 
>>>>>> Yahoo! Search.
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacques Le Roux <ja...@les7arts.com>]

But is not XAP another kind of beast ? Maybe with the same CSS drawbacks though, I had only a cursory review (to be sure it was easy 
to localise). Sorry no time neither, still continuing to work on french labels in my free time, tedious...

Jacques

From: "Adrian Crum" <ad...@hlmksw.com>
> Jacopo,
>
> Thank you for the reminder. After spending some time looking at various tool kits, I came to the conclusion that they are overkill 
> for what we need. But that's just my opinion.
>
> The tool kits typically have their own CSS styles and they have their own way of doing things that don't mesh well with OFBiz. I'm 
> thinking we can accomplish a lot of UI wizardry on our own with just a little javascript and maybe some new CSS styles.
>
> I'm working on some POC code right now that I hope will demonstrate how - by integrating Prototype into the screen widgets - it 
> will be trivial to have an improved UI.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> Adrian,
>>
>> it is really great to see you are putting effort on this.
>> As a side note, as I've already mentioned this in one of my mails some time ago, I'm still wondering if the usage of XAP (one of 
>> the incubating projects at Apache) could help us in this effort.
>> Unfortunately I had no time to seriously look into it but if you are interested you can get a quick overview of the tool here:
>>
>> http://incubator.apache.org/xap/overview.html
>>
>> Jacopo
>>
>>
>> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
>>
>>> David,
>>>
>>> I agree that there are some cool Ajax like features that won't map exactly to existing widgets. In that case we'll create a new 
>>> widget and try to find an HTML equivalent. So, I'm not tossing out the idea of new widgets that have improved features, I'm 
>>> suggesting let's start with adding new features to existing widgets.
>>>
>>> I have seen the Ajax work done in the Example component.
>>>
>>> Regarding the alternate HTML rendering classes, I don't think those will be needed. My thinking right now is to just evolve the 
>>> existing HTML rendering classes.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> Adrian,
>>>> This sounds great for the elements that have some sort of natural JS/AJAX extension that doesn't change what the form means or 
>>>> offers to the user but instead just improves the user experience and/or efficiency.
>>>> With cases like I agree it would be great, and a REALLY cool feature, to upgrade automatically and not require form changes or 
>>>> anything.
>>>> However, there are many cases where we can't automatically add JS/AJAX extensions, but instead they represent a possible widget 
>>>> that is different enough from the concept behind any of the existing form field types that it would be weird to piggy back the 
>>>> functionality and try to automatically shoe-horn it into the existing functionality.
>>>> Some of the stuff I played with recently and added, like an auto-refresh on a screen container, is not something we would want 
>>>> to automatically turn on. The other one I added recently, to submit a form in the background and not refresh the page, is also 
>>>> something that I don't think we would want to automatically turn on.
>>>> So, yes, I agree we should add some of the automatic extensions that we can and it would be a really cool set of new features.
>>>> Stepping back to the original thingy, how does using alternate HtmlFormRenderer classes help with this? Maybe you're not still 
>>>> considering that, but I'd say if we did default fancy things (which again, I love the idea of), we should just do those all the 
>>>> time unless, like you wrote, the browser identifier is clearly one that won't support it (some of that might need to be client 
>>>> side too though... I'm not sure about all of the nuances there).
>>>> -David
>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>> I'm resurrecting this thread because I've spent some time looking into the whole third party rendering library support idea 
>>>>> and I think I have a simple solution.
>>>>>
>>>>> I thought about David's suggestion of having new widgets that are effects based. I don't think that will be a good strategy 
>>>>> because not all browsers will have javascript enabled - which would render those widgets useless.
>>>>>
>>>>> A better approach I would like to propose is to use the Prototype javascript library in combination with EXISTING widgets to 
>>>>> improve their response and functionality. The widget rendering code would detect if the browser supports javascript, and 
>>>>> output the correct HTML to accommodate the browser.
>>>>>
>>>>> Instead of a "live-form" widget, the existing form widget would detect browser support, and render an improved form if the 
>>>>> browser supports it. The current paginated tables would use Ajax calls to scroll through pages instead of refreshing the whole 
>>>>> screen.
>>>>>
>>>>> Basically, I'd like to see the cool effects and improved response implemented without any additional work on the widget XML 
>>>>> files.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> I guess this is a continuation of the discussion in the thread "uilabels and screenlet widget", and is related somewhat to 
>>>>>> part of the stuff in issue OFBIZ-1648.
>>>>>> The general goal of the widgets is simple: no platform specific artifacts. Unfortunately this isn't entirely possible, which 
>>>>>> is why we have a very big and ugly "platform-specific" tag to delineate things that are not generic and provide for the 
>>>>>> possible of having alternative platform things specified together so that when rendering for a different target the 
>>>>>> appropriate option can be selected.
>>>>>> As far as that applies to this topic, I'd say the best approach is to never have any element or attribute called "dojo" or 
>>>>>> "ajax" or "rico" or anything. In the dojo attribute for the container elements, I'm not sure what you'd propose to put in it, 
>>>>>> ie the "some Dojo data", but in general I'd prefer to never have anything that is so dependent on a particular underlying 
>>>>>> technology, the widget artifacts gain efficiency by their focus on different effects, with the underlying software taking 
>>>>>> care of the "causes", or rather how the effects are brought about.
>>>>>> In other words while we wouldn't want elements that have anything to do with "dojo" or "openrico" we would want elements to 
>>>>>> describe the effects from those libraries we'd like to have available through the widget, and the most appropriate is 
>>>>>> probably the Form Widget with different form and field types (though some would certainly go elsewhere and are not form 
>>>>>> related).
>>>>>> Examples of that would be a new form type like "live-grid" or a new form field type like "live-combobox" (or 
>>>>>> "dynamic-combobox" or "server-side-combobox" or something). If we add elements like that then it doesn't matter which AJAX 
>>>>>> library we use underneath and generate HTML/etc for, and we can change libraries without requiring any change to the higher 
>>>>>> level artifacts, like the form definitions.
>>>>>> -David
>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo, etc) in the screen widgets, we need to discuss how that 
>>>>>>> support will appear in the screen widget XML files.
>>>>>>>
>>>>>>> I'll start things off with a suggestion I made in another thread. Everyone is welcome to join in and offer their ideas. When 
>>>>>>> we reach an agreement, we can submit the results to Jira and begin building it out.
>>>>>>>
>>>>>>> I was thinking we could simply extend the existing widgets with additional attributes. The new attributes would pass 3rd 
>>>>>>> party specific data to the rendering classes. The new attributes are ignored by rendering classes that don't need them. All 
>>>>>>> rendering classes render all widgets in some form - some rendering classes might have additional bells and whistles based 
>>>>>>> upon the additional attributes, while others downgrade gracefully and still provide a usable screen rendering.
>>>>>>>
>>>>>>>
>>>>>>> So, the widget XML would look something like this:
>>>>>>>
>>>>>>>
>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data" ajax="some Ajax data" foo="some foo data">
>>>>>>> ...
>>>>>>> </container>
>>>>>>>
>>>>>>> The additional attributes could be applied to any screen widget element, not just the container element.
>>>>>>>
>>>>>>> The advantage I see to this approach is it is fully backwards compatible. We can add attributes to any screen widget element 
>>>>>>> without breaking existing rendering code.
>>>>>>>
>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------
>>>>>>> Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
>>
>>
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@hlmksw.com>]

Jacopo,

Thank you for the reminder. After spending some time looking at various 
tool kits, I came to the conclusion that they are overkill for what we 
need. But that's just my opinion.

The tool kits typically have their own CSS styles and they have their 
own way of doing things that don't mesh well with OFBiz. I'm thinking we 
can accomplish a lot of UI wizardry on our own with just a little 
javascript and maybe some new CSS styles.

I'm working on some POC code right now that I hope will demonstrate how 
- by integrating Prototype into the screen widgets - it will be trivial 
to have an improved UI.

-Adrian

Jacopo Cappellato wrote:
> Adrian,
> 
> it is really great to see you are putting effort on this.
> As a side note, as I've already mentioned this in one of my mails some 
> time ago, I'm still wondering if the usage of XAP (one of the incubating 
> projects at Apache) could help us in this effort.
> Unfortunately I had no time to seriously look into it but if you are 
> interested you can get a quick overview of the tool here:
> 
> http://incubator.apache.org/xap/overview.html
> 
> Jacopo
> 
> 
> On May 7, 2008, at 4:48 PM, Adrian Crum wrote:
> 
>> David,
>>
>> I agree that there are some cool Ajax like features that won't map 
>> exactly to existing widgets. In that case we'll create a new widget 
>> and try to find an HTML equivalent. So, I'm not tossing out the idea 
>> of new widgets that have improved features, I'm suggesting let's start 
>> with adding new features to existing widgets.
>>
>> I have seen the Ajax work done in the Example component.
>>
>> Regarding the alternate HTML rendering classes, I don't think those 
>> will be needed. My thinking right now is to just evolve the existing 
>> HTML rendering classes.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Adrian,
>>> This sounds great for the elements that have some sort of natural 
>>> JS/AJAX extension that doesn't change what the form means or offers 
>>> to the user but instead just improves the user experience and/or 
>>> efficiency.
>>> With cases like I agree it would be great, and a REALLY cool feature, 
>>> to upgrade automatically and not require form changes or anything.
>>> However, there are many cases where we can't automatically add 
>>> JS/AJAX extensions, but instead they represent a possible widget that 
>>> is different enough from the concept behind any of the existing form 
>>> field types that it would be weird to piggy back the functionality 
>>> and try to automatically shoe-horn it into the existing functionality.
>>> Some of the stuff I played with recently and added, like an 
>>> auto-refresh on a screen container, is not something we would want to 
>>> automatically turn on. The other one I added recently, to submit a 
>>> form in the background and not refresh the page, is also something 
>>> that I don't think we would want to automatically turn on.
>>> So, yes, I agree we should add some of the automatic extensions that 
>>> we can and it would be a really cool set of new features.
>>> Stepping back to the original thingy, how does using alternate 
>>> HtmlFormRenderer classes help with this? Maybe you're not still 
>>> considering that, but I'd say if we did default fancy things (which 
>>> again, I love the idea of), we should just do those all the time 
>>> unless, like you wrote, the browser identifier is clearly one that 
>>> won't support it (some of that might need to be client side too 
>>> though... I'm not sure about all of the nuances there).
>>> -David
>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>> I'm resurrecting this thread because I've spent some time looking 
>>>> into the whole third party rendering library support idea and I 
>>>> think I have a simple solution.
>>>>
>>>> I thought about David's suggestion of having new widgets that are 
>>>> effects based. I don't think that will be a good strategy because 
>>>> not all browsers will have javascript enabled - which would render 
>>>> those widgets useless.
>>>>
>>>> A better approach I would like to propose is to use the Prototype 
>>>> javascript library in combination with EXISTING widgets to improve 
>>>> their response and functionality. The widget rendering code would 
>>>> detect if the browser supports javascript, and output the correct 
>>>> HTML to accommodate the browser.
>>>>
>>>> Instead of a "live-form" widget, the existing form widget would 
>>>> detect browser support, and render an improved form if the browser 
>>>> supports it. The current paginated tables would use Ajax calls to 
>>>> scroll through pages instead of refreshing the whole screen.
>>>>
>>>> Basically, I'd like to see the cool effects and improved response 
>>>> implemented without any additional work on the widget XML files.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> I guess this is a continuation of the discussion in the thread 
>>>>> "uilabels and screenlet widget", and is related somewhat to part of 
>>>>> the stuff in issue OFBIZ-1648.
>>>>> The general goal of the widgets is simple: no platform specific 
>>>>> artifacts. Unfortunately this isn't entirely possible, which is why 
>>>>> we have a very big and ugly "platform-specific" tag to delineate 
>>>>> things that are not generic and provide for the possible of having 
>>>>> alternative platform things specified together so that when 
>>>>> rendering for a different target the appropriate option can be 
>>>>> selected.
>>>>> As far as that applies to this topic, I'd say the best approach is 
>>>>> to never have any element or attribute called "dojo" or "ajax" or 
>>>>> "rico" or anything. In the dojo attribute for the container 
>>>>> elements, I'm not sure what you'd propose to put in it, ie the 
>>>>> "some Dojo data", but in general I'd prefer to never have anything 
>>>>> that is so dependent on a particular underlying technology, the 
>>>>> widget artifacts gain efficiency by their focus on different 
>>>>> effects, with the underlying software taking care of the "causes", 
>>>>> or rather how the effects are brought about.
>>>>> In other words while we wouldn't want elements that have anything 
>>>>> to do with "dojo" or "openrico" we would want elements to describe 
>>>>> the effects from those libraries we'd like to have available 
>>>>> through the widget, and the most appropriate is probably the Form 
>>>>> Widget with different form and field types (though some would 
>>>>> certainly go elsewhere and are not form related).
>>>>> Examples of that would be a new form type like "live-grid" or a new 
>>>>> form field type like "live-combobox" (or "dynamic-combobox" or 
>>>>> "server-side-combobox" or something). If we add elements like that 
>>>>> then it doesn't matter which AJAX library we use underneath and 
>>>>> generate HTML/etc for, and we can change libraries without 
>>>>> requiring any change to the higher level artifacts, like the form 
>>>>> definitions.
>>>>> -David
>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo, 
>>>>>> etc) in the screen widgets, we need to discuss how that support 
>>>>>> will appear in the screen widget XML files.
>>>>>>
>>>>>> I'll start things off with a suggestion I made in another thread. 
>>>>>> Everyone is welcome to join in and offer their ideas. When we 
>>>>>> reach an agreement, we can submit the results to Jira and begin 
>>>>>> building it out.
>>>>>>
>>>>>> I was thinking we could simply extend the existing widgets with 
>>>>>> additional attributes. The new attributes would pass 3rd party 
>>>>>> specific data to the rendering classes. The new attributes are 
>>>>>> ignored by rendering classes that don't need them. All rendering 
>>>>>> classes render all widgets in some form - some rendering classes 
>>>>>> might have additional bells and whistles based upon the additional 
>>>>>> attributes, while others downgrade gracefully and still provide a 
>>>>>> usable screen rendering.
>>>>>>
>>>>>>
>>>>>> So, the widget XML would look something like this:
>>>>>>
>>>>>>
>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>>>>>> ajax="some Ajax data" foo="some foo data">
>>>>>> ...
>>>>>> </container>
>>>>>>
>>>>>> The additional attributes could be applied to any screen widget 
>>>>>> element, not just the container element.
>>>>>>
>>>>>> The advantage I see to this approach is it is fully backwards 
>>>>>> compatible. We can add attributes to any screen widget element 
>>>>>> without breaking existing rendering code.
>>>>>>
>>>>>> That's it. Like I said, please add your ideas.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------
>>>>>> Looking for last minute shopping deals?  Find them fast with 
>>>>>> Yahoo! Search.
> 
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacopo Cappellato <ja...@gmail.com>]

Adrian,

it is really great to see you are putting effort on this.
As a side note, as I've already mentioned this in one of my mails some  
time ago, I'm still wondering if the usage of XAP (one of the  
incubating projects at Apache) could help us in this effort.
Unfortunately I had no time to seriously look into it but if you are  
interested you can get a quick overview of the tool here:

http://incubator.apache.org/xap/overview.html

Jacopo


On May 7, 2008, at 4:48 PM, Adrian Crum wrote:

> David,
>
> I agree that there are some cool Ajax like features that won't map  
> exactly to existing widgets. In that case we'll create a new widget  
> and try to find an HTML equivalent. So, I'm not tossing out the idea  
> of new widgets that have improved features, I'm suggesting let's  
> start with adding new features to existing widgets.
>
> I have seen the Ajax work done in the Example component.
>
> Regarding the alternate HTML rendering classes, I don't think those  
> will be needed. My thinking right now is to just evolve the existing  
> HTML rendering classes.
>
> -Adrian
>
> David E Jones wrote:
>> Adrian,
>> This sounds great for the elements that have some sort of natural  
>> JS/AJAX extension that doesn't change what the form means or offers  
>> to the user but instead just improves the user experience and/or  
>> efficiency.
>> With cases like I agree it would be great, and a REALLY cool  
>> feature, to upgrade automatically and not require form changes or  
>> anything.
>> However, there are many cases where we can't automatically add JS/ 
>> AJAX extensions, but instead they represent a possible widget that  
>> is different enough from the concept behind any of the existing  
>> form field types that it would be weird to piggy back the  
>> functionality and try to automatically shoe-horn it into the  
>> existing functionality.
>> Some of the stuff I played with recently and added, like an auto- 
>> refresh on a screen container, is not something we would want to  
>> automatically turn on. The other one I added recently, to submit a  
>> form in the background and not refresh the page, is also something  
>> that I don't think we would want to automatically turn on.
>> So, yes, I agree we should add some of the automatic extensions  
>> that we can and it would be a really cool set of new features.
>> Stepping back to the original thingy, how does using alternate  
>> HtmlFormRenderer classes help with this? Maybe you're not still  
>> considering that, but I'd say if we did default fancy things (which  
>> again, I love the idea of), we should just do those all the time  
>> unless, like you wrote, the browser identifier is clearly one that  
>> won't support it (some of that might need to be client side too  
>> though... I'm not sure about all of the nuances there).
>> -David
>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>> I'm resurrecting this thread because I've spent some time looking  
>>> into the whole third party rendering library support idea and I  
>>> think I have a simple solution.
>>>
>>> I thought about David's suggestion of having new widgets that are  
>>> effects based. I don't think that will be a good strategy because  
>>> not all browsers will have javascript enabled - which would render  
>>> those widgets useless.
>>>
>>> A better approach I would like to propose is to use the Prototype  
>>> javascript library in combination with EXISTING widgets to improve  
>>> their response and functionality. The widget rendering code would  
>>> detect if the browser supports javascript, and output the correct  
>>> HTML to accommodate the browser.
>>>
>>> Instead of a "live-form" widget, the existing form widget would  
>>> detect browser support, and render an improved form if the browser  
>>> supports it. The current paginated tables would use Ajax calls to  
>>> scroll through pages instead of refreshing the whole screen.
>>>
>>> Basically, I'd like to see the cool effects and improved response  
>>> implemented without any additional work on the widget XML files.
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> I guess this is a continuation of the discussion in the thread  
>>>> "uilabels and screenlet widget", and is related somewhat to part  
>>>> of the stuff in issue OFBIZ-1648.
>>>> The general goal of the widgets is simple: no platform specific  
>>>> artifacts. Unfortunately this isn't entirely possible, which is  
>>>> why we have a very big and ugly "platform-specific" tag to  
>>>> delineate things that are not generic and provide for the  
>>>> possible of having alternative platform things specified together  
>>>> so that when rendering for a different target the appropriate  
>>>> option can be selected.
>>>> As far as that applies to this topic, I'd say the best approach  
>>>> is to never have any element or attribute called "dojo" or "ajax"  
>>>> or "rico" or anything. In the dojo attribute for the container  
>>>> elements, I'm not sure what you'd propose to put in it, ie the  
>>>> "some Dojo data", but in general I'd prefer to never have  
>>>> anything that is so dependent on a particular underlying  
>>>> technology, the widget artifacts gain efficiency by their focus  
>>>> on different effects, with the underlying software taking care of  
>>>> the "causes", or rather how the effects are brought about.
>>>> In other words while we wouldn't want elements that have anything  
>>>> to do with "dojo" or "openrico" we would want elements to  
>>>> describe the effects from those libraries we'd like to have  
>>>> available through the widget, and the most appropriate is  
>>>> probably the Form Widget with different form and field types  
>>>> (though some would certainly go elsewhere and are not form  
>>>> related).
>>>> Examples of that would be a new form type like "live-grid" or a  
>>>> new form field type like "live-combobox" (or "dynamic-combobox"  
>>>> or "server-side-combobox" or something). If we add elements like  
>>>> that then it doesn't matter which AJAX library we use underneath  
>>>> and generate HTML/etc for, and we can change libraries without  
>>>> requiring any change to the higher level artifacts, like the form  
>>>> definitions.
>>>> -David
>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>> In order to accommodate 3rd party rendering libraries (Ajax,  
>>>>> Dojo, etc) in the screen widgets, we need to discuss how that  
>>>>> support will appear in the screen widget XML files.
>>>>>
>>>>> I'll start things off with a suggestion I made in another  
>>>>> thread. Everyone is welcome to join in and offer their ideas.  
>>>>> When we reach an agreement, we can submit the results to Jira  
>>>>> and begin building it out.
>>>>>
>>>>> I was thinking we could simply extend the existing widgets with  
>>>>> additional attributes. The new attributes would pass 3rd party  
>>>>> specific data to the rendering classes. The new attributes are  
>>>>> ignored by rendering classes that don't need them. All rendering  
>>>>> classes render all widgets in some form - some rendering classes  
>>>>> might have additional bells and whistles based upon the  
>>>>> additional attributes, while others downgrade gracefully and  
>>>>> still provide a usable screen rendering.
>>>>>
>>>>>
>>>>> So, the widget XML would look something like this:
>>>>>
>>>>>
>>>>> <container id="some-id" style="some-style" dojo="some Dojo data"  
>>>>> ajax="some Ajax data" foo="some foo data">
>>>>> ...
>>>>> </container>
>>>>>
>>>>> The additional attributes could be applied to any screen widget  
>>>>> element, not just the container element.
>>>>>
>>>>> The advantage I see to this approach is it is fully backwards  
>>>>> compatible. We can add attributes to any screen widget element  
>>>>> without breaking existing rendering code.
>>>>>
>>>>> That's it. Like I said, please add your ideas.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------
>>>>> Looking for last minute shopping deals?  Find them fast with  
>>>>> Yahoo! Search.

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacques Le Roux <ja...@les7arts.com>]

I think this is interesting (even if this implies to have js used). Maybe you could provide a patch for future discussion ?

Note that there are already pages for this in Wiki http://docs.ofbiz.org/display/OFBIZ/Screen+and+Form+Widget+Enhancements

Jacques

From: "guo weizhan" <gu...@gmail.com>
> This is the old topic but I'm still interesting in this. If there is not
> good method to add 3rd party rendering libraries, how about enhance the
> current widget? We can extends the current widgets and append some
> attributes to let the widgets can work with other libraries, take the dojo
> for example:
> <field name="**" title="${uiLabelMap.**}"
> tooltip="${uiLabelMap.**}" dojoType="dijit.form.TextBox"
> trim="true"></field>
> 
> 
> 2008/5/10 Adrian Crum <ad...@hlmksw.com>
>>
>> I submitted a patch to Jira -
> https://issues.apache.org/jira/browse/OFBIZ-1648. It's a start, let me know
> what you think.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>>
>>> Adrian,
>>>
>>> That sounds good to me. I'm always hesitant to say it because if the
> inherent inaccuracy of any human communication, but I think "we're on the
> same page here".
>>>
>>> -David
>>>
>>>
>>> On May 7, 2008, at 8:48 AM, Adrian Crum wrote:
>>>
>>>> David,
>>>>
>>>> I agree that there are some cool Ajax like features that won't map
> exactly to existing widgets. In that case we'll create a new widget and try
> to find an HTML equivalent. So, I'm not tossing out the idea of new widgets
> that have improved features, I'm suggesting let's start with adding new
> features to existing widgets.
>>>>
>>>> I have seen the Ajax work done in the Example component.
>>>>
>>>> Regarding the alternate HTML rendering classes, I don't think those will
> be needed. My thinking right now is to just evolve the existing HTML
> rendering classes.
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>>
>>>>> Adrian,
>>>>> This sounds great for the elements that have some sort of natural
> JS/AJAX extension that doesn't change what the form means or offers to the
> user but instead just improves the user experience and/or efficiency.
>>>>> With cases like I agree it would be great, and a REALLY cool feature,
> to upgrade automatically and not require form changes or anything.
>>>>> However, there are many cases where we can't automatically add JS/AJAX
> extensions, but instead they represent a possible widget that is different
> enough from the concept behind any of the existing form field types that it
> would be weird to piggy back the functionality and try to automatically
> shoe-horn it into the existing functionality.
>>>>> Some of the stuff I played with recently and added, like an
> auto-refresh on a screen container, is not something we would want to
> automatically turn on. The other one I added recently, to submit a form in
> the background and not refresh the page, is also something that I don't
> think we would want to automatically turn on.
>>>>> So, yes, I agree we should add some of the automatic extensions that we
> can and it would be a really cool set of new features.
>>>>> Stepping back to the original thingy, how does using alternate
> HtmlFormRenderer classes help with this? Maybe you're not still considering
> that, but I'd say if we did default fancy things (which again, I love the
> idea of), we should just do those all the time unless, like you wrote, the
> browser identifier is clearly one that won't support it (some of that might
> need to be client side too though... I'm not sure about all of the nuances
> there).
>>>>> -David
>>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>>>
>>>>>> I'm resurrecting this thread because I've spent some time looking into
> the whole third party rendering library support idea and I think I have a
> simple solution.
>>>>>>
>>>>>> I thought about David's suggestion of having new widgets that are
> effects based. I don't think that will be a good strategy because not all
> browsers will have javascript enabled - which would render those widgets
> useless.
>>>>>>
>>>>>> A better approach I would like to propose is to use the Prototype
> javascript library in combination with EXISTING widgets to improve their
> response and functionality. The widget rendering code would detect if the
> browser supports javascript, and output the correct HTML to accommodate the
> browser.
>>>>>>
>>>>>> Instead of a "live-form" widget, the existing form widget would detect
> browser support, and render an improved form if the browser supports it. The
> current paginated tables would use Ajax calls to scroll through pages
> instead of refreshing the whole screen.
>>>>>>
>>>>>> Basically, I'd like to see the cool effects and improved response
> implemented without any additional work on the widget XML files.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>>
>>>>>>> I guess this is a continuation of the discussion in the thread
> "uilabels and screenlet widget", and is related somewhat to part of the
> stuff in issue OFBIZ-1648.
>>>>>>> The general goal of the widgets is simple: no platform specific
> artifacts. Unfortunately this isn't entirely possible, which is why we have
> a very big and ugly "platform-specific" tag to delineate things that are not
> generic and provide for the possible of having alternative platform things
> specified together so that when rendering for a different target the
> appropriate option can be selected.
>>>>>>> As far as that applies to this topic, I'd say the best approach is to
> never have any element or attribute called "dojo" or "ajax" or "rico" or
> anything. In the dojo attribute for the container elements, I'm not sure
> what you'd propose to put in it, ie the "some Dojo data", but in general I'd
> prefer to never have anything that is so dependent on a particular
> underlying technology, the widget artifacts gain efficiency by their focus
> on different effects, with the underlying software taking care of the
> "causes", or rather how the effects are brought about.
>>>>>>> In other words while we wouldn't want elements that have anything to
> do with "dojo" or "openrico" we would want elements to describe the effects
> from those libraries we'd like to have available through the widget, and the
> most appropriate is probably the Form Widget with different form and field
> types (though some would certainly go elsewhere and are not form related).
>>>>>>> Examples of that would be a new form type like "live-grid" or a new
> form field type like "live-combobox" (or "dynamic-combobox" or
> "server-side-combobox" or something). If we add elements like that then it
> doesn't matter which AJAX library we use underneath and generate HTML/etc
> for, and we can change libraries without requiring any change to the higher
> level artifacts, like the form definitions.
>>>>>>> -David
>>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>>>
>>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo,
> etc) in the screen widgets, we need to discuss how that support will appear
> in the screen widget XML files.
>>>>>>>>
>>>>>>>> I'll start things off with a suggestion I made in another thread.
> Everyone is welcome to join in and offer their ideas. When we reach an
> agreement, we can submit the results to Jira and begin building it out.
>>>>>>>>
>>>>>>>> I was thinking we could simply extend the existing widgets with
> additional attributes. The new attributes would pass 3rd party specific data
> to the rendering classes. The new attributes are ignored by rendering
> classes that don't need them. All rendering classes render all widgets in
> some form - some rendering classes might have additional bells and whistles
> based upon the additional attributes, while others downgrade gracefully and
> still provide a usable screen rendering.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, the widget XML would look something like this:
>>>>>>>>
>>>>>>>>
>>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data"
> ajax="some Ajax data" foo="some foo data">
>>>>>>>> ...
>>>>>>>> </container>
>>>>>>>>
>>>>>>>> The additional attributes could be applied to any screen widget
> element, not just the container element.
>>>>>>>>
>>>>>>>> The advantage I see to this approach is it is fully backwards
> compatible. We can add attributes to any screen widget element without
> breaking existing rendering code.
>>>>>>>>
>>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------
>>>>>>>> Looking for last minute shopping deals?  Find them fast with Yahoo!
> Search.
>>>
>>>
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[guo weizhan <gu...@gmail.com>]

This is the old topic but I'm still interesting in this. If there is not
good method to add 3rd party rendering libraries, how about enhance the
current widget? We can extends the current widgets and append some
attributes to let the widgets can work with other libraries, take the dojo
for example:
 <field name="**" title="${uiLabelMap.**}"
 tooltip="${uiLabelMap.**}" dojoType="dijit.form.TextBox"
 trim="true"></field>


 2008/5/10 Adrian Crum <ad...@hlmksw.com>
>
> I submitted a patch to Jira -
https://issues.apache.org/jira/browse/OFBIZ-1648. It's a start, let me know
what you think.
>
> -Adrian
>
> David E Jones wrote:
>>
>> Adrian,
>>
>> That sounds good to me. I'm always hesitant to say it because if the
inherent inaccuracy of any human communication, but I think "we're on the
same page here".
>>
>> -David
>>
>>
>> On May 7, 2008, at 8:48 AM, Adrian Crum wrote:
>>
>>> David,
>>>
>>> I agree that there are some cool Ajax like features that won't map
exactly to existing widgets. In that case we'll create a new widget and try
to find an HTML equivalent. So, I'm not tossing out the idea of new widgets
that have improved features, I'm suggesting let's start with adding new
features to existing widgets.
>>>
>>> I have seen the Ajax work done in the Example component.
>>>
>>> Regarding the alternate HTML rendering classes, I don't think those will
be needed. My thinking right now is to just evolve the existing HTML
rendering classes.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>>
>>>> Adrian,
>>>> This sounds great for the elements that have some sort of natural
JS/AJAX extension that doesn't change what the form means or offers to the
user but instead just improves the user experience and/or efficiency.
>>>> With cases like I agree it would be great, and a REALLY cool feature,
to upgrade automatically and not require form changes or anything.
>>>> However, there are many cases where we can't automatically add JS/AJAX
extensions, but instead they represent a possible widget that is different
enough from the concept behind any of the existing form field types that it
would be weird to piggy back the functionality and try to automatically
shoe-horn it into the existing functionality.
>>>> Some of the stuff I played with recently and added, like an
auto-refresh on a screen container, is not something we would want to
automatically turn on. The other one I added recently, to submit a form in
the background and not refresh the page, is also something that I don't
think we would want to automatically turn on.
>>>> So, yes, I agree we should add some of the automatic extensions that we
can and it would be a really cool set of new features.
>>>> Stepping back to the original thingy, how does using alternate
HtmlFormRenderer classes help with this? Maybe you're not still considering
that, but I'd say if we did default fancy things (which again, I love the
idea of), we should just do those all the time unless, like you wrote, the
browser identifier is clearly one that won't support it (some of that might
need to be client side too though... I'm not sure about all of the nuances
there).
>>>> -David
>>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>>>
>>>>> I'm resurrecting this thread because I've spent some time looking into
the whole third party rendering library support idea and I think I have a
simple solution.
>>>>>
>>>>> I thought about David's suggestion of having new widgets that are
effects based. I don't think that will be a good strategy because not all
browsers will have javascript enabled - which would render those widgets
useless.
>>>>>
>>>>> A better approach I would like to propose is to use the Prototype
javascript library in combination with EXISTING widgets to improve their
response and functionality. The widget rendering code would detect if the
browser supports javascript, and output the correct HTML to accommodate the
browser.
>>>>>
>>>>> Instead of a "live-form" widget, the existing form widget would detect
browser support, and render an improved form if the browser supports it. The
current paginated tables would use Ajax calls to scroll through pages
instead of refreshing the whole screen.
>>>>>
>>>>> Basically, I'd like to see the cool effects and improved response
implemented without any additional work on the widget XML files.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>>
>>>>>> I guess this is a continuation of the discussion in the thread
"uilabels and screenlet widget", and is related somewhat to part of the
stuff in issue OFBIZ-1648.
>>>>>> The general goal of the widgets is simple: no platform specific
artifacts. Unfortunately this isn't entirely possible, which is why we have
a very big and ugly "platform-specific" tag to delineate things that are not
generic and provide for the possible of having alternative platform things
specified together so that when rendering for a different target the
appropriate option can be selected.
>>>>>> As far as that applies to this topic, I'd say the best approach is to
never have any element or attribute called "dojo" or "ajax" or "rico" or
anything. In the dojo attribute for the container elements, I'm not sure
what you'd propose to put in it, ie the "some Dojo data", but in general I'd
prefer to never have anything that is so dependent on a particular
underlying technology, the widget artifacts gain efficiency by their focus
on different effects, with the underlying software taking care of the
"causes", or rather how the effects are brought about.
>>>>>> In other words while we wouldn't want elements that have anything to
do with "dojo" or "openrico" we would want elements to describe the effects
from those libraries we'd like to have available through the widget, and the
most appropriate is probably the Form Widget with different form and field
types (though some would certainly go elsewhere and are not form related).
>>>>>> Examples of that would be a new form type like "live-grid" or a new
form field type like "live-combobox" (or "dynamic-combobox" or
"server-side-combobox" or something). If we add elements like that then it
doesn't matter which AJAX library we use underneath and generate HTML/etc
for, and we can change libraries without requiring any change to the higher
level artifacts, like the form definitions.
>>>>>> -David
>>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo,
etc) in the screen widgets, we need to discuss how that support will appear
in the screen widget XML files.
>>>>>>>
>>>>>>> I'll start things off with a suggestion I made in another thread.
Everyone is welcome to join in and offer their ideas. When we reach an
agreement, we can submit the results to Jira and begin building it out.
>>>>>>>
>>>>>>> I was thinking we could simply extend the existing widgets with
additional attributes. The new attributes would pass 3rd party specific data
to the rendering classes. The new attributes are ignored by rendering
classes that don't need them. All rendering classes render all widgets in
some form - some rendering classes might have additional bells and whistles
based upon the additional attributes, while others downgrade gracefully and
still provide a usable screen rendering.
>>>>>>>
>>>>>>>
>>>>>>> So, the widget XML would look something like this:
>>>>>>>
>>>>>>>
>>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data"
ajax="some Ajax data" foo="some foo data">
>>>>>>> ...
>>>>>>> </container>
>>>>>>>
>>>>>>> The additional attributes could be applied to any screen widget
element, not just the container element.
>>>>>>>
>>>>>>> The advantage I see to this approach is it is fully backwards
compatible. We can add attributes to any screen widget element without
breaking existing rendering code.
>>>>>>>
>>>>>>> That's it. Like I said, please add your ideas.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------
>>>>>>> Looking for last minute shopping deals?  Find them fast with Yahoo!
Search.
>>
>>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@hlmksw.com>]

I submitted a patch to Jira - 
https://issues.apache.org/jira/browse/OFBIZ-1648. It's a start, let me 
know what you think.

-Adrian

David E Jones wrote:
> 
> Adrian,
> 
> That sounds good to me. I'm always hesitant to say it because if the 
> inherent inaccuracy of any human communication, but I think "we're on 
> the same page here".
> 
> -David
> 
> 
> On May 7, 2008, at 8:48 AM, Adrian Crum wrote:
> 
>> David,
>>
>> I agree that there are some cool Ajax like features that won't map 
>> exactly to existing widgets. In that case we'll create a new widget 
>> and try to find an HTML equivalent. So, I'm not tossing out the idea 
>> of new widgets that have improved features, I'm suggesting let's start 
>> with adding new features to existing widgets.
>>
>> I have seen the Ajax work done in the Example component.
>>
>> Regarding the alternate HTML rendering classes, I don't think those 
>> will be needed. My thinking right now is to just evolve the existing 
>> HTML rendering classes.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Adrian,
>>> This sounds great for the elements that have some sort of natural 
>>> JS/AJAX extension that doesn't change what the form means or offers 
>>> to the user but instead just improves the user experience and/or 
>>> efficiency.
>>> With cases like I agree it would be great, and a REALLY cool feature, 
>>> to upgrade automatically and not require form changes or anything.
>>> However, there are many cases where we can't automatically add 
>>> JS/AJAX extensions, but instead they represent a possible widget that 
>>> is different enough from the concept behind any of the existing form 
>>> field types that it would be weird to piggy back the functionality 
>>> and try to automatically shoe-horn it into the existing functionality.
>>> Some of the stuff I played with recently and added, like an 
>>> auto-refresh on a screen container, is not something we would want to 
>>> automatically turn on. The other one I added recently, to submit a 
>>> form in the background and not refresh the page, is also something 
>>> that I don't think we would want to automatically turn on.
>>> So, yes, I agree we should add some of the automatic extensions that 
>>> we can and it would be a really cool set of new features.
>>> Stepping back to the original thingy, how does using alternate 
>>> HtmlFormRenderer classes help with this? Maybe you're not still 
>>> considering that, but I'd say if we did default fancy things (which 
>>> again, I love the idea of), we should just do those all the time 
>>> unless, like you wrote, the browser identifier is clearly one that 
>>> won't support it (some of that might need to be client side too 
>>> though... I'm not sure about all of the nuances there).
>>> -David
>>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>>> I'm resurrecting this thread because I've spent some time looking 
>>>> into the whole third party rendering library support idea and I 
>>>> think I have a simple solution.
>>>>
>>>> I thought about David's suggestion of having new widgets that are 
>>>> effects based. I don't think that will be a good strategy because 
>>>> not all browsers will have javascript enabled - which would render 
>>>> those widgets useless.
>>>>
>>>> A better approach I would like to propose is to use the Prototype 
>>>> javascript library in combination with EXISTING widgets to improve 
>>>> their response and functionality. The widget rendering code would 
>>>> detect if the browser supports javascript, and output the correct 
>>>> HTML to accommodate the browser.
>>>>
>>>> Instead of a "live-form" widget, the existing form widget would 
>>>> detect browser support, and render an improved form if the browser 
>>>> supports it. The current paginated tables would use Ajax calls to 
>>>> scroll through pages instead of refreshing the whole screen.
>>>>
>>>> Basically, I'd like to see the cool effects and improved response 
>>>> implemented without any additional work on the widget XML files.
>>>>
>>>> What do you think?
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> I guess this is a continuation of the discussion in the thread 
>>>>> "uilabels and screenlet widget", and is related somewhat to part of 
>>>>> the stuff in issue OFBIZ-1648.
>>>>> The general goal of the widgets is simple: no platform specific 
>>>>> artifacts. Unfortunately this isn't entirely possible, which is why 
>>>>> we have a very big and ugly "platform-specific" tag to delineate 
>>>>> things that are not generic and provide for the possible of having 
>>>>> alternative platform things specified together so that when 
>>>>> rendering for a different target the appropriate option can be 
>>>>> selected.
>>>>> As far as that applies to this topic, I'd say the best approach is 
>>>>> to never have any element or attribute called "dojo" or "ajax" or 
>>>>> "rico" or anything. In the dojo attribute for the container 
>>>>> elements, I'm not sure what you'd propose to put in it, ie the 
>>>>> "some Dojo data", but in general I'd prefer to never have anything 
>>>>> that is so dependent on a particular underlying technology, the 
>>>>> widget artifacts gain efficiency by their focus on different 
>>>>> effects, with the underlying software taking care of the "causes", 
>>>>> or rather how the effects are brought about.
>>>>> In other words while we wouldn't want elements that have anything 
>>>>> to do with "dojo" or "openrico" we would want elements to describe 
>>>>> the effects from those libraries we'd like to have available 
>>>>> through the widget, and the most appropriate is probably the Form 
>>>>> Widget with different form and field types (though some would 
>>>>> certainly go elsewhere and are not form related).
>>>>> Examples of that would be a new form type like "live-grid" or a new 
>>>>> form field type like "live-combobox" (or "dynamic-combobox" or 
>>>>> "server-side-combobox" or something). If we add elements like that 
>>>>> then it doesn't matter which AJAX library we use underneath and 
>>>>> generate HTML/etc for, and we can change libraries without 
>>>>> requiring any change to the higher level artifacts, like the form 
>>>>> definitions.
>>>>> -David
>>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo, 
>>>>>> etc) in the screen widgets, we need to discuss how that support 
>>>>>> will appear in the screen widget XML files.
>>>>>>
>>>>>> I'll start things off with a suggestion I made in another thread. 
>>>>>> Everyone is welcome to join in and offer their ideas. When we 
>>>>>> reach an agreement, we can submit the results to Jira and begin 
>>>>>> building it out.
>>>>>>
>>>>>> I was thinking we could simply extend the existing widgets with 
>>>>>> additional attributes. The new attributes would pass 3rd party 
>>>>>> specific data to the rendering classes. The new attributes are 
>>>>>> ignored by rendering classes that don't need them. All rendering 
>>>>>> classes render all widgets in some form - some rendering classes 
>>>>>> might have additional bells and whistles based upon the additional 
>>>>>> attributes, while others downgrade gracefully and still provide a 
>>>>>> usable screen rendering.
>>>>>>
>>>>>>
>>>>>> So, the widget XML would look something like this:
>>>>>>
>>>>>>
>>>>>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>>>>>> ajax="some Ajax data" foo="some foo data">
>>>>>> ...
>>>>>> </container>
>>>>>>
>>>>>> The additional attributes could be applied to any screen widget 
>>>>>> element, not just the container element.
>>>>>>
>>>>>> The advantage I see to this approach is it is fully backwards 
>>>>>> compatible. We can add attributes to any screen widget element 
>>>>>> without breaking existing rendering code.
>>>>>>
>>>>>> That's it. Like I said, please add your ideas.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------
>>>>>> Looking for last minute shopping deals?  Find them fast with 
>>>>>> Yahoo! Search.
> 
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[David E Jones <jo...@hotwaxmedia.com>]

Adrian,

That sounds good to me. I'm always hesitant to say it because if the  
inherent inaccuracy of any human communication, but I think "we're on  
the same page here".

-David


On May 7, 2008, at 8:48 AM, Adrian Crum wrote:

> David,
>
> I agree that there are some cool Ajax like features that won't map  
> exactly to existing widgets. In that case we'll create a new widget  
> and try to find an HTML equivalent. So, I'm not tossing out the idea  
> of new widgets that have improved features, I'm suggesting let's  
> start with adding new features to existing widgets.
>
> I have seen the Ajax work done in the Example component.
>
> Regarding the alternate HTML rendering classes, I don't think those  
> will be needed. My thinking right now is to just evolve the existing  
> HTML rendering classes.
>
> -Adrian
>
> David E Jones wrote:
>> Adrian,
>> This sounds great for the elements that have some sort of natural  
>> JS/AJAX extension that doesn't change what the form means or offers  
>> to the user but instead just improves the user experience and/or  
>> efficiency.
>> With cases like I agree it would be great, and a REALLY cool  
>> feature, to upgrade automatically and not require form changes or  
>> anything.
>> However, there are many cases where we can't automatically add JS/ 
>> AJAX extensions, but instead they represent a possible widget that  
>> is different enough from the concept behind any of the existing  
>> form field types that it would be weird to piggy back the  
>> functionality and try to automatically shoe-horn it into the  
>> existing functionality.
>> Some of the stuff I played with recently and added, like an auto- 
>> refresh on a screen container, is not something we would want to  
>> automatically turn on. The other one I added recently, to submit a  
>> form in the background and not refresh the page, is also something  
>> that I don't think we would want to automatically turn on.
>> So, yes, I agree we should add some of the automatic extensions  
>> that we can and it would be a really cool set of new features.
>> Stepping back to the original thingy, how does using alternate  
>> HtmlFormRenderer classes help with this? Maybe you're not still  
>> considering that, but I'd say if we did default fancy things (which  
>> again, I love the idea of), we should just do those all the time  
>> unless, like you wrote, the browser identifier is clearly one that  
>> won't support it (some of that might need to be client side too  
>> though... I'm not sure about all of the nuances there).
>> -David
>> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
>>> I'm resurrecting this thread because I've spent some time looking  
>>> into the whole third party rendering library support idea and I  
>>> think I have a simple solution.
>>>
>>> I thought about David's suggestion of having new widgets that are  
>>> effects based. I don't think that will be a good strategy because  
>>> not all browsers will have javascript enabled - which would render  
>>> those widgets useless.
>>>
>>> A better approach I would like to propose is to use the Prototype  
>>> javascript library in combination with EXISTING widgets to improve  
>>> their response and functionality. The widget rendering code would  
>>> detect if the browser supports javascript, and output the correct  
>>> HTML to accommodate the browser.
>>>
>>> Instead of a "live-form" widget, the existing form widget would  
>>> detect browser support, and render an improved form if the browser  
>>> supports it. The current paginated tables would use Ajax calls to  
>>> scroll through pages instead of refreshing the whole screen.
>>>
>>> Basically, I'd like to see the cool effects and improved response  
>>> implemented without any additional work on the widget XML files.
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> I guess this is a continuation of the discussion in the thread  
>>>> "uilabels and screenlet widget", and is related somewhat to part  
>>>> of the stuff in issue OFBIZ-1648.
>>>> The general goal of the widgets is simple: no platform specific  
>>>> artifacts. Unfortunately this isn't entirely possible, which is  
>>>> why we have a very big and ugly "platform-specific" tag to  
>>>> delineate things that are not generic and provide for the  
>>>> possible of having alternative platform things specified together  
>>>> so that when rendering for a different target the appropriate  
>>>> option can be selected.
>>>> As far as that applies to this topic, I'd say the best approach  
>>>> is to never have any element or attribute called "dojo" or "ajax"  
>>>> or "rico" or anything. In the dojo attribute for the container  
>>>> elements, I'm not sure what you'd propose to put in it, ie the  
>>>> "some Dojo data", but in general I'd prefer to never have  
>>>> anything that is so dependent on a particular underlying  
>>>> technology, the widget artifacts gain efficiency by their focus  
>>>> on different effects, with the underlying software taking care of  
>>>> the "causes", or rather how the effects are brought about.
>>>> In other words while we wouldn't want elements that have anything  
>>>> to do with "dojo" or "openrico" we would want elements to  
>>>> describe the effects from those libraries we'd like to have  
>>>> available through the widget, and the most appropriate is  
>>>> probably the Form Widget with different form and field types  
>>>> (though some would certainly go elsewhere and are not form  
>>>> related).
>>>> Examples of that would be a new form type like "live-grid" or a  
>>>> new form field type like "live-combobox" (or "dynamic-combobox"  
>>>> or "server-side-combobox" or something). If we add elements like  
>>>> that then it doesn't matter which AJAX library we use underneath  
>>>> and generate HTML/etc for, and we can change libraries without  
>>>> requiring any change to the higher level artifacts, like the form  
>>>> definitions.
>>>> -David
>>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>>> In order to accommodate 3rd party rendering libraries (Ajax,  
>>>>> Dojo, etc) in the screen widgets, we need to discuss how that  
>>>>> support will appear in the screen widget XML files.
>>>>>
>>>>> I'll start things off with a suggestion I made in another  
>>>>> thread. Everyone is welcome to join in and offer their ideas.  
>>>>> When we reach an agreement, we can submit the results to Jira  
>>>>> and begin building it out.
>>>>>
>>>>> I was thinking we could simply extend the existing widgets with  
>>>>> additional attributes. The new attributes would pass 3rd party  
>>>>> specific data to the rendering classes. The new attributes are  
>>>>> ignored by rendering classes that don't need them. All rendering  
>>>>> classes render all widgets in some form - some rendering classes  
>>>>> might have additional bells and whistles based upon the  
>>>>> additional attributes, while others downgrade gracefully and  
>>>>> still provide a usable screen rendering.
>>>>>
>>>>>
>>>>> So, the widget XML would look something like this:
>>>>>
>>>>>
>>>>> <container id="some-id" style="some-style" dojo="some Dojo data"  
>>>>> ajax="some Ajax data" foo="some foo data">
>>>>> ...
>>>>> </container>
>>>>>
>>>>> The additional attributes could be applied to any screen widget  
>>>>> element, not just the container element.
>>>>>
>>>>> The advantage I see to this approach is it is fully backwards  
>>>>> compatible. We can add attributes to any screen widget element  
>>>>> without breaking existing rendering code.
>>>>>
>>>>> That's it. Like I said, please add your ideas.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------
>>>>> Looking for last minute shopping deals?  Find them fast with  
>>>>> Yahoo! Search.

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@hlmksw.com>]

David,

I agree that there are some cool Ajax like features that won't map 
exactly to existing widgets. In that case we'll create a new widget and 
try to find an HTML equivalent. So, I'm not tossing out the idea of new 
widgets that have improved features, I'm suggesting let's start with 
adding new features to existing widgets.

I have seen the Ajax work done in the Example component.

Regarding the alternate HTML rendering classes, I don't think those will 
be needed. My thinking right now is to just evolve the existing HTML 
rendering classes.

-Adrian

David E Jones wrote:
> 
> Adrian,
> 
> This sounds great for the elements that have some sort of natural 
> JS/AJAX extension that doesn't change what the form means or offers to 
> the user but instead just improves the user experience and/or efficiency.
> 
> With cases like I agree it would be great, and a REALLY cool feature, to 
> upgrade automatically and not require form changes or anything.
> 
> However, there are many cases where we can't automatically add JS/AJAX 
> extensions, but instead they represent a possible widget that is 
> different enough from the concept behind any of the existing form field 
> types that it would be weird to piggy back the functionality and try to 
> automatically shoe-horn it into the existing functionality.
> 
> Some of the stuff I played with recently and added, like an auto-refresh 
> on a screen container, is not something we would want to automatically 
> turn on. The other one I added recently, to submit a form in the 
> background and not refresh the page, is also something that I don't 
> think we would want to automatically turn on.
> 
> So, yes, I agree we should add some of the automatic extensions that we 
> can and it would be a really cool set of new features.
> 
> Stepping back to the original thingy, how does using alternate 
> HtmlFormRenderer classes help with this? Maybe you're not still 
> considering that, but I'd say if we did default fancy things (which 
> again, I love the idea of), we should just do those all the time unless, 
> like you wrote, the browser identifier is clearly one that won't support 
> it (some of that might need to be client side too though... I'm not sure 
> about all of the nuances there).
> 
> -David
> 
> 
> On May 6, 2008, at 3:42 PM, Adrian Crum wrote:
> 
>> I'm resurrecting this thread because I've spent some time looking into 
>> the whole third party rendering library support idea and I think I 
>> have a simple solution.
>>
>> I thought about David's suggestion of having new widgets that are 
>> effects based. I don't think that will be a good strategy because not 
>> all browsers will have javascript enabled - which would render those 
>> widgets useless.
>>
>> A better approach I would like to propose is to use the Prototype 
>> javascript library in combination with EXISTING widgets to improve 
>> their response and functionality. The widget rendering code would 
>> detect if the browser supports javascript, and output the correct HTML 
>> to accommodate the browser.
>>
>> Instead of a "live-form" widget, the existing form widget would detect 
>> browser support, and render an improved form if the browser supports 
>> it. The current paginated tables would use Ajax calls to scroll 
>> through pages instead of refreshing the whole screen.
>>
>> Basically, I'd like to see the cool effects and improved response 
>> implemented without any additional work on the widget XML files.
>>
>> What do you think?
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> I guess this is a continuation of the discussion in the thread 
>>> "uilabels and screenlet widget", and is related somewhat to part of 
>>> the stuff in issue OFBIZ-1648.
>>> The general goal of the widgets is simple: no platform specific 
>>> artifacts. Unfortunately this isn't entirely possible, which is why 
>>> we have a very big and ugly "platform-specific" tag to delineate 
>>> things that are not generic and provide for the possible of having 
>>> alternative platform things specified together so that when rendering 
>>> for a different target the appropriate option can be selected.
>>> As far as that applies to this topic, I'd say the best approach is to 
>>> never have any element or attribute called "dojo" or "ajax" or "rico" 
>>> or anything. In the dojo attribute for the container elements, I'm 
>>> not sure what you'd propose to put in it, ie the "some Dojo data", 
>>> but in general I'd prefer to never have anything that is so dependent 
>>> on a particular underlying technology, the widget artifacts gain 
>>> efficiency by their focus on different effects, with the underlying 
>>> software taking care of the "causes", or rather how the effects are 
>>> brought about.
>>> In other words while we wouldn't want elements that have anything to 
>>> do with "dojo" or "openrico" we would want elements to describe the 
>>> effects from those libraries we'd like to have available through the 
>>> widget, and the most appropriate is probably the Form Widget with 
>>> different form and field types (though some would certainly go 
>>> elsewhere and are not form related).
>>> Examples of that would be a new form type like "live-grid" or a new 
>>> form field type like "live-combobox" (or "dynamic-combobox" or 
>>> "server-side-combobox" or something). If we add elements like that 
>>> then it doesn't matter which AJAX library we use underneath and 
>>> generate HTML/etc for, and we can change libraries without requiring 
>>> any change to the higher level artifacts, like the form definitions.
>>> -David
>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo, 
>>>> etc) in the screen widgets, we need to discuss how that support will 
>>>> appear in the screen widget XML files.
>>>>
>>>> I'll start things off with a suggestion I made in another thread. 
>>>> Everyone is welcome to join in and offer their ideas. When we reach 
>>>> an agreement, we can submit the results to Jira and begin building 
>>>> it out.
>>>>
>>>> I was thinking we could simply extend the existing widgets with 
>>>> additional attributes. The new attributes would pass 3rd party 
>>>> specific data to the rendering classes. The new attributes are 
>>>> ignored by rendering classes that don't need them. All rendering 
>>>> classes render all widgets in some form - some rendering classes 
>>>> might have additional bells and whistles based upon the additional 
>>>> attributes, while others downgrade gracefully and still provide a 
>>>> usable screen rendering.
>>>>
>>>>
>>>> So, the widget XML would look something like this:
>>>>
>>>>
>>>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>>>> ajax="some Ajax data" foo="some foo data">
>>>> ...
>>>> </container>
>>>>
>>>> The additional attributes could be applied to any screen widget 
>>>> element, not just the container element.
>>>>
>>>> The advantage I see to this approach is it is fully backwards 
>>>> compatible. We can add attributes to any screen widget element 
>>>> without breaking existing rendering code.
>>>>
>>>> That's it. Like I said, please add your ideas.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------
>>>> Looking for last minute shopping deals?  Find them fast with Yahoo! 
>>>> Search.
> 
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[David E Jones <jo...@hotwaxmedia.com>]

Adrian,

This sounds great for the elements that have some sort of natural JS/ 
AJAX extension that doesn't change what the form means or offers to  
the user but instead just improves the user experience and/or  
efficiency.

With cases like I agree it would be great, and a REALLY cool feature,  
to upgrade automatically and not require form changes or anything.

However, there are many cases where we can't automatically add JS/AJAX  
extensions, but instead they represent a possible widget that is  
different enough from the concept behind any of the existing form  
field types that it would be weird to piggy back the functionality and  
try to automatically shoe-horn it into the existing functionality.

Some of the stuff I played with recently and added, like an auto- 
refresh on a screen container, is not something we would want to  
automatically turn on. The other one I added recently, to submit a  
form in the background and not refresh the page, is also something  
that I don't think we would want to automatically turn on.

So, yes, I agree we should add some of the automatic extensions that  
we can and it would be a really cool set of new features.

Stepping back to the original thingy, how does using alternate  
HtmlFormRenderer classes help with this? Maybe you're not still  
considering that, but I'd say if we did default fancy things (which  
again, I love the idea of), we should just do those all the time  
unless, like you wrote, the browser identifier is clearly one that  
won't support it (some of that might need to be client side too  
though... I'm not sure about all of the nuances there).

-David


On May 6, 2008, at 3:42 PM, Adrian Crum wrote:

> I'm resurrecting this thread because I've spent some time looking  
> into the whole third party rendering library support idea and I  
> think I have a simple solution.
>
> I thought about David's suggestion of having new widgets that are  
> effects based. I don't think that will be a good strategy because  
> not all browsers will have javascript enabled - which would render  
> those widgets useless.
>
> A better approach I would like to propose is to use the Prototype  
> javascript library in combination with EXISTING widgets to improve  
> their response and functionality. The widget rendering code would  
> detect if the browser supports javascript, and output the correct  
> HTML to accommodate the browser.
>
> Instead of a "live-form" widget, the existing form widget would  
> detect browser support, and render an improved form if the browser  
> supports it. The current paginated tables would use Ajax calls to  
> scroll through pages instead of refreshing the whole screen.
>
> Basically, I'd like to see the cool effects and improved response  
> implemented without any additional work on the widget XML files.
>
> What do you think?
>
> -Adrian
>
> David E Jones wrote:
>> I guess this is a continuation of the discussion in the thread  
>> "uilabels and screenlet widget", and is related somewhat to part of  
>> the stuff in issue OFBIZ-1648.
>> The general goal of the widgets is simple: no platform specific  
>> artifacts. Unfortunately this isn't entirely possible, which is why  
>> we have a very big and ugly "platform-specific" tag to delineate  
>> things that are not generic and provide for the possible of having  
>> alternative platform things specified together so that when  
>> rendering for a different target the appropriate option can be  
>> selected.
>> As far as that applies to this topic, I'd say the best approach is  
>> to never have any element or attribute called "dojo" or "ajax" or  
>> "rico" or anything. In the dojo attribute for the container  
>> elements, I'm not sure what you'd propose to put in it, ie the  
>> "some Dojo data", but in general I'd prefer to never have anything  
>> that is so dependent on a particular underlying technology, the  
>> widget artifacts gain efficiency by their focus on different  
>> effects, with the underlying software taking care of the "causes",  
>> or rather how the effects are brought about.
>> In other words while we wouldn't want elements that have anything  
>> to do with "dojo" or "openrico" we would want elements to describe  
>> the effects from those libraries we'd like to have available  
>> through the widget, and the most appropriate is probably the Form  
>> Widget with different form and field types (though some would  
>> certainly go elsewhere and are not form related).
>> Examples of that would be a new form type like "live-grid" or a new  
>> form field type like "live-combobox" (or "dynamic-combobox" or  
>> "server-side-combobox" or something). If we add elements like that  
>> then it doesn't matter which AJAX library we use underneath and  
>> generate HTML/etc for, and we can change libraries without  
>> requiring any change to the higher level artifacts, like the form  
>> definitions.
>> -David
>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo,  
>>> etc) in the screen widgets, we need to discuss how that support  
>>> will appear in the screen widget XML files.
>>>
>>> I'll start things off with a suggestion I made in another thread.  
>>> Everyone is welcome to join in and offer their ideas. When we  
>>> reach an agreement, we can submit the results to Jira and begin  
>>> building it out.
>>>
>>> I was thinking we could simply extend the existing widgets with  
>>> additional attributes. The new attributes would pass 3rd party  
>>> specific data to the rendering classes. The new attributes are  
>>> ignored by rendering classes that don't need them. All rendering  
>>> classes render all widgets in some form - some rendering classes  
>>> might have additional bells and whistles based upon the additional  
>>> attributes, while others downgrade gracefully and still provide a  
>>> usable screen rendering.
>>>
>>>
>>> So, the widget XML would look something like this:
>>>
>>>
>>> <container id="some-id" style="some-style" dojo="some Dojo data"  
>>> ajax="some Ajax data" foo="some foo data">
>>> ...
>>> </container>
>>>
>>> The additional attributes could be applied to any screen widget  
>>> element, not just the container element.
>>>
>>> The advantage I see to this approach is it is fully backwards  
>>> compatible. We can add attributes to any screen widget element  
>>> without breaking existing rendering code.
>>>
>>> That's it. Like I said, please add your ideas.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------
>>> Looking for last minute shopping deals?  Find them fast with  
>>> Yahoo! Search.

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@hlmksw.com>]

I believe the approach has been to use javascript to add convenience, 
but the UI will still work without it. The Find Party screen is an example.

-Adrian

Al Byers wrote:
> I am not sure. It seems like there are many cases where it is possible to
> require that javascript be turned on and those would be worth developing
> for.
> 
> -Al
> 
> On Tue, May 6, 2008 at 3:42 PM, Adrian Crum <ad...@hlmksw.com> wrote:
> 
>> I'm resurrecting this thread because I've spent some time looking into the
>> whole third party rendering library support idea and I think I have a simple
>> solution.
>>
>> I thought about David's suggestion of having new widgets that are effects
>> based. I don't think that will be a good strategy because not all browsers
>> will have javascript enabled - which would render those widgets useless.
>>
>> A better approach I would like to propose is to use the Prototype
>> javascript library in combination with EXISTING widgets to improve their
>> response and functionality. The widget rendering code would detect if the
>> browser supports javascript, and output the correct HTML to accommodate the
>> browser.
>>
>> Instead of a "live-form" widget, the existing form widget would detect
>> browser support, and render an improved form if the browser supports it. The
>> current paginated tables would use Ajax calls to scroll through pages
>> instead of refreshing the whole screen.
>>
>> Basically, I'd like to see the cool effects and improved response
>> implemented without any additional work on the widget XML files.
>>
>> What do you think?
>>
>> -Adrian
>>
>>
>> David E Jones wrote:
>>
>>> I guess this is a continuation of the discussion in the thread "uilabels
>>> and screenlet widget", and is related somewhat to part of the stuff in issue
>>> OFBIZ-1648.
>>>
>>> The general goal of the widgets is simple: no platform specific
>>> artifacts. Unfortunately this isn't entirely possible, which is why we have
>>> a very big and ugly "platform-specific" tag to delineate things that are not
>>> generic and provide for the possible of having alternative platform things
>>> specified together so that when rendering for a different target the
>>> appropriate option can be selected.
>>>
>>> As far as that applies to this topic, I'd say the best approach is to
>>> never have any element or attribute called "dojo" or "ajax" or "rico" or
>>> anything. In the dojo attribute for the container elements, I'm not sure
>>> what you'd propose to put in it, ie the "some Dojo data", but in general I'd
>>> prefer to never have anything that is so dependent on a particular
>>> underlying technology, the widget artifacts gain efficiency by their focus
>>> on different effects, with the underlying software taking care of the
>>> "causes", or rather how the effects are brought about.
>>>
>>> In other words while we wouldn't want elements that have anything to do
>>> with "dojo" or "openrico" we would want elements to describe the effects
>>> from those libraries we'd like to have available through the widget, and the
>>> most appropriate is probably the Form Widget with different form and field
>>> types (though some would certainly go elsewhere and are not form related).
>>>
>>> Examples of that would be a new form type like "live-grid" or a new form
>>> field type like "live-combobox" (or "dynamic-combobox" or
>>> "server-side-combobox" or something). If we add elements like that then it
>>> doesn't matter which AJAX library we use underneath and generate HTML/etc
>>> for, and we can change libraries without requiring any change to the higher
>>> level artifacts, like the form definitions.
>>>
>>> -David
>>>
>>>
>>> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>>>
>>>  In order to accommodate 3rd party rendering libraries (Ajax, Dojo, etc)
>>>> in the screen widgets, we need to discuss how that support will appear in
>>>> the screen widget XML files.
>>>>
>>>> I'll start things off with a suggestion I made in another thread.
>>>> Everyone is welcome to join in and offer their ideas. When we reach an
>>>> agreement, we can submit the results to Jira and begin building it out.
>>>>
>>>> I was thinking we could simply extend the existing widgets with
>>>> additional attributes. The new attributes would pass 3rd party specific data
>>>> to the rendering classes. The new attributes are ignored by rendering
>>>> classes that don't need them. All rendering classes render all widgets in
>>>> some form - some rendering classes might have additional bells and whistles
>>>> based upon the additional attributes, while others downgrade gracefully and
>>>> still provide a usable screen rendering.
>>>>
>>>>
>>>> So, the widget XML would look something like this:
>>>>
>>>>
>>>> <container id="some-id" style="some-style" dojo="some Dojo data"
>>>> ajax="some Ajax data" foo="some foo data">
>>>>  ...
>>>> </container>
>>>>
>>>> The additional attributes could be applied to any screen widget
>>>> element, not just the container element.
>>>>
>>>> The advantage I see to this approach is it is fully backwards
>>>> compatible. We can add attributes to any screen widget element without
>>>> breaking existing rendering code.
>>>>
>>>> That's it. Like I said, please add your ideas.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------
>>>> Looking for last minute shopping deals?  Find them fast with Yahoo!
>>>> Search.
>>>>
>>>
>>>
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Al Byers <by...@automationgroups.com>]

I am not sure. It seems like there are many cases where it is possible to
require that javascript be turned on and those would be worth developing
for.

-Al

On Tue, May 6, 2008 at 3:42 PM, Adrian Crum <ad...@hlmksw.com> wrote:

> I'm resurrecting this thread because I've spent some time looking into the
> whole third party rendering library support idea and I think I have a simple
> solution.
>
> I thought about David's suggestion of having new widgets that are effects
> based. I don't think that will be a good strategy because not all browsers
> will have javascript enabled - which would render those widgets useless.
>
> A better approach I would like to propose is to use the Prototype
> javascript library in combination with EXISTING widgets to improve their
> response and functionality. The widget rendering code would detect if the
> browser supports javascript, and output the correct HTML to accommodate the
> browser.
>
> Instead of a "live-form" widget, the existing form widget would detect
> browser support, and render an improved form if the browser supports it. The
> current paginated tables would use Ajax calls to scroll through pages
> instead of refreshing the whole screen.
>
> Basically, I'd like to see the cool effects and improved response
> implemented without any additional work on the widget XML files.
>
> What do you think?
>
> -Adrian
>
>
> David E Jones wrote:
>
> >
> > I guess this is a continuation of the discussion in the thread "uilabels
> > and screenlet widget", and is related somewhat to part of the stuff in issue
> > OFBIZ-1648.
> >
> > The general goal of the widgets is simple: no platform specific
> > artifacts. Unfortunately this isn't entirely possible, which is why we have
> > a very big and ugly "platform-specific" tag to delineate things that are not
> > generic and provide for the possible of having alternative platform things
> > specified together so that when rendering for a different target the
> > appropriate option can be selected.
> >
> > As far as that applies to this topic, I'd say the best approach is to
> > never have any element or attribute called "dojo" or "ajax" or "rico" or
> > anything. In the dojo attribute for the container elements, I'm not sure
> > what you'd propose to put in it, ie the "some Dojo data", but in general I'd
> > prefer to never have anything that is so dependent on a particular
> > underlying technology, the widget artifacts gain efficiency by their focus
> > on different effects, with the underlying software taking care of the
> > "causes", or rather how the effects are brought about.
> >
> > In other words while we wouldn't want elements that have anything to do
> > with "dojo" or "openrico" we would want elements to describe the effects
> > from those libraries we'd like to have available through the widget, and the
> > most appropriate is probably the Form Widget with different form and field
> > types (though some would certainly go elsewhere and are not form related).
> >
> > Examples of that would be a new form type like "live-grid" or a new form
> > field type like "live-combobox" (or "dynamic-combobox" or
> > "server-side-combobox" or something). If we add elements like that then it
> > doesn't matter which AJAX library we use underneath and generate HTML/etc
> > for, and we can change libraries without requiring any change to the higher
> > level artifacts, like the form definitions.
> >
> > -David
> >
> >
> > On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
> >
> >  In order to accommodate 3rd party rendering libraries (Ajax, Dojo, etc)
> > > in the screen widgets, we need to discuss how that support will appear in
> > > the screen widget XML files.
> > >
> > > I'll start things off with a suggestion I made in another thread.
> > > Everyone is welcome to join in and offer their ideas. When we reach an
> > > agreement, we can submit the results to Jira and begin building it out.
> > >
> > > I was thinking we could simply extend the existing widgets with
> > > additional attributes. The new attributes would pass 3rd party specific data
> > > to the rendering classes. The new attributes are ignored by rendering
> > > classes that don't need them. All rendering classes render all widgets in
> > > some form - some rendering classes might have additional bells and whistles
> > > based upon the additional attributes, while others downgrade gracefully and
> > > still provide a usable screen rendering.
> > >
> > >
> > > So, the widget XML would look something like this:
> > >
> > >
> > > <container id="some-id" style="some-style" dojo="some Dojo data"
> > > ajax="some Ajax data" foo="some foo data">
> > >  ...
> > > </container>
> > >
> > > The additional attributes could be applied to any screen widget
> > > element, not just the container element.
> > >
> > > The advantage I see to this approach is it is fully backwards
> > > compatible. We can add attributes to any screen widget element without
> > > breaking existing rendering code.
> > >
> > > That's it. Like I said, please add your ideas.
> > >
> > > -Adrian
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------
> > > Looking for last minute shopping deals?  Find them fast with Yahoo!
> > > Search.
> > >
> >
> >
> >

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@hlmksw.com>]

I'm resurrecting this thread because I've spent some time looking into 
the whole third party rendering library support idea and I think I have 
a simple solution.

I thought about David's suggestion of having new widgets that are 
effects based. I don't think that will be a good strategy because not 
all browsers will have javascript enabled - which would render those 
widgets useless.

A better approach I would like to propose is to use the Prototype 
javascript library in combination with EXISTING widgets to improve their 
response and functionality. The widget rendering code would detect if 
the browser supports javascript, and output the correct HTML to 
accommodate the browser.

Instead of a "live-form" widget, the existing form widget would detect 
browser support, and render an improved form if the browser supports it. 
The current paginated tables would use Ajax calls to scroll through 
pages instead of refreshing the whole screen.

Basically, I'd like to see the cool effects and improved response 
implemented without any additional work on the widget XML files.

What do you think?

-Adrian

David E Jones wrote:
> 
> I guess this is a continuation of the discussion in the thread "uilabels 
> and screenlet widget", and is related somewhat to part of the stuff in 
> issue OFBIZ-1648.
> 
> The general goal of the widgets is simple: no platform specific 
> artifacts. Unfortunately this isn't entirely possible, which is why we 
> have a very big and ugly "platform-specific" tag to delineate things 
> that are not generic and provide for the possible of having alternative 
> platform things specified together so that when rendering for a 
> different target the appropriate option can be selected.
> 
> As far as that applies to this topic, I'd say the best approach is to 
> never have any element or attribute called "dojo" or "ajax" or "rico" or 
> anything. In the dojo attribute for the container elements, I'm not sure 
> what you'd propose to put in it, ie the "some Dojo data", but in general 
> I'd prefer to never have anything that is so dependent on a particular 
> underlying technology, the widget artifacts gain efficiency by their 
> focus on different effects, with the underlying software taking care of 
> the "causes", or rather how the effects are brought about.
> 
> In other words while we wouldn't want elements that have anything to do 
> with "dojo" or "openrico" we would want elements to describe the effects 
> from those libraries we'd like to have available through the widget, and 
> the most appropriate is probably the Form Widget with different form and 
> field types (though some would certainly go elsewhere and are not form 
> related).
> 
> Examples of that would be a new form type like "live-grid" or a new form 
> field type like "live-combobox" (or "dynamic-combobox" or 
> "server-side-combobox" or something). If we add elements like that then 
> it doesn't matter which AJAX library we use underneath and generate 
> HTML/etc for, and we can change libraries without requiring any change 
> to the higher level artifacts, like the form definitions.
> 
> -David
> 
> 
> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
> 
>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo, 
>> etc) in the screen widgets, we need to discuss how that support will 
>> appear in the screen widget XML files.
>>
>> I'll start things off with a suggestion I made in another thread. 
>> Everyone is welcome to join in and offer their ideas. When we reach an 
>> agreement, we can submit the results to Jira and begin building it out.
>>
>> I was thinking we could simply extend the existing widgets with 
>> additional attributes. The new attributes would pass 3rd party 
>> specific data to the rendering classes. The new attributes are ignored 
>> by rendering classes that don't need them. All rendering classes 
>> render all widgets in some form - some rendering classes might have 
>> additional bells and whistles based upon the additional attributes, 
>> while others downgrade gracefully and still provide a usable screen 
>> rendering.
>>
>>
>> So, the widget XML would look something like this:
>>
>>
>> <container id="some-id" style="some-style" dojo="some Dojo data" 
>> ajax="some Ajax data" foo="some foo data">
>>  ...
>> </container>
>>
>> The additional attributes could be applied to any screen widget 
>> element, not just the container element.
>>
>> The advantage I see to this approach is it is fully backwards 
>> compatible. We can add attributes to any screen widget element without 
>> breaking existing rendering code.
>>
>> That's it. Like I said, please add your ideas.
>>
>> -Adrian
>>
>>
>>
>>
>>
>>
>> ---------------------------------
>> Looking for last minute shopping deals?  Find them fast with Yahoo! 
>> Search.
> 
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[David E Jones <jo...@hotwaxmedia.com>]

On Feb 16, 2008, at 8:46 PM, David E Jones wrote:

>
> I guess this is a continuation of the discussion in the thread  
> "uilabels and screenlet widget", and is related somewhat to part of  
> the stuff in issue OFBIZ-1648.

Whoops, I just noticed I was looking at the wrong thread name when I  
typed the above, it is actually "Need help from a Java guru" and not  
"uilabels and screenlet widget", though that appears to be somewhat  
related too.

-David



> The general goal of the widgets is simple: no platform specific  
> artifacts. Unfortunately this isn't entirely possible, which is why  
> we have a very big and ugly "platform-specific" tag to delineate  
> things that are not generic and provide for the possible of having  
> alternative platform things specified together so that when  
> rendering for a different target the appropriate option can be  
> selected.
>
> As far as that applies to this topic, I'd say the best approach is  
> to never have any element or attribute called "dojo" or "ajax" or  
> "rico" or anything. In the dojo attribute for the container  
> elements, I'm not sure what you'd propose to put in it, ie the "some  
> Dojo data", but in general I'd prefer to never have anything that is  
> so dependent on a particular underlying technology, the widget  
> artifacts gain efficiency by their focus on different effects, with  
> the underlying software taking care of the "causes", or rather how  
> the effects are brought about.
>
> In other words while we wouldn't want elements that have anything to  
> do with "dojo" or "openrico" we would want elements to describe the  
> effects from those libraries we'd like to have available through the  
> widget, and the most appropriate is probably the Form Widget with  
> different form and field types (though some would certainly go  
> elsewhere and are not form related).
>
> Examples of that would be a new form type like "live-grid" or a new  
> form field type like "live-combobox" (or "dynamic-combobox" or  
> "server-side-combobox" or something). If we add elements like that  
> then it doesn't matter which AJAX library we use underneath and  
> generate HTML/etc for, and we can change libraries without requiring  
> any change to the higher level artifacts, like the form definitions.
>
> -David
>
>
> On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:
>
>> In order to accommodate 3rd party rendering libraries (Ajax, Dojo,  
>> etc) in the screen widgets, we need to discuss how that support  
>> will appear in the screen widget XML files.
>>
>> I'll start things off with a suggestion I made in another thread.  
>> Everyone is welcome to join in and offer their ideas. When we reach  
>> an agreement, we can submit the results to Jira and begin building  
>> it out.
>>
>> I was thinking we could simply extend the existing widgets with  
>> additional attributes. The new attributes would pass 3rd party  
>> specific data to the rendering classes. The new attributes are  
>> ignored by rendering classes that don't need them. All rendering  
>> classes render all widgets in some form - some rendering classes  
>> might have additional bells and whistles based upon the additional  
>> attributes, while others downgrade gracefully and still provide a  
>> usable screen rendering.
>>
>>
>> So, the widget XML would look something like this:
>>
>>
>> <container id="some-id" style="some-style" dojo="some Dojo data"  
>> ajax="some Ajax data" foo="some foo data">
>> ...
>> </container>
>>
>> The additional attributes could be applied to any screen widget  
>> element, not just the container element.
>>
>> The advantage I see to this approach is it is fully backwards  
>> compatible. We can add attributes to any screen widget element  
>> without breaking existing rendering code.
>>
>> That's it. Like I said, please add your ideas.
>>
>> -Adrian
>>
>>
>>
>>
>>
>>
>> ---------------------------------
>> Looking for last minute shopping deals?  Find them fast with Yahoo!  
>> Search.
>

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Jacques Le Roux <ja...@les7arts.com>]

Hi Al,

Jacopo has suggested to have a look at XAP (incubator). I just subscribed to their MLs and asked for i18n support. It might turn 
interesting to get involved in this project... http://incubator.apache.org/xap/index.html

Jacques

From: "Al Byers" <by...@automationgroups.com>
>I have been working with Dojo for the past six months and am ready to try a
> set of rendering classes. I am interested in all the widget types - forms,
> comboboxes and menus. I am especially interested in the tree and grid
> objects. With client-side functionality there will be new problems to solve
> - like making sure that a minimum set of javascript base files get sent to
> the client.
>
> Dojo interacts with the server through a DataStore object and there will be
> some good opportunities to add generic functionality there. One of the main
> client-side-centric issues is that of "on-demand" data delivery. You can't
> always load all the data for a tree up front - for example. The Dojo Grid
> widget is very powerful and could use some tools to make it simpler to use.
>
> When I get something basic working, I will add an
> org.ofbiz.widget.dojodirectory, unless it would be better do a
> specialized app first or
> something.
>
> -Al
> 

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Al Byers <by...@automationgroups.com>]

I have been working with Dojo for the past six months and am ready to try a
set of rendering classes. I am interested in all the widget types - forms,
comboboxes and menus. I am especially interested in the tree and grid
objects. With client-side functionality there will be new problems to solve
- like making sure that a minimum set of javascript base files get sent to
the client.

Dojo interacts with the server through a DataStore object and there will be
some good opportunities to add generic functionality there. One of the main
client-side-centric issues is that of "on-demand" data delivery. You can't
always load all the data for a tree up front - for example. The Dojo Grid
widget is very powerful and could use some tools to make it simpler to use.

When I get something basic working, I will add an
org.ofbiz.widget.dojodirectory, unless it would be better do a
specialized app first or
something.

-Al

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Tim Ruppert <ti...@hotwaxmedia.com>]

+1

On Feb 17, 2008, at 10:45 AM, Adrian Crum wrote:

> David E Jones <jo...@hotwaxmedia.com> wrote: In other words while  
> we wouldn't want elements that have anything to
> do with "dojo" or "openrico" we would want elements to describe the
> effects from those libraries we'd like to have available through the
> widget, and the most appropriate is probably the Form Widget with
> different form and field types (though some would certainly go
> elsewhere and are not form related).
>
> Examples of that would be a new form type like "live-grid" or a new
> form field type like "live-combobox" (or "dynamic-combobox" or  
> "server-
> side-combobox" or something). If we add elements like that then it
> doesn't matter which AJAX library we use underneath and generate HTML/
> etc for, and we can change libraries without requiring any change to
> the higher level artifacts, like the form definitions.
> Those are great suggestions. I like that approach.
>
> -Adrian
>
>
>
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo!  
> Search.

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[Adrian Crum <ad...@yahoo.com>]

David E Jones <jo...@hotwaxmedia.com> wrote: In other words while we wouldn't want elements that have anything to  
do with "dojo" or "openrico" we would want elements to describe the  
effects from those libraries we'd like to have available through the  
widget, and the most appropriate is probably the Form Widget with  
different form and field types (though some would certainly go  
elsewhere and are not form related).

Examples of that would be a new form type like "live-grid" or a new  
form field type like "live-combobox" (or "dynamic-combobox" or "server- 
side-combobox" or something). If we add elements like that then it  
doesn't matter which AJAX library we use underneath and generate HTML/ 
etc for, and we can change libraries without requiring any change to  
the higher level artifacts, like the form definitions.
Those are great suggestions. I like that approach.

-Adrian


       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries

[David E Jones <jo...@hotwaxmedia.com>]

I guess this is a continuation of the discussion in the thread  
"uilabels and screenlet widget", and is related somewhat to part of  
the stuff in issue OFBIZ-1648.

The general goal of the widgets is simple: no platform specific  
artifacts. Unfortunately this isn't entirely possible, which is why we  
have a very big and ugly "platform-specific" tag to delineate things  
that are not generic and provide for the possible of having  
alternative platform things specified together so that when rendering  
for a different target the appropriate option can be selected.

As far as that applies to this topic, I'd say the best approach is to  
never have any element or attribute called "dojo" or "ajax" or "rico"  
or anything. In the dojo attribute for the container elements, I'm not  
sure what you'd propose to put in it, ie the "some Dojo data", but in  
general I'd prefer to never have anything that is so dependent on a  
particular underlying technology, the widget artifacts gain efficiency  
by their focus on different effects, with the underlying software  
taking care of the "causes", or rather how the effects are brought  
about.

In other words while we wouldn't want elements that have anything to  
do with "dojo" or "openrico" we would want elements to describe the  
effects from those libraries we'd like to have available through the  
widget, and the most appropriate is probably the Form Widget with  
different form and field types (though some would certainly go  
elsewhere and are not form related).

Examples of that would be a new form type like "live-grid" or a new  
form field type like "live-combobox" (or "dynamic-combobox" or "server- 
side-combobox" or something). If we add elements like that then it  
doesn't matter which AJAX library we use underneath and generate HTML/ 
etc for, and we can change libraries without requiring any change to  
the higher level artifacts, like the form definitions.

-David


On Feb 16, 2008, at 1:34 PM, Adrian Crum wrote:

> In order to accommodate 3rd party rendering libraries (Ajax, Dojo,  
> etc) in the screen widgets, we need to discuss how that support will  
> appear in the screen widget XML files.
>
> I'll start things off with a suggestion I made in another thread.  
> Everyone is welcome to join in and offer their ideas. When we reach  
> an agreement, we can submit the results to Jira and begin building  
> it out.
>
> I was thinking we could simply extend the existing widgets with  
> additional attributes. The new attributes would pass 3rd party  
> specific data to the rendering classes. The new attributes are  
> ignored by rendering classes that don't need them. All rendering  
> classes render all widgets in some form - some rendering classes  
> might have additional bells and whistles based upon the additional  
> attributes, while others downgrade gracefully and still provide a  
> usable screen rendering.
>
>
> So, the widget XML would look something like this:
>
>
> <container id="some-id" style="some-style" dojo="some Dojo data"  
> ajax="some Ajax data" foo="some foo data">
>  ...
> </container>
>
> The additional attributes could be applied to any screen widget  
> element, not just the container element.
>
> The advantage I see to this approach is it is fully backwards  
> compatible. We can add attributes to any screen widget element  
> without breaking existing rendering code.
>
> That's it. Like I said, please add your ideas.
>
> -Adrian
>
>
>
>
>
>
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo!  
> Search.