Well, while I understand you solution, I worry about one thing.
I'll have the code that "preloads the lists" in a lot of different actions,
and I don't want to have to repeat that code.
I don't think it violates that at all, if the tag is written correctly. The
tag doesn't access the database directly. It just access the data.model.
But the real point is that while tags can be made to work together, existing
tags cannot be extended (easily anyway)...
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:14 PM
Subject: Re: tags build upon tags
>
>
> On Fri, 24 Aug 2001, John Raley wrote:
>
> > Date: Fri, 24 Aug 2001 12:18:02 -0700
> > From: John Raley <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: tags build upon tags
> >
> > Funny, I was just griping about this to a friend last night: that tags
> > aren't composable like functions and classes. IMO it's a major weakness
> > in JSP. There was some discussion earlier on this list, see "Using tags
> > from Java code". The short answer is you do it all yourself.
> >
>
> Hmm, the main reason that <html:select> and <html:options> are two
> separate tags (instead of one) is so you *can* compose them together.
>
> > David Corbin wrote:
> >
> > >I would like to write a tag that is essentially <html:select> +
> > ><html:options> + domain data from a database.
> >
> > >Is there a standard way to construct such a tag? Should I just write
> > the >whole thing by hand? Should I write it be calling the other tag
> > classes? > >David Corbin > >
> >
>
> Have you considered not writing a new tag at all? Unless there are some
> really interesting requirements, you should be able to do something like
> this:
>
> * In a Action that preceeds the creation of your form, create two
> ArrayLists (one for the labels and one for the values). Store these
> as request attributes under keys "labels" and values".
>
> * When the JSP page is executed, you just say:
>
> <html:select name="propertyName">
> <html:options name="values" labelName="labels"/>
> </html:select>
>
> * If this list of labels and values gets used repeatedly, you might
> create them at application startup time and store them in application
> scope instead.
>
> It would certainly be feasible to write a custom tag to do the database
> lookup inside the tag, but this violates the principle of separating how
> the data is stored (in the database) from how it is presented (on the
> page). The strategy above establishes a very simple mechanism for
> communication from the model layer to the view layer, without creating any
> undo dependencies on either side.
>
> Craig
>
>
>
>
