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.