You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Paananen, Tero" <Te...@GTECH.COM> on 2003/08/18 22:23:58 UTC
Re: Tags more extensible (was: Suggestions for Calendar Popup tag
lib?)
[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'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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Posted by David Graham <gr...@yahoo.com>.
> I agree *iff* we're careful about the way it's done. Some of the method
> calls will probably go away anyway if the code is automatically inlined,
> so
> I don't believe method invocation would be the issue.
>
> However, looking at FormTag right now, I see several methods that build
> up
> strings in StringBuffer instances and convert those to String instances
> so
> that they can then be appended to a StringBuffer. All that string
> processing
> can mount up and cost you in the long run, where it would be much more
> efficient to pass the original StringBuffer to those methods so that
> they
> can append what they need, without requiring the creation, copying and
> destruction of multiple StringBuffer and String instances in between.
I considered implementing the methods that way but decided against it for
several reasons.
1. It is, thankfully, not a common Java idiom for methods to alter
objects they receive as parameters. It's much easier to maintain code
that communicates in the traditional "take parameters as input and return
the result as output" mode.
2. Passing in a partially constructed StringBuffer is less reusable than
having the methods return a String. The methods have to worry about
what's in the buffer and what stage of the construction they are called.
I was willing to give up a certain amount of efficiency for the sake of
clarity and maintainability. If the tags are proven to be a performance
bottleneck with benchmarking, I'm certainly open to optimizing the code.
David
>
> --
> Martin Cooper
>
>
> >
> > >
> > >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: struts-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Robert Leland Robert@free2create.org
> > ------------------------------------------
> > Java, J2EE, Struts, Web Application Development
> >
> > 804 N. Kenmore Street +01-703-525-3580
> > Arlington VA 22201
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Posted by Martin Cooper <ma...@apache.org>.
"Robert Leland" <rl...@apache.org> wrote in message
news:3F413BE4.5030309@apache.org...
> 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 agree *iff* we're careful about the way it's done. Some of the method
calls will probably go away anyway if the code is automatically inlined, so
I don't believe method invocation would be the issue.
However, looking at FormTag right now, I see several methods that build up
strings in StringBuffer instances and convert those to String instances so
that they can then be appended to a StringBuffer. All that string processing
can mount up and cost you in the long run, where it would be much more
efficient to pass the original StringBuffer to those methods so that they
can append what they need, without requiring the creation, copying and
destruction of multiple StringBuffer and String instances in between.
--
Martin Cooper
>
> >
> >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: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
> --
> Robert Leland Robert@free2create.org
> ------------------------------------------
> Java, J2EE, Struts, Web Application Development
>
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Posted by David Graham <gr...@yahoo.com>.
> A good way to tackle this is Use Case by Use Case, to avoid talking in
> general terms.
+1 There's no way to factor the tags properly without a specific use case
to guide us.
David
> 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: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
> --
> Robert Leland Robert@free2create.org
> ------------------------------------------
> Java, J2EE, Struts, Web Application Development
>
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
>
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tags more extensible (was: Suggestions for Calendar Popup tag
lib?)
Posted by Robert Leland <rl...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
>
--
Robert Leland Robert@free2create.org
------------------------------------------
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Posted by David Graham <gr...@yahoo.com>.
> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org