struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Miller" <>
Subject Re: Feature suggestion: <struts:errors/> tag
Date Tue, 18 Jul 2000 18:04:14 GMT
I've been following the template proposal with a lot of interest, and
realised that there was potential for some overlap with the error handling I
was talking about.
You're looking at taking this one step further - so that, using the example
of an error page, the error template had codes embedded in it that could be
matched up to some actual (XML?) error messages. A custom tag would then
apply the mapping to produce the resultant error page, correct? If we then
wanted to target WAP say, we'd just map to a different template.

Ant (Jakarta) provides something like this with its tokens (you can have a
text file with @tokenname@, and it will copy the file, substituting tokens
for actual values as it goes). I haven't played with it much, but I can see
some quite powerful uses for it.

The tricky part with doing this in Struts is deciding how to handle
iteration. It's probably not enough to just have a block that gets repeated
for each row of data. For example, what happens if we want to make every
second row an alternate colour?

The other issue I see is that the Struts tags are (currently) tied quite
heavily to HTML. So if Struts were to implement some kind of XSL
transformation tag to allow targetting of different platforms, we wouldn't
want to be using any of the Struts tags that render HTML?...

I'll give it some thought :-)

----- Original Message -----
From: "Craig R. McClanahan" <>
To: <>
Sent: Tuesday, July 18, 2000 5:33 PM
Subject: Re: Feature suggestion: <struts:errors/> tag

> Chris Miller wrote:
> > I want to use the <struts:errors/> tag, however I'm not entirely happy
> > the concept of storing HTML in the resource file for the errors.heading
> > errors.footer (or for anything else for that matter). Also, the
> > <struts:error> tag seems a bit restrictive.
> >
> > What I would like to do is be able to provide the name of a template to
> > include that will handle displaying the errors:
> >
> > <struts:errors template="errors.jsp"/>
> >
> > Actually, even better would be to be able to do something like:
> > <struts:errors template="errors"/>, where 'errors' is a global action
> > mapping, so I can abstract the name of the actual JSP page.
> >
> > The template would then be hand-crafted to display the error message
> > the appropriate HTML, using <struts:message> tags to display appropriate
> > headings etc, and <struts:iterate> tags to loop through the error
> > as required.
> >
> > This way I can have multiple error templates for various page designs,
> > well as gain a lot of flexibility as to what appears in the error
section of
> > a particular page. Also, changes to the design wouldn't require changes
> > all the different locale resource files etc etc.
> >
> > I realise I can probably do this myself with a <jsp:include>, but I
think it
> > would be a nice addition to the framework.
> >
> > Does this make sense? (Since I haven't done much actual code in struts,
> > might be way off base!).
> >
> That's quite interesting.
> It also ties in with two other ideas I have been thinking about:
> * The template tags proposal submitted (to Struts)
>   by David Geary
> * A tag library in the "jakarta-taglibs" project at
>   <> that lets you apply XSL
>   transformations to an XML data source.
> What I've been thinking about (along with Eduardo Pelegri-Llopart, the
> specification lead for the JSP spec) is a custom tag that lets you do
> simple parameterized text replacements as you process a data source
against a
> template.  That way, you could ask your database for a set of rows (or
receive a
> set of message keys or XML objects), and then your template would have
> placeholders for where the column values go, and the template would have a
> that repeats for each row.
> The error messages gadget in Struts sounds an awful lot like a special
case of
> this scenario.  Does that make sense?
> >
> > Chris Miller
> Craig

View raw message