Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mfncooper@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=JOjGeELgA5QqU5EL7H9GXhUL7paNXwTS333uZqz9f9uiKN+P3mUBvMFkpFwBa9oT3ipOXHYJ96Ql/QDhtFh4ArdsIQk3zo5E1ue2RC+sfwzrrEaXQjK2V+9QHEgw97L+idCvrEmw5uaxvY5FeSJXtEY3VROhuHtdDdS960obz6Y=
Message-ID: <16d6c6200610181844s774a0a86l91de302be0f5baa6@mail.gmail.com>
Date: Wed, 18 Oct 2006 18:44:30 -0700
From: "Martin Cooper" <martinc@apache.org>
Sender: mfncooper@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: TagHandler design for tag implementations (was Re: JXP Template
 support?)
In-Reply-To: <45365301.90309@twdata.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_56482_1445868.1161222270175"
References: 
 <9252368.1161176644166.JavaMail.os-j2ee@opensymphony01.managed.contegix.com>
	 <45365301.90309@twdata.org>

------=_Part_56482_1445868.1161222270175
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/18/06, Don Brown <mrdon@twdata.org> wrote:
>
> 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();
>   }
> }


Hmm, this is starting to look like it would if you used ECS:

http://jakarta.apache.org/ecs/index.html

--
Martin Cooper


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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

------=_Part_56482_1445868.1161222270175--