Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Subject: RE: Custom tag life cycle
From: Felipe Schnack <felipes@ritterdosreis.br>
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
In-Reply-To: 
	<66337F04F2A1E440BF87F2080B5F537001481DD4@madison.dc.Blackboard.com>
References: 
	<66337F04F2A1E440BF87F2080B5F537001481DD4@madison.dc.Blackboard.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Date: 03 Feb 2003 15:37:15 -0200
Message-Id: <1044293835.1766.212.camel@desenv1.ritterdosreis.br>
Mime-Version: 1.0

  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:gmcgath@panix.com]=20
> > Sent: Monday, February 03, 2003 9:14 AM
> > To: tomcat-user@jakarta.apache.org
> > Subject: Custom tag life cycle
> >=20
> >=20
> > The webapp which I am developing (see http://www.timeczar.com for
> > details) uses a moderately complex custom tag library, and=20
> > I've found the lifecycle of a TagSupport object to be very confusing.
> >=20
> > As I understand it, a TagSupport object may (but is not=20
> > guaranteed to) be reused for subsequent occurrences of the=20
> > same tag in a JSP.  This means that attribute variables can't=20
> > safely be initialized in the constructor, because they may=20
> > not get reinitialized for subsequent occurrences of the tag. =20
> > (Here I'm assuming that setter functions for attributes=20
> > simply set an instance variable.)=20
> >=20
> > After some digging, I found that the recommended way to reset=20
> > attribute instance varaibles is to use the doEndTag method. =20
> > This probably doesn't work if a tag is nested within a tag of=20
> > the same name, but I can live with that.
>=20
> 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.
>=20
> 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.
>=20
> >=20
> > Doing this works fine in Tomcat.  However, I recently ported=20
> > my webapp to Resin and found that it doesn't work there. =20
> > Here's a cut-back excerpt from my JSP:
> >=20
> > <caltags:eventset>
> >     <caltags:evtstartdate mode=3D"date" length=3D"m"/> -
> >     <caltags:evtenddate mode=3D"date" length=3D"m"/> </caltags:eventset=
>
> >=20
> > The class which implements eventset includes the tag body=20
> > once for each event in the set.  The evtstartdate and=20
> > evtenddate tags are implemented by a class called DateTag,=20
> > which extends TagSupport. Under Tomcat, DateTag.setMode and=20
> > DateTag.SetLength get called once for each tag in each=20
> > inclusion of the tag body.  Under Resin, only two calls (one=20
> > for each of the date tags) are made to each of setMode and=20
> > setLength.  If I clear the mode and length fields when I call=20
> > doEndTag, then all occurrences of the date tags except the=20
> > first take on their default attributes, which is not the=20
> > behavior I want.
> >=20
> > Are both Tomcat and Resin within spec in implementing=20
> > different behaviors here?  If so, what is the correct point=20
> > in the lifecycle to reset attribute values in a TagSupport object?
>=20
> 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.
>=20
> Here's what I'd recommend:
>=20
> Initialize the mode and length instance variables to null at
> construction time.
>=20
> Do something like this in doStartTag:
>=20
> String mode =3D this.mode;
> if (mode =3D=3D null) {
>   mode =3D DEFAULT_MODE;
> }
>=20
> ...and repeat for length.  Never modify the instance variables or call
> their setters yourself -- let the container manage them.
>=20
> --=20
> 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
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>=20
--=20

Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893

Centro Universit=E1rio Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


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