I'm wondering if we shouldn't go in new direction to improve the
tags.... Looking at the freemarker templates, the ratio of Freemarker
code to HTML is probably 1.5, which leads me to wonder why we are using
a template language at all.
Here is a design for tag libs that I've been mulling around. By
default, generate most, if not all, simple tags in Java, using an
interceptor or handler-based system for building on or customizing the
tags. This approach combines the Stripes TagInterceptor-style of
allowing the user to modify the tag output with the flexibility of an
event-based pipeline. It would be faster because all but the more
HTML-rich tags would be generated in pure Java, bringing speed, tool
support, and no new syntax or EL to learn.
For example, we would define a TagHandler, loosely based off SAX's
ContentHandler:
public interface TagHandler {
startElement(String name, Attributes a);
endElement(String name);
characters(String text);
renderBody();
}
A simple text field tag would look like:
public class TextFieldTag {
public TextFieldTag(TagHandler next) {
this.next = next;
}
public void render(Map parameters) {
Attributes a = new Attributes();
a.copy(a, parameters, "name", "value", "onchange"...);
a.add("type", "text");
next.startElement("input", a);
next.endElement();
}
}
For the "simple" theme, the TagHandler passed to the TextFieldTag would
simply render the events to HTML, but for the "xhtml" theme, a new
TagHandler would be inserted before the rendering one that decorates the
simple tag with other HTML elements.
The advantages of this approach are:
1. Speed - The simple, code-rich templates are created in Java
2. Ability to completely modify a tag's output.
3. Extensibility without copy/paste
Points 2 and 3 are what make this approach interesting. Currently, you
can include another Freemarker template, but you can't modify its output
in any way. Therefore, if you wanted to add an attribute to the text
field tag, you'd have to completely replace it. This technique allows a
handler to add/remove/modify attributes of elements and text. It also
could easily support writing tags in Velocity or Freemarker when the tag
ratio of code to HTML goes low by running the template language output
through a simple sax filter that converts to TagHandler events.
Anyways, there are a lot of details still to be thought through, but I
thought it was worth getting it out there, even in a raw form, to get
some feedback.
Don
Patrick Lightbody wrote:
THANK YOU DON.
You said it much better than I did.
Honestly, guys, the reaction here is a little... odd. I wanted to engage the
dialog of how we might address known issues. Unless you've used the Struts 2
tags, it probably is hard to provide any real constructive feedback on this
particular subject. Don outlines the problems very nicely.
Ted's suggestion of building our own template language is definitely something
I've also thought about. I've always said the ideal template language that we
could use for our UI tags would be:
- JSP-like
- No scripplet support
- Fast
- Very lightweight (not giving the feeling we're requiring or endorsing one
language over another)
JXP could be a possible solution. So could building one in house. Or, perhaps,
we could fork JXP for our needs and do both. The point is there is a real issue
here, as Don outlined, as we should discuss ways to approach the problem.
I personally think that JXP is a very good start, so I'd prefer to look at that
before building our own. It may have issues (character encoding support), but a
lack of activity or developer support is not a concern for me. Solving our
known problems is my only concern - we can work out the technical, license, and
community issues later.
Now, to address Don's comments directly:
Problem #1 (performance) isn't a huge issue for me - I figure we can solve
that. Problems #2 and #3 are my main issue, which is why my criteria points to
a JSP-like syntax since most applications use JSP.
Let's pose a hypothetical: What if we could work with the JXP guys (or guy, as
the case may be - who cares) to:
- Ensure that it was fast
- Have it emulate JSP 2.0 syntax
- Address any other technical issues (ie: charsets)
I think at that point JXP might really be something we'd want to consider. The
alternative is building our own from scratch or possibly by forking something
like FreeMarker. Anyone know how difficult that would be?
Patrick
I think perhaps we are getting too deep into the
"solution" when we
don't understand or agree upon the problem. The
purpose of the Struts
tags is to provide a shortcut to create simple and
complex output. The
tags are usable in Velocity, Freemarker, and JSP. It
does this by
delegating to an independent component object model
that defines the
component as a Java object and uses Freemarker to do
the actual rendering.
Therefore, the advantages of the current system are:
1. Same tags in Velocity, Freemarker, and JSP
2. Easy to customize a tag's output by overriding its
Freemarker template
However, I do believe there are disadvantages:
1. Performance overhead of the Freemarker template
engine, as opposed
o pure Java rendering used by toolkits like the
default JSF JSP tags
2. Yet another template engine and expression
language to learn if you
se JSP or Velocity
3. Little to no tool support for Freemarker
Furthermore, if you look at our templates, most of
them have little HTML
output themselves, making them harder to read as they
have more
Freemarker syntax than HTML. Template engines
generally do better when
the markup greatly outweighs the template syntax.
The above disadvantages are big enough to me that I'm
interested in
finding an alternative to Freemarker. I want
something fast, intuitive,
and requires little to no extra learning on the part
of the developer.
Freemarker seems like a great template language for
general purpose web
pages, but for our tags, I'd like to find something
lighterweight.
I don't have a solution myself, but as we discuss
possible solutions,
and I'm very happy we have an active discussion
going, please keep in
mind the problems we are trying to solve.
Don
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=46468&messageID=94463#94463
---------------------------------------------------------------------
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]
