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 <[EMAIL PROTECTED]> 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.
