> -----Original Message-----
> From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 04, 2001 10:37 PM
> To: [EMAIL PROTECTED]
> Subject: Custom JSP Tags and Validator
>
>
> I have couple of issues with the best way to handle
> the possible incorporation of the validator custom JSP
> tags into Struts. I'll go through each of the issues.
>
> I made two custom jsp tags for errors based off of the
> Struts' tags. One was validator:errors which is the
> equivalent of html:errors except it iterates through
> the errors instead of just printing them. This is
> necessary to remove the html formatting from the
> message resources (for generating error messages in
> JavaScript for example).
Even though its common practice, wrapping html around messages within the
properties file should be black-listed. OK, black-listing might be a little
extreme... However, I feel its fair to consider it a bad practice within the
context of a model/view separation framework.
IMHO, the messages should not be parsed, and the messages shouldn't be
coupled to any particular form of display. (Today its html, tommorrow
Javascript message boxes, next week XML, PDF, etc.. right?)
Assuming that this previous line of babble stands true, it seems logical to
treat errors like any other collection we display. The main forms of this
being:
<logic:present name="errors">
{{ what ever i want eg. script/html formatting/xml tags/ etc.. }}
<logic:iterate name="errors" id="error">
...
or
<html:errors property="lastName"/>
> I also made a header and
> footer attribute that are optional so you can specify
> a header and footer as something optional instead of
> automatically have 'errors.header' and 'errors.footer'
> included in the output of the tag if they exist. I
> did some work on making the standard html:errors tag
> iterate if an id attribute is used and otherwise work
> the way it currently does, but if you have a lot of
> jsp pages with html:errors they probably all use
> 'errors.header' and 'errors.footer' which you wouldn't
> want to be printed in a case like Example 1. I could
> make it work like the validator:errors tag with an
> optional header and footer attribute if the id
> attribute was used so this wasn't an issue. Anyway
> I'm not sure if it is becoming a bit confusing making
> so much dual functionality all in one tag and it makes
> sense to keep it a separate tag that could go in
> 'org.apache.struts.taglib.validator'. I'm leaning
> towards adding a separate tag, but I wondered what
> others thought.
>
> Example 1 (possible modified Struts Tag):
> <ul>
> <html:errors id="error">
> <li><bean:write name="error"/></li>
> </html:errors>
> </ul>
>
> Example 2:
> <validator:errors id="error" header="errors.header"
> footer="errors.footer">
> <li><bean:write name="error"/></li>
> </validator:errors>
>
> Example 3:
> <validator:errorsExist>
> <bean:message key="errors.header"/>
> <ul>
> <validator:errors id="error">
> <li><bean:write name="error"/></li>
> </validator:errors>
> </ul><hr>
> </validator:errorsExist>
>
> The validator:errorsExist was just a convenient
> shorcut not to have to put the key for the errors into
> the logic:present tag. I'm thinking that even though
> it seems nice to have, it doesn't belong in the main
> Struts' project.
>
> The tag that generates JavaScript is currently
> separate from the from html:form. I have a couple of
> ideas. One is to leave it totally separate like it
> already is. The other is to have a javascript="true"
How about script="true"?? That way we're not coupled to and/or indicating
javascript usage is the only game in town.
(Or would a more specific variant of this be appropriate??
eg. script="ECMAScript"; script="VBScript"; script="PerlScript"; etc..)
> added to html:form so there wouldn't be an extra tag.
> Another is that it should be placed inside the body of
> html:form so it can automatically get the formname,
> but leave it so it can be overridden.
>
> Basic use of tag matching it to the bean of the form
> in scope.
> <validator:javascript formName="typeForm"/>
>
> This only generates the dynamic JavaScript for this
> form so you can make a reference to the static
> JavaScript on a separate page to take advantage of
> browser caching.
> <validator:javascript formName="typeForm"
> dynamicJavascript="true" staticJavascript="false"/>
>
> I hope I was clear (especially describing the issue
> with the errors tag). Let me know any thoughts or
> other ideas on this.
>
> David
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>
-- Levi
