My personal feeling is we need to rethink our tags and how we implement
them. To be clear, I think this is now a post 2.0.x discussion,
probably 2.1 or 3.0.
Let's start with our goals for tags:
1. Make it easy to create complex components
2. Tie the value stack values into the tag attributes
3. Allow multiple renderings of content based on a "theme" attribute
4. Allow the rendering of a tag to be easily customized
I like these goals and think we should strive to meet them. Our current
system meets these goals by:
1. Providing JSP, Velocity, and Freemarker wrappers around internal
"components"
2. Uses OGNL to evaluate parameters against the value stack
3. Theme system uses theme value to determine which Freemarker template
to use to render content
4. Freemarker templates can be copied into
WEB-INF/classes/template/THEME/COMPONENT.ftl to be overridden
Unfortunately, our current system also has these disadvantages:
1. Difficult to create your own themeable tag
2. No theme inheritance
3. Not easy to mix and match theme engines (have simple theme tags
implemented in Java, another theme use Freemarker, then have the
Freemarker theme able to leverage/extend simple tags)
I'm still thinking how we can address these issues in the long term,
however, I guess to answer your original question, I think our "ajax"
theme will continue to be tied to Dojo, however, I'd be open to new tags
that used other frameworks. I certainly don't think the "theme"
capability would be appropriate to solve the multiple ajax framework
problem, however, it is good at customizing the look and feel of a tag,
which is what we will continue to encourage.
Don
Musachy Barroso wrote:
Are we going to support(like we do with Dojo) more than one ajax
framework, or we are just trying to make it easier for others to
plugin their themes?
musachy
Don Brown wrote:
Honestly, I don't think it is the best approach to use themes to
solve the multiple Ajax toolkit problem. The theory behind themes is
to separate the functional component from its rendering. For
example, a text tag would need to take the maxlength parameter, no
matter how it is rendered.
The problem with pushing multiple ajax toolkits, each with their own
theme, under existing components is that the capabilities of the Ajax
toolkit differ wildly, therefore it isn't possible to create the
clean function/rendering separation. For example, the calendar tag
WW had takes a very different parameter set than the Dojo calendar
tag. Therefore, to fully take advantage of the Dojo and WW calendar
themes, we'd have to ensure that the component parameters were a
union of the two components. Unfortunately, this just creates
confusing because depending on your theme, half the parameters won't
do anything. This leaky abstraction is ugly and confusing. The
alternative is to only include parameters that both implementations
can support, which isn't ideal either.
Therefore, in cases where the rendering would require different
parameters, like in the case of different Ajax toolkits, I think it
is best to create a new tag. Unfortunately, it is currently
difficult to add your own components/tags, and really, the whole tag
theme concept needs an overhaul, IMO.
Don
Musachy Barroso wrote:
Hi Rene
Given all the buzz about ajax, people will want to play with the
"Firts-class Ajax support" when struts is released, I was thinking
that if the configuration was difficult it would be a problem for
people new to struts, or struts 1 users, but if it is that
easy...them moving it out of core would probably be a good idea.
musachy
Rene Gielen wrote:
Hi Musachy,
Musachy Barroso schrieb:
How easy would it be to setup an application to use this separate
theme?
Usually not more than one line of code in your application
configuration :)
The main goal of WW2/S2 tag design was to keep every tag
functional, not depending on it's implementation, therefore being
able to express your functional requirements in an abstract way.
The real challenge to integrate a new AJAX framework and such is to
deliver a good interface between the that framework and the said
abstraction layer, making the user's choice (and effort) as easy as
stated in the first sentence...
Regards,
Rene
musachy
Frank W. Zammetti wrote:
I for one tend to agree... anything included in the core product
inherently makes people think that's what they should be using,
the way
things should be done... for all Dojo's good points, there's
hundreds of
other options out there, people should understand they have a
choice. This isn't just a Dojo thing, I'd say the same thing if
it was Prototype,
APT, DWR, etc.
That being said, I do very much believe the various themes should
be kept
close to the core, i.e., some sort of endorsed add-ons or
something of
that nature, right there on the download page next to S2 itself... I
definitely do think it should be as easy as possible for someone
to drop
in a scriptaculous theme, or an AjaxTags theme, or whatever else,
and get
to work very quickly.
Validation is a tough question because ideally you'd want to be
able to
flip a switch and use AJAX to do validations if you want to, but
then you
right away have to ask what library do you use? Maybe that's a
place to
just write some simple Javascript and not use a library at all,
much like
valdator emits its own JS (debatable).
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
