> Tag reuse is only allowed when the set of attributes that are
> used, and their values, are identical. For example, the
> following two tags will
> *always* use different instances:
>
> <foo:bar baz="a"/>
> <foo:bar baz="b"/>
>
> because the attribute value is different.
My understanding was that the same instance *could* be reused, as long
as setBaz("b") is called between the first doEndTag and the second
doStartTag. Am I mistaken?
--
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
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 03, 2003 2:37 PM
> To: Tomcat Users List
> Subject: Re: more about custam tag life cycle
>
>
>
>
> On Mon, 3 Feb 2003, Will Hartung wrote:
>
> > Date: Mon, 3 Feb 2003 11:00:46 -0800
> > From: Will Hartung <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > Subject: Re: more about custam tag life cycle
> >
> > > From: "Felipe Schnack" <[EMAIL PROTECTED]>
> > > Sent: Monday, February 03, 2003 10:12 AM
> > > Subject: RE: more about custam tag life cycle
> >
> >
> > > This makes me feel muuuuuch better :-)
> >
> > On Mon, 2003-02-03 at 16:09, Tim Moore wrote:
> > > This is NOT true, AFAIK. The same tag instance can be
> used multiple
> > > times
> > *sequentially*
> > > but not *concurrently*. Check out the lifecycle state diagram in
> > > the JSP
> > spec.
> >
> > The way to look at it is simply that the generated code is going to
> > use a tag pool for each distinct class of tags.
> Unfortunately, there
> > is no specific action that tells the tag it is being pulled from or
> > being put back from the pool.
> >
>
> The page will call release() before it is put back in the pool.
>
> > All tags follow the basic lifecycle of simpy
> > constuctor
> > setPageContext
> > doStartTag
> > doEndTag
> >
> > In the pooled environment, it's:
> > constructor
> > setPageContext
> > doStartTag
> > doEndTag
> > doStartTag
> > doEndTag
> > etc.
> >
> > (I've seen some containers, I thinik Tomcat is one, that call
> > setPageContext on each tag, but I've seen others that do not, so
> > setPageContext is not a reliable method to reset the tag
> properties).
> >
> > If the tag implments the TryCatchFinally interface, then a
> doFinally
> > is called after the doEndTag.
> >
>
> This only helps in a JSP 1.2 container, and comes with at
> least some performance price due to the extra
> try/catch/finally block that the page compiler has to create.
>
> > What's is non-obvious is that the doEndTag and doFinally
> are supposed
> > to assume the role of cleaning the tag up for reuse.
>
> That is not what they are for.
>
> The purpose of doEndTag() is to finish up whatever processing
> your tag does, at the end of the closing tag on the page.
> You should not be modifying the attribute values that were
> set by the page anyway, so there should be no need to clean up here.
>
> The purpose of doFinally() is to deal with exceptions that
> were thrown within the body of your tag. You really do not
> want to spend the extra processor cycles when such exceptions
> do not occur, or don't matter to you.
>
> >
> > I particularly like this quote from the spec:
> >
> > "The particular code shown below assumes there is some pool of tag
> > handlers that are managed (details not described, although pool
> > managing is simpler when there are no optional attributes),"
> >
> > This entire problem, at least as I've encountered it,
> revolves around
> > not only optional, but also contradictory tags (i.e. it's okay to
> > specify paramter a, b, or c, but no combination in the same tag).
> >
>
> There are really two issues here -- tag *pooling* (the
> container recycles a previous tag instance instead of
> creating a new one every time) and tag
> *reuse* (the container uses the same instance for more than
> one tag with identical attributes). It's entirely legal to
> have tag reuse even in a container that does not implement
> tag pooling, so you have to account for both possibilities.
>
> Tag reuse is only allowed when the set of attributes that are
> used, and their values, are identical. For example, the
> following two tags will
> *always* use different instances:
>
> <foo:bar baz="a"/>
> <foo:bar baz="b"/>
>
> because the attribute value is different. Likewise, the
> following two tags will *always* use different instances:
>
> <foo:bar baz="a"/>
> <foo:bar bif="a"/>
>
> because different attribues are used.
>
> However, the following tag instances *can* be reused (and
> smart developers will always program their tags as if they
> *will* be reused):
>
> <foo:bar baz="a"/>
> <foo:bar baz="a"/>
>
> If your container does implement tag pooling (in addition to
> or instead of tag reuse), it will call release() before
> returning the instance to the pool. That makes release() the
> right place to reset everything to defaults.
>
> > And like I said earlier, it would be nice if there were a pool
> > interface added to the lifecycle to clean up the tag processing to
> > make optional properties more portable and easier to write for.
> >
>
> There are two simple rules for writing pooling-safe and
> reuse-safe tags:
>
> * Do not modify the instance variables that were
> set by your attribute setters in ANY of the
> doXxx() methods.
>
> * If you want to clean up, do so in release(),
> which will be called before a tag instance can
> be returned to the pool.
>
> Or, in JSP 2.0, use the new SimpleTag API and dispense with
> the whole set of concerns about tag lifecycle (such tag
> instances cannot be pooled, so you don't have to worry about it).
>
> > Regards,
> >
> > Will Hartung
> > ([EMAIL PROTECTED])
> >
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
