On Sun, 28 Jul 2002, Craig R. McClanahan wrote:
> Date: Sun, 28 Jul 2002 15:36:08 -0700 (PDT)
> From: Craig R. McClanahan <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tags: write private "init()" method to init. vars from cons.
> and release
>
>
>
> On 28 Jul 2002, David M. Karr wrote:
>
> > Date: 28 Jul 2002 14:58:23 -0700
> > From: David M. Karr <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: Tags: write private "init()" method to init. vars from cons.
> > and release
> >
> > >>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
> >
> > Craig> On 28 Jul 2002, David M. Karr wrote:
> >
> > >> Is there some reason the Struts custom tags have redundant initializations
>of
> > >> their instance variables, once as implicit initializations, and once in the
> > >> "release()" method? I hope that this code is either generated, or someone
>has
> > >> carefully examined every single one to verify that the implicit init. value
>is
> > >> identical to the value it's set to in "release()".
> > >>
> > >> It would seem to me that a better strategy would be to write a private
>"init()"
> > >> method which initializes all the instance variables to their initial state,
>and
> > >> which is called from the "release()" method and a new no-args constructor (I
> > >> would guess that none of the tags have a defined constructor).
> > >>
> > >> Is there a good reason for how this currently works?
> >
> > Craig> It actually turns out that initializing to non-null values tends to get
> > Craig> you in trouble in containers that recycle tag instances -- we really
>need
> > Craig> to go through and rip that out (as well as the tendency to modify the
> > Craig> specified attribute values during doStartTag() or doEndTag(), which will
> > Craig> cause nothing but grief with optimizing page compilers.
> >
> > The issues with recycled tag instances is exactly why I was looking at this. I
> > assume, by this statement, that you agree the current strategy isn't right? If
> > so, I'll submit a bug for this. I plan on building a patch for this myself,
> > but I'm not certain when I'll get to this. As I described, I would remove the
> > implicit initializations, implement the "init()" method with the correct
> > initializations, create a no-args constructor, and call the "init()" method
> > from both "release()" and the no-args constructor. That should just take a few
> > minutes to modify very tag :) .
> >
>
> I would rather avoid even having a private init() method -- I'd rather see
> us initialize all String-valued attributes to null in their declarations
> and in the reset() methods. Any place in the code we've previously
> depended on the default value should do explicit checks for null and
> modify their behavior accordingly.
>
> > Do you have a good example of your other statement, about modifying the
> > specified attribute values in the tag methods? I may have seen that, but I
> > want to be sure I know what you're referring to.
> >
>
> I've fixed them as I've seen them, so don't know of any offhand -- but I
> would review the most complicated tags like <html:form> first. If you see
> something like "this.foo = ..." in a tag's doStartTag() or doEndTag()
> method, that is a danger sign.
>
More particularly, this is an issue only if "foo" is a property that
corresponds to a tag attribute. It's fine for tag instances to have
general purpose instance variables.
> Craig
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
