On Tue, 13 Mar 2001, [iso-8859-1] Jean-Noël Ribette wrote:
> ----- Original Message -----
> From: Michael Gerdau <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 13, 2001 2:35 PM
> Subject: Re: [PROPOSAL - specialized taglib for fast interface development]
>
>
>
> > Why not try to add your more specialized tags to the other taglibs
> > under new names or by adding additional options to the existing tags ?
>
> Well, I am not sure about that as struts-light tags are specialized tags and does
>not allow to do the same thing as the
> tags now in struts taglibs.
>
I would prefer to keep the struts-html library at a (pretty
much) one-to-one correspondence between custom tags and the corresponding
HTML tags that they render. Fancier things should be factored into a
separate tag library. I view struts-light more as an extension than a
replacement of the existing tags, sort of like macros in a programming
language.
> >>From a design point of view I think your taglib shouldn't merely copy
> >code from other taglibs as that would require changes in more than
> >one place should the original ever need changing.
>
> That is sure. The actual code is just a first try to show the idea of the taglib. A
>good design should be found so that
> it can evolve easily. However, it's need some though as
> - Some struts-light tags do the job of more than one usal tag. So it is impossible
>to just extend a tag.
> - struts:html tags do nearly all the job in doStartTag and doEndTag. So it is
>difficult to, for example extends the Form
> tag to include presentation code. Maybe something like this is enough for some tags :
> public myNewFormTag extends FormTag
> public int doStartTag()
>
> // do some stuff before the <form> tag
> doSomething();
> int i = super.doStartTag();
> // do some other stuff after the <form> tag
> doSomeOtherThing();
> return i;
> }
> but some others may not be implemented this way.
> I am thinking about this.
>
While thinking about this, it is worth remembering we will probably need
to refactor the code in the struts-html tag implementation classes anyway,
in order to support an XHTML 1.0 compatible output rendering. This will
be a good opportunity to factor out code that generates common fragments
into utility classes that can be shared by multiple tags.
> >Best,
> >Michael
Craig