On 18 Sep 2002, Craig Longman wrote:
> 1) is this resetting of bodyContent the responsibility of the
> implementing tag? seeing as the return from doStartTag() doesn't seem
> to be included in the AttrSet that decides if a tag can be reused or
> not, i guess it is? (the BodyTagSupport.doStartTag(), but it returns
> EVAL_BODY_BUFFERED by default so it can assume that setBodyContent()
> is called)
Short answer: yes, the behavior you're describing is consistent with a
container acting legally. The tag is responsible for adapting
appropriately.
(I should say, just for completeness, that questions like this get
intricate fast, so it's important to note that what I say extemporaneously
isn't official or backed up by authoritative word from the JSP expert
group.)
> 2) is the goal of using EVAL_BODY_INCLUDE when possible an admirable
> one? considering that the included body _might_ be very big, i think it
> is, but i'd like confirmation.
Note that the page might be buffered anyway, which obviates your
stream-to-the-client case. But in general, yes: EVAL_BODY_INCLUDE has
the potential to be more efficient than EVAL_BODY_BUFFERED. All things
being equal, it should run more quickly, though of course it's nearly
impossible to say *how* much quickly without testing.
> 3) is returning different values from doStartTag() a
> stupid/dangerous/illegal thing to do?
No, but as the logical conclusion of the issues you've raised, returning
different codes for different invocations does require additional work on
your part. I typically record state in an instance variable that's under
the control of doStartTag(), as in:
doStartTag() {
// ...
needBody = true;
return EVAL_BODY_BUFFERED;
}
doEndTag() {
if (needBody)
// ...
else
// ...
}
Hope that helps,
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
