But is not XAP another kind of beast ? Maybe with the same CSS drawbacks though, I had only a cursory review (to be sure it was easy
to localise). Sorry no time neither, still continuing to work on french labels in my free time, tedious...
Jacques
From: "Adrian Crum" <[EMAIL PROTECTED]>
Jacopo,
Thank you for the reminder. After spending some time looking at various tool kits, I came to the conclusion that they are overkill
for what we need. But that's just my opinion.
The tool kits typically have their own CSS styles and they have their own way of doing things that don't mesh well with OFBiz. I'm
thinking we can accomplish a lot of UI wizardry on our own with just a little javascript and maybe some new CSS styles.
I'm working on some POC code right now that I hope will demonstrate how - by integrating Prototype into the screen widgets - it
will be trivial to have an improved UI.
-Adrian
Jacopo Cappellato wrote:
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.
