> 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: [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
> >
> >
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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