struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: tags build upon tags
Date Tue, 28 Aug 2001 00:14:56 GMT

On Fri, 24 Aug 2001, John Raley wrote:

> Date: Fri, 24 Aug 2001 12:18:02 -0700
> From: John Raley <>
> Reply-To:
> To:
> 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

* 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"/>

* 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.


View raw message