On Thu, 2002-09-19 at 22:22, Shawn Bayern wrote: > 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.
k. it took me a while to figure out HOW to write things back to the
response when there was no bodyContent member to toy with, and was
beginning to think i couldn't. but eventually i stumbled across
pageContext.getOut()...
> (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.
if the page is buffered, then its likely to be a container limitation
though, right? (assuming i know that no parent tags are buffering).
either way, i guess there's nothing i can do about it. i like the
INCLUDE though, the really long pages can start being downloaded before
things are done, which can help when the page is 100-200K and can take a
few seconds to process and the client is on a slow connection. i'm more
concerned about starting the stream back to the client than i am with
actual performance of writing things out is concerned, although every
nano-second of performance adds up... ;-)
> > 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,
sure does. my initial reason for returning different codes was to write
a tag that would output different things at the beginning depending on
what other tags it contained. so, the first run it would buffer things
and allow the containing tags to voice their requests, a very similar
interface to jstl ParamParentI in fact. then, it could save the
information off as an attribute for that particular page & tag instance
(although there would normally only be one per page). for subsequent
runs, the information would be retrieved from the attribute and used
immediately, then the body could be INCLUDED. however, i cannot figure
out how to determine if a page has been modified and recompiled, so i
think i'm going to have to give that initial idea up, for the time being
at least.
--
CraigL->Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
