Nice start Shawn.
It reminds me that I need to review the design of some of my early taglibs.
It would be nice if the tuturial was split up between JSP 1.1 and JSP 1.2
features instead of intermixing 1.2 features such as TryCatchFinally and
doFinally with JSP 1.1 features.
One other point, if a tag creates a script varaible who's scope is
AT_BEGIN or AT_END, the object created must be a different object
from the tag handler. Its ok for the tag handler to be the script variable
object if its scope is NESTED.
Regards,
Glenn
Shawn Bayern wrote:
>
> Prompted by Mac's comments, I conducted an informal code review and
> realized quite how widespread tag-lifecycle misconceptions are. Most tag
> developers I know, including myself, have handled things incorrectly at
> one point or another. Even the excellent Tag Libraries Tutorial on Sun's
> site (http://java.sun.com/products/jsp/tutorial/TagLibrariesTOC.html) has,
> in its example of an iteration tag, what seems to be a bug that most
> developers have made at least once:
>
> public void setGroup(Collection members) {
> if(members.size() > 0)
> iterator = members.iterator();
> }
>
> This morning, to respond to the problem, I've compiled a short list of
> guidelines for tag-handler lifecycle management which I'd like to include
> in the Jakarta-Taglibs Tutorial. Here's a first draft. It contains
> nothing original, but it attempts to target particular misconceptions and
> organize the info from the 1.2 spec that's useful for tag developers.
> Any comments?
>
> Shawn
>
> -----
>
> Guidelines for tag lifecycle management:
>
> 1) Properties are expected to remain consistent. This means that:
>
> - no user code should call a setXXX() accessor of a tag handler
> - the tag handler's code itself should not modify properties that are
> set by a setXXX() method
> - tag handlers should not perform invocation-specific logic in a
> setXXX() method. That is, the setting of a property should
> have no side effects.
>
> 2) Private, invocation-specific state must be managed manually.
> Implications include that:
>
> - release() is not necessarily called between invocations, which
> means that tag logic should not count on private invocation-
> specific state being reset by release()
> - doEndTag() is not necessarily called at the end of every invocation
> (in cases of abnormal termination -- e.g., an exception thrown inside
> a tag's body or by one of its methods)
> - private invocation-specific state is thus best initialized in
> doStartTag()
>
> - doFinally() *is* always called for tag handlers that implement
> TryCatchFinally, so this method should be used if any invocation-
> specific resources need to be released
> - release() *is* always called at least once for a tag handler before
> it is garbage-collected, so this method can and should be used to
> release any long-term resources
>
> 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().
>
> Similarly, Iterators and Enumarations should not be extracted in a
> setXXX() method. setXXX() methods are meant to be "idempotent";
> write them so that they can be called multiple times with no
> side effects (and, conversely, only once instead of multiple times
> if the argument passed is the same).
>
> b) Private state that's kept for each invocation should typically be
> reset in doStartTag(), not in release(). If you have an iteration
> index controlling the behavior of a loop, doStartTag() is the
> appropriate method from which to initialize it.
>
> c) If a tag needs to open a new database connection (or file, or other
> external resource) for every invocation, the tag handler should
> implement TryCatchFilnally and close the database connection (or
> other resource) in doFinally(). doEndTag() might not be called,
> and release() might not be called until long after you expect it to be.
--
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
