Re: Tags more extensible (was: Suggestions for Calendar Popup taglib?)

[Robert Leland]

Replyied Inline.

Paananen, Tero wrote:

[this is in response to Robert Leland's reply to my
post on the struts-user list griping about the
(un)extensibility of custom tags]
 

My #1 pet peeve about custom taglibs are that almost
none of them have been designed with extensibility in
mind. This includes all the Struts tags that I've had
to tinker with.
Extending them basically means, more or less,
copy-and-pasteing all the existing code into your new
taglib, then customizing the behavior to meet your
needs.
     

Tero:

   Your insight into how the Struts Tags can be made
more Modular so they can be extended easier would be very
valuable and welcome.I encourage you can bring the issue
up on the struts-dev list.
   

Robert,

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.
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 doubt there would many any notiable impact on performance.

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.
I feel your pain as one ex-U.S. President once said.

What say ye, oh Struts gods (and goddesses)? :)

I agree totally, at the level were currenrly arguing, I dare anyone to 
disagree !
A good way to tackle this is Use Case by Use Case, to avoid talking in
general terms.
1) What specific tags have you or do you want to modify the behaviour of.
2)  What level of granularity makes sense.
3) Do we use simple overriding, or publish/subscribe or Decorator 
Pattern, others.
    I would start off by recommending the Decorator pattern. I believe 
this is what
    David Karr did when adding JSTL functionality to Struts.


			-TPP
 

-Rob


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


 



--
Robert Leland                   [EMAIL PROTECTED]
------------------------------------------
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street           +01-703-525-3580
Arlington VA 22201