struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Tags creating Tags
Date Mon, 27 Oct 2003 03:44:37 GMT
Lukas Bradley wrote:

>Ruth, Craig, and lurkers,
>
>I think what I'm after boils down to a method like this:
>
>public String renderTag(PageContext pPageContext, Tag pTagToRender) throws
>JspException
>
>  
>
A look at the JSP Specification will tell you that this would not work 
at all for a classic tag handler (i.e. implements Tag or implements 
BodyTag).

>After creating the tag manually, you could pass it to this method, and have
>it rendered.  The return value of a String should be the final output of the
>Tag.  The method would check for BodyTag, IterationTag, etc support, and
>react to it.  This way, the user could embed custom tags (Struts or
>otherwise) within their own custom tags.
>
>I'm surprised a method like this doesn't already exist.  This wouldn't be
>recursive, nor would it recompile on each shot.  You may be right in calling
>this a tad "hackish," but it would be useful, no?  I can even think of
>another method that would be the incredi-hack:
>
>public String renderTag(PageContext pPageContext, Tag pTagToRender) throws
>JspException
>
>Where you pass in "<html:file .... />" instead of the Tag object itself.
>Now that would be aggressive.
>
>For another approach, the JspFragment interface looks promising.  However,
>I'm stuck with Tomcat 4.1 for now, so JSP 2.0 is out.
>
>  
>

I think the approach you suggest is problematic, for many of the reasons 
that Action chaining is problematic.  The most serious issue is that 
you're trying to use a JSP artifact (a custom tag implementation class) 
for something it was never designed to do (be a reusable "output 
generator" outside the context of the very strict and complex lifecycle 
for tag instances described in the JSP specfiication).  "Hackish" does 
not begin to describe how much trouble this kind of anti-object-oriented 
approach will lead you to in the long run.

The right answer would be to create your own tag class that does exactly 
what you want.  If your tag wants to leverage functionality from 
existing tag classes (and you don't want to cut-n-paste), either make 
your class a subclass of the existing one (presuming the stuff you need 
is already abstracted into useful protected methods), or abstract the 
stuff you need into utility classes that can be shared between your tag 
and the standard ones, and then lobby to have the same factoring done in 
the standard classes.

This is the foundational basis on which all Struts tag classes are 
organized, and has proven to support a pretty rich library of tag class 
implementations that (in many cases) reuse or specialize protected 
methods in their subclasses.  In no case was a "generate a tag" type of 
hack considered, because it's not necessary.  All that's necessary is 
applying sound design practices for factoring reusable code into 
reusable chunks.  I won't try to claim that we've done a perfect job at 
the current factoring, but the existence of something like struts-el 
(which was basically built on top of the existing tags, without having 
to rip them apart) is pretty good evidence that we're on the right track.

Trying to interfere with the tag instance lifecycle that the JSP page 
compiler assumes pretty much guarantees you'll end up with disaster.

>Lukas
>
>  
>

Craig



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message