> From what I've seen most custom tags seem to have been
> implemented as one big doStartTag() or doEndTag(). The
> entire implementation of the tag is in that one method.

I have worked to move most of the code out of doStartTag() and doEndTag()
for many tags.  My pattern has been to have a "render*" method that
returns a String with the HTML to be rendered that you can override to
render things how you like.  The tags aren't perfect but they are better
factored than in previous releases.  I'm open to suggestions on further
refactoring of the html taglib.  I'm personally not as interested in the
other tags because I use JSTL but there may be another committer willing
to work on those.

David

> 
> In order to modify the behavior, more often than not,
> the only way to do this, is to completely rewrite that
> method by copy-and-pasting the old implementation into
> your new tag, modify it slightly and be done with it.
> The only reuse comes with the getters and setters for
> the tag's properties.
> 
> This approach to "extending" breaks the minute a new
> release of your "base" tag changes significantly. You
> either have to redo your extended tag based on the new
> release or leave your extended tag as is, and potentially
> leave bugs in that were fixed in the new release.
> 
> I've had some limited success with tags that implement
> doStartTag() (and/or doEndTag() in more discreet steps:
> 
>       // method names and (non-existing) return types
>       // purely illustrative
>       public int doStartTag() throws JspException {
>               doStart();
>               doStep1();
>               doStep2();
>               doEnd();
>       }
> 
> This way you can overload only the method that deals
> with whatever you need to modify and leave everything
> else as is.
> 
> If you also had pre- and post-processing methods for
> every discreet step in the "process", you'd have even
> more flexibility:
> 
>       // method names and (non-existing) return types
>       // purely illustrative
>       private String doStep1() {
>               preDoStep1();
> 
>               // step 1 implementation here
> 
>               postDoStep1();
>       }
> 
> Hopefully you see where I'm going with this. The pre-
> and post-processing methods could be implemented to
> skip, ignore, modify, etc. the implementation of the
> real method.
> 
> I haven't done anything like this with custom tags
> myself, but I've used a few products (ATG Dynamo comes
> to mind first) that use this sort of architecture in
> the entire application, and it's extremely flexible.
> 
> I realize that doing something like this would probably
> have a performance impact and would most likely be overkill
> for everyone but that one screwed up developer that needs
> to modify every tag he gets his hands on, but as far as
> extensibility goes, something like this would greatly
> improve on how custom tags can be extended, IMHO.
> 
> I'm sure people on the list who have far more experience
> than I do with writing taglibs, and application architectures
> in general, will see lot of things wrong with this approach
> and can come up with something better, but as someone who
> has had to extend a somewhat large number of custom tags
> (Struts and otherwise), I'm completely fed up with the
> copy-and-paste codeing I'm forced to do right now.
> 
> What say ye, oh Struts gods (and goddesses)? :)
> 
>                               -TPP
> 
> -----------------------------------------
> This email may contain confidential and privileged material for the sole
> use of the intended recipient(s). Any review, use, retention,
> distribution or disclosure by others is strictly prohibited. If you are
> not the intended recipient (or authorized to receive for the recipient),
> please contact the sender by reply email and delete all copies of this
> message.  Also, email is susceptible to data corruption, interception,
> tampering, unauthorized amendment and viruses. We only send and receive
> emails on the basis that we are not liable for any such corruption,
> interception, tampering, amendment or viruses or any consequence
> thereof.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to