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. > > > > > > > > >
