Ruth, Craig, and lurkers,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).
I think what I'm after boils down to a method like this:
public String renderTag(PageContext pPageContext, Tag pTagToRender) throws JspException
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
