If doEndTag isn't a good option for cleaning, why don't you use
doFinally()?
  Anyway, it's incredible... i'm always finding out that writing custom
tags is a real nightmare :-)

On Mon, 2003-02-03 at 15:30, Tim Moore wrote:
> > -----Original Message-----
> > From: Gary McGath [mailto:[EMAIL PROTECTED]] 
> > Sent: Monday, February 03, 2003 9:14 AM
> > To: [EMAIL PROTECTED]
> > Subject: Custom tag life cycle
> > 
> > 
> > The webapp which I am developing (see http://www.timeczar.com for
> > details) uses a moderately complex custom tag library, and 
> > I've found the lifecycle of a TagSupport object to be very confusing.
> > 
> > As I understand it, a TagSupport object may (but is not 
> > guaranteed to) be reused for subsequent occurrences of the 
> > same tag in a JSP.  This means that attribute variables can't 
> > safely be initialized in the constructor, because they may 
> > not get reinitialized for subsequent occurrences of the tag.  
> > (Here I'm assuming that setter functions for attributes 
> > simply set an instance variable.) 
> > 
> > After some digging, I found that the recommended way to reset 
> > attribute instance varaibles is to use the doEndTag method.  
> > This probably doesn't work if a tag is nested within a tag of 
> > the same name, but I can live with that.
> 
> Actually I believe that containers would be required to use two
> different instances when tags are nested.  The instance can only be
> reused for subsequent uses of the tag *after* the first one is closed.
> 
> But I would do the initialization in doStartTag rather than doEndTag.
> The latter may not be called if an exception is thrown from within the
> tag body.
> 
> > 
> > Doing this works fine in Tomcat.  However, I recently ported 
> > my webapp to Resin and found that it doesn't work there.  
> > Here's a cut-back excerpt from my JSP:
> > 
> > <caltags:eventset>
> >     <caltags:evtstartdate mode="date" length="m"/> -
> >     <caltags:evtenddate mode="date" length="m"/> </caltags:eventset>
> > 
> > The class which implements eventset includes the tag body 
> > once for each event in the set.  The evtstartdate and 
> > evtenddate tags are implemented by a class called DateTag, 
> > which extends TagSupport. Under Tomcat, DateTag.setMode and 
> > DateTag.SetLength get called once for each tag in each 
> > inclusion of the tag body.  Under Resin, only two calls (one 
> > for each of the date tags) are made to each of setMode and 
> > setLength.  If I clear the mode and length fields when I call 
> > doEndTag, then all occurrences of the date tags except the 
> > first take on their default attributes, which is not the 
> > behavior I want.
> > 
> > Are both Tomcat and Resin within spec in implementing 
> > different behaviors here?  If so, what is the correct point 
> > in the lifecycle to reset attribute values in a TagSupport object?
> 
> The spec allows the container to assume that the attributes of a tag
> handler will be retained across invocations, so if there are multiple
> identical invocations, the setter methods do not need to be called
> again.
> 
> Here's what I'd recommend:
> 
> Initialize the mode and length instance variables to null at
> construction time.
> 
> Do something like this in doStartTag:
> 
> String mode = this.mode;
> if (mode == null) {
>   mode = DEFAULT_MODE;
> }
> 
> ...and repeat for length.  Never modify the instance variables or call
> their setters yourself -- let the container manage them.
> 
> -- 
> Tim Moore / Blackboard Inc. / Software Engineer
> 1899 L Street, NW / 5th Floor / Washington, DC 20036
> Phone 202-463-4860 ext. 258 / Fax 202-463-4863
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
-- 

Felipe Schnack
Analista de Sistemas
[EMAIL PROTECTED]
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
[EMAIL PROTECTED]
Fone/Fax.: (51)32303341


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to