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.
