Custom Tag Handler

[Jayashree Mohan]

Given the following tag handler defined with <bodycontent>JSP</bodycontent>

public class body extends TagSupport {
public int doStartTag() throws JspException{
return EVAL_BODY_INCLUDE;
}
public int doAfterBody() throws JspException {
try { pageContext.getOut().print("how are you?"); }catch(IOException e) {}
return SKIP_BODY;
}
}

what will be printed out by the following part of a jsp page?
<prefix:sufix>
<i>Hello</i>
</prefix:sufix>

1) The tag handler won't compile.
2) The jsp page will print Hello how are you?
3) The jsp page will print how are you? Hello
4) The jsp page will print Hello

The mock exam gives the answer as 4) but I feel its 2). The explanation given was "you can't print from doAfterBdoy in a TagSupport handlers".
Is the answer and explanation rite??

[Charles Lyons]

The explanation given was "you can't print from doAfterBdoy in a TagSupport handlers". Is the answer and explanation rite?

I've never heard that before; I can't see any technical reason why you shouldn't write content in doAfterBody(). In fact, there might be a compelling reason to do so. For example, what about a tag which builds a table? It might do:

<td>BODY</td>
<td>BODY</td>
...

where BODY is evaluation of the body content. Then we might want doStartTag() to write "<td>", then evaluate the body, then doAfterBody() to write "</td>" until there is no more content.

Whether you would want to use doAfterBody() to write content is a different matter entirely, and perhaps this job is better left to a BodyTag, but I don't see any reason why content output from doAfterBody() should be banned.

I don't think their explanation makes sense anyway: if you "can't print from doAfterBody()", then should we expect a runtime exception? It seems unlikely that just nothing will happen despite the fact we're accessing 'out' directly.

I agree with you; I think 2 should be the correct answer.