This is a good followup to what Craig is saying. I accidentally sent
it to Joe
instead of this list - hopefully got it right this time :)
It's not a JS API, but WW does have something similar in the theme's for the
tags.
At the moment we have a dojo theme, but Ranier was going to introduce a
prototype/scripactulous theme. Some on the users list didn't like to
introduce
dojo into pages that only needed a date picker/WYSIWYG editor - and hence the
current implementation (I did add a dojo implementation, but at the current
version of dojo this is a little flaky).
We had a discussion a few months back, and agreed on certain standard
components
that each theme should implement. What we need to be carefull of, is ensuring
that each theme implementation covers this same functionality. One case of
this is that the prototype currently does not offer events similar to
dojo - so
it would need to be clearly documentated that you cannot easy move
between these
themes.
Quoting Craig McClanahan <[EMAIL PROTECTED]>:
On 3/27/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
On Mon, March 27, 2006 9:22 am, Joe Germuska said:
> I wonder if there's a way to generalize an "API" out of these so that
> we are less bound to an implementation. Certainly, a date picker or
> rich text field which ultimately just ends up setting a value of a
> single form field should be not too hard to generalize, although I
> haven't looked at all the models for integrating JS widgets into a
> page neatly. I guess there are also issues of triggering the
> widgets, etc.
Generalize an API out of GUI widgets?
Where's Craig with the JSF plug when you need him?!? :-) LOL
Ask and ye shall receive :-) [1]
Seriously, wrapping DOJO widgets (using whatever technology you like on the
server side) is a heck of a lot more fun than writing all that javascript
yourself, as long as the underlying widget does what you need. I'm
currently playing with a JSF component wrapper for DOJO's rich text editing
capability. Took about an hour to do the wrapping -- the only issues I've
got relate to the widget implementation itself (doesn't support scrollbars,
and problems hooking in to the Save and Cancel events where I want to).
I've also seen people try to generalize *all* DOJO widgets with a single JSP
tag API. This is a lot more practical in JSP 2.0, where you can declare a
tag that takes arbitrary parameters. But I worry about usability issues of
a single tag like this, because you effectively have a "mode" of operation
for every widget (which would each only recognize only a subset of the
overall set of attributes). We have small examples of this sort of thing
all over the Struts tag library ... just for an example, try to explain to a
newbie what combination of attributes to use on an <html:frame> tag[2] when
you want to pass parameters in.
Wrapping is good, but I've come to believe in "one tag (or equivalent for
your favorite technology) per use case" is better than "one size fits all".
Frank
Craig
[1]
http://blogs.sun.com/roller/page/edwingo?entry=component_authoring_for_creator
[2] http://struts.apache.org/struts-taglib/tlddoc/html/frame.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
