jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <Eduardo.Pelegrillop...@Sun.COM>
Subject Re: Tag lifecycle, reprise
Date Sat, 12 May 2001 18:40:55 GMT
See intermixed....

"A. Keyton Weissinger" wrote:
> 
> Hi Shawn. I agree that these topics need to be addressed in the tutorial.
> 
> A couple comments...
> 
> > 1) Properties are expected to remain consistent.  This means that:
> >
> >    - no user code should call a setXXX() accessor of a tag handler
> Should this not be amended to be the following?
>         - no user code should call a setXXX() accessor corresponding to a tag
> attribute.
> It seems to me that I may want some setters on my tag that are outside the
> attribute mechanism.
> For example, if I have:
> <ora:displayContents>
>    <ora:getContents/>
> </ora:displayContents>
> It might be nice to have a setContent() method in the parent tag that does
> not affect a tag attribute.
> This needs more thought, but I think you see what I mean....


It is OK to invoke a setter method as long as:

 * It is not a setter on a property that is an attribute.
 * THe setter is part of the 'official' sematnics of the tag.

The first constraint is specified in the JSP 1.2 spec PFD2
The second needs to be clarified.  The motivation for this one is to
allow a Tag Library to indicate thta some things are an artifact of its
implementation, not part of its real advertised semantics, and thus make
is possible for aggressive "open coding" implementations, including
those that may get rid altogether of the tag handler instance.


> 
> >    - tag handlers should not perform invocation-specific logic in a
> >      setXXX() method.  That is, the setting of a property should
> >      have no side effects.
> Might add here that the spec (JSP or the JavaBean, I believe) does not
> specify an order in which the JSP container will call setters.

Left to right.

> 
> > Examples:
> >
> > a) Suppose you have a tag that accepts some sort of expression that you
> >    need to resolve, e.g.:
> >
> >       <show value="$my-expression$"/>
> >
> >    "$my-expression$" should be stored by setValue() and evaluated in
> >    doStartTag().  For the behavior that's almost always desired, it should
> >    NOT be evaluated in setValue().
> I disagree somewhat with this. If you have some runtime validation of
> attributes values occurring, you may want this to happen in the setters --
> to short circuit the process. Why wait for doStartTag()? This would require
> evaluation, but not any further processing. THoughts?

Depends on what you want the semantics to be.  Assuming you want
semantics like "<%= ... %>", the evaluation should be done at
doStartTag().  If it were done in the setter then, since the container
(in JSP 1.2 or lower) regards your "$my-expression$" as a literal
constant not as a real run-time epxression, in repeated evaluations
(like in a loop) the container may not re-evaluate the setter, which is
not what you want if you want rtexpr-like evaluation.

	- eduard/o

> 
> Everything else +1
> 
> Keyton

Mime
View raw message