ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject Re: Discussion: Screen Widget XML format to support 3rd party rendering libraries
Date Thu, 01 Jan 2009 16:31:40 GMT
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


From: "guo weizhan" <guo.weizhan@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 <adrianc@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
> 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
> 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
> 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,
> 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
> 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
> 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
> 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
> Search.

View raw message