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.
