AW: AW: ANNOUNCEMENT: New JAKARTA-STRUTS Subproject

["Nestel, Frank" <fr...@coi.de>]

Hi,

moving this from JSP-INTEREST to Struts User, it's getting even
longer....

> 
> "Nestel, Frank" wrote:
> 
> > Hi Craig,
> >
> > warning, this is long!
> >
> 
> Hi Frank ... glad to hear from you.  See below.
> 
> If you are interested in discussing the details of Struts, you might
> want to
> join the STRUTS-USER mailing list at 
> <http://jakarta.apache.org> rather
> than
> occupying bandwidth on JSP-INTEREST, which should be more general
> purpose.
> 
> >
> > I toyed arround last weekend with the Struts tools, but I'm still
> > unsatisfied. The basic idea as well as the basic approach is very
> > cool anyway. I'd like to stay closer to the JSP/Servlet framework as
> > Webmacro and freemarker, but have a better separation of 
> functionality,
> > layout and data.
> >
> > Some points:
> >
> > * The TextareaTag is broken: Accessing rows and cols 
> attributes, certain
> >   Attributes (like wrapping) of HTML are not available for 
> the struts-tag.
> >

Talking about HTML 4, you left out all taht TABINDEX, NOTABSTOP,
TITLE, LABEL and maybe the FIELDSET thingie from your TabLib form
tags. There is are WRAP (and companions which I don't use in my 
applications) attributes to TextArea which seem
to not have made it to the HTML4 but seem to work in all tested
Browsers and are fairly useful. Real world is a mess :-)

> Some patches to the textarea tag were posted a couple of 
> nights ago that
> fixed
> the basic syntax of the generated tag, and correctly used 
> rows and cols
> as the
> attributes.  Ideas for extensions to the tags are welcome -- including
> additional HTML attributes to be supported.  However, pardon my
> ignorance, but I
> don't see any mention of a "wrapping" attribute in HTML 4.0???
> 
> One particular area of enhancement focus will be the optional 
> ability to
> generate JavaScript functions for client side validation for 
> things like
> "required field" or "must be an integer".

I rather consider that NTH (nice to have) since I know people (like
myself) who usually switch off JavaScript while browsing. Its a 
security issue and commercial sites use it to generate annoying
pop ups. So I'd like to have client side form validations, since it
is convenient to the user, but I'd never rely my apps on it...

> > * Generally it looks like many HTML attributes are missing 
> from the taglib.
> 
> That problem can be easily addressed -- I wanted to get the basic
> framework
> working first.

That is true. 
Its also fairly tedious to make it all that complete, on the other
hand having it incomplete forces people to develop tags of their own,
only to reflect small extensions.

> > * Maybe it would be nice to have more control whether the 
> text is editable
> >   or read/only or not even viewed with custom tags. I.E. 
> with your user
> >   registration, I'd like to use the same bean and the same 
> jsp to register
> >   and edit my registration data, but in the latter case I 
> shouldn't be able
> >   to change my unique user id any more AND I DONT WANT TO 
> DO JAVA CODING IN
> >   IN MY JSP :-)
> 
> If it is editable, use this:
> 
>     <struts:text name="xyz"/>
> 
> if it is not editable, use this:
> 
>     <struts:property name="xyz"/>
> 
> If it needs to go back and forth (i.e. the "disabled" attribute on an
> input
> field), that will need to wait for an enhancement to the text tag.

One solution would be to augment the Servlet/JSP with a Hashtable which
contains additional information to a field (e.g. type and validation method,
visibility, changeability) on a per field basis. This should have a
reasonable
default, so that a missing entry in that table does "the usual" (probably
text 
field, non zero length required, appropriate JS validator, visible and
changeable).

> > * Having the System text properties in many languages would 
> be nice anyway.
> 
> Anyone willing to do the translations?  I would be happy to 
> check in the
> appropriate resource bundles for these!

If changes happen say weekly and we can set up the workflow I'll could
provide some German. Unless you need a fresh translation for every nightly
build.

> > * Isn't there some means to implement an "else" Tag to your 
> if tags (I know
> >   there are intrinsic problems with the Taglib-Syntax). 
> Would be so nice.
> >   Having "if a endif if not a endif" is a source of easy mistakes.
> 
> Offhand, I cannot think of a really elegant way to do this -- but I'm
> going to
> experiment with something like the following:
> 
>     <struts:ifCondition ...>
>         ...
>     </struts:ifCondition>
>     <struts:else>
>         ...
>     </struts:else>
> 
> where the "if" tag would remember the result of the last conditional
> evaluation
> somewhere internally, and the "else" tag could simply reverse that
> result.  Have
> to make sure this works with nested conditionals, too.  Does 
> that sound
> like a
> reasonable syntax?

Your syntax is ugly but OK, it's kind of a gap in taglibs IMHO :-)
A collegue has toyed with syntax like

<if>
	<then>
	</then>
	<elseif>
	</elseif>
	<else>
	</else>
</if>

which is also not bad. He never finished and I didn't want to start over. 
To make this really useful one had to have a framework, to allow all kinds 
of <if> to interact with each other as elseifs ...

> > * The locale/message support is very nice, but instead of hanging my
> > application
> >   with a NullPointerException, I'd like another behaviour 
> if an undefined
> >   text is requested: Write s.th. in the log file, and show 
> the Message id
> >   to the presenting tag/servlet. E.g. if a MessageTag requests
> > franks.cool.text,
> >   which is missing. Write a warning in a log file and return
> > de_DE:franks.cool.text
> >   to the application. This behaviour should be (maybe 
> switchable) at low
> > level
> >   in the application.
> 
> How about a reserved message key that is used whenever an 
> unknown key is
> requested?  That way, you can have your cool message, and I 
> can have my
> null
> return if I want :-).

Yes, I messed my weekend project up, when I decided to translate
on a "on demand" policy and realized that many pages just didn't
not appear due to missing message texts...

> > * Switching locales seems to be broken. I implemented an 
> Action to set the
> >   session locale to a certain value, but still get german 
> text unless it
> >   is missing and i get the english ones you provided.
> 
> I assume you actually have the appropriate German resource bundle as
> well,
> right?  I will look at that.

Actually it started up german with a few null's and some english
texts coming through (so I'm sure all resources are loaded). Without
looking at the source. Is the message caching done right? I did
a testoutpout of the locale itself to see I really toggled the 
application language, but got the same german messages all the time...

> > * Consider to have some classes (e.g. the Message 
> obtaining/caching) as
> >   singletons in JVM Space instead of Application space. I'd 
> rather like
> >   to have a MessageBundle.getInstance() anywhere in my 
> java, than to access
> >   the objects via requests, session and application 
> objects. Hmm at a second
> >   thought I am not convinced completely if this is a good 
> idea, but its
> >   an idea anyway.
> 
> Singletons in a servlet container environment are not portable.  Most
> servlet
> containers implement a custom class loader for each web application
> (some for
> each servlet) -- and statics are not shared across class 
> loaders.  That
> is why
> you are encouraged to use servlet context attributes (i.e. application
> scope
> beans in JSP) for information sharing within an app, and 
> external media
> (databases, directory servers, files, EJBs, ...) for sharing between
> applications.

Ooops, in that case I had to rethink some of my application designs. 

> Think about the implications if sharing across apps really was allowed
> -- do you
> *really* want some other web app running in the same container to be
> able to
> scribble on your critical global variables?  We might as well 
> go back to
> COMMON
> blocks in Fortran :-).

No, no, but when I cache messages on a certain level, I wouldn't be unhappy
if different applications would use the same cache over and over. I know you
had to make that smart, so you don't have to block various threads, on the
other hand I would like to avoid to catch the same text multiple time from
disk again and again and hold mutliple times in my memory. Most of the
accessore interfaces I use are kind of read only, so this its much better
than COMMON blocks :-)

> > * Consider having a tag for a jsp to check weather it is 
> accessed directly
> > or
> >   via the controler servlet, forwarding the request to some 
> neutral page in
> > the
> >   prior case.
> 
> It would not be tough to do this -- simply check the request URI (on a
> forward,
> it wil still be the original URI pointing at the controller servlet).
> You would
> have to know what <servlet-mapping> pattern you are using for the
> controller
> servlet to make the decision, but that seems possible.

What I did is having a application tag, checking a certain request attribute
to be not null, this has to be preset by the servlet. I just argue, this
should be in the basic system.

> A similar "nice to have" would be a tag to check for the 
> existence of a
> particular session attribute, and forward if it is missing.  
> That would
> be
> useful for checking whether the user is currently logged in or not.

I've seen your example application and would vote for having logging
in support moved in the basic product...

> > Even nice would be if sun would allow some fixed
> > initialization
> >   code for a JSP, when a taglib is requested by it, but I 
> don't know where
> > to
> >   send that idea. Second thinging shows: A taglib would 
> then need to have
> >   an initialization at JVM, Server, Application, Session, 
> Request and Page
> > scope
> >   :-)
> 
> Ideas for improving the specs should go to the feedback EMAIL 
> addresses
> on the
> front covers.  In the case at hand:
> 
>     servletapi-feedback@eng.sun.com
> 
>     jsp-spec-comments@eng.sun.com
> 
> depending on whether its a servlet thing or a JSP thing.
> 
> What I do for initialization is to use a startup servlet, which will
> create and
> configure the objects I need, and store them in the servlet context
> attributes
> (for example, the MessageResources bundle).  The custom tag 
> instance has
> access
> to this (through the PageContext), so it is quite reasonable.  Because
> tag
> instances get created quite often (they are not accessed in a
> multithreaded
> manner like servlets are), I would not want to do a lot of 
> heavy lifting
> at
> every tag instance creation.

The efficiency would be matter of design. But if I had "on usage" startup
code for a taglib I could check various assertions (e.g. controller servlet
run, user logged in) beforehand and rely on that at every place in the 
taglib.

> > * Customization of process method is a lot of work to do, 
> like starting from
> >
> >   scratch. Couldn't be that more modularized so that I can 
> restrict myself
> > to
> >   the essential coding (I started programming s.th. like 
> having a process
> >   function which essentially returns the JSP URI, not caring about
> > initialization
> >   and forwarding, when I realized it pulled me away from 
> the application I
> >   need to program and might be different with the next 
> struts-edition...)
> 
> Are you speaking of the process() method in ActionServlet?  If so, the
> easiest
> way to customize the behavior would be to subclass ActionServlet and
> just
> override that method.  If you just want to do some special logic first
> and then
> do the standard logic, it's pretty easy:
> 
>     protected void process(HttpServletRequest request,
>         HttpServletResponse response)
>         throws IOException, ServletException {
> 
>         ... do something special here ...
>         ... if it falls through, use the standard logic ...
> 
>         super.process(request, response);
> 
>     }
> 
> Or, you can replace the entire process() method with your own 
> handling.
> Of
> course, my assumption is that you wouldn't have bothered using
> ActionServlet in
> the first place if you didn't want what the process() method does for
> you, like
> automatic handling of the form bean :-).

I still love the basic idea, but there is still a lot redundancy:
The JSP contain links which are not controlled by the servlet, the
servlet loads a bean on startup, the JSP needs the same useBean again.

I'd like the JSPs even more dumb (why do i need the useBean tag, when the
servlet could have preset everything for the page), why do I have to
handcode correct links in my JSPs when I just put all the links
really mattering to the application in the action.xml. I do a lot
of mistakes and spend much time crafting tools to avoid my mistakes :-)
There are IMHO to many informations to be kept consistant in two 
places.

Or to put it different, an application can be seen as a graph: Pages
interconnected by directed links. And its all clear that XML is 
completely appropriate to set down the whole graph plus a characterisation
of the nodes. Struts currently mainly describes the nodes, though in
your example you started with putting graph information in the XML.

> >   Together with the idea of self validating FormBeans 
> (having a own validate
> >   method it should be possible to obtain very short process 
> methods for many
> >   standard cases.
> 
> As mentioned above, I'd like to see the ability to optionally create
> client-side
> validations in JavaScript as well.

IMHO NTH :-)

> Self-validating form beans sound cool at first blush, but consider one
> issue
> about the process flow -- one of the roles of the form bean 
> itself is to
> faithfully represent the last set of input fields that the 
> user entered
> (whether
> the whole transaction is semantically valid or not).  If the setter
> methods in
> your form bean, for example, were to through 
> IllegalArgumentException on
> invalid
> values, your form bean would not be completely up to date -- so that
> when you
> redisplayed the the form to the user again, it wouldn't show the bad
> value that
> he/she actually entered.
> 
> I would suggest that validation be done either in the action class
> itself, or in
> the "data access layer" bean or EJB that actually represents your
> business
> objects.

Not sure if we are thinking about the same thing, I liked the approach
in the "Advanced form processing using JSP" artivle by Govind Seshadri on
JavaWorld. Extending that idea every FormBean should be required to have 
a validate() method which returns a data structure (Hashtable) about postion

and type of error...

> > * What I really liked would be to have the whole 
> application abstract
> > automaton
> >   layed out in the action.xml, e.g. there should be a 
> mechanism to reference
> > a
> >   link just by name (from a Hashtable instead of the getSuccess(),
> > getFailure()
> >   thingie) and a custom tag for the JSP which is s.th. like 
> a inner link and
> >   does not even contain a HREF but rather a NAME of a link 
> from the recent
> >   action.xml. Currently certain links are both in the 
> action.xml and in the
> >   JSP source code.
> >   I fear, to imlement this one had to change quite a lot 
> from the struts
> >   framework, keeping rather the spirit than the mechanics.
> >
> 
> Can you do what you want by extending the ActionMapping implementation
> class
> with additional properties?  After all, the "success" and "failure"
> properties
> are not part of the standard action class -- they are 
> extensions defined
> by the
> example application.  There is no limit to the number of such 
> properties
> you can
> add (although there is no current support for an "array" or 
> "hashtable"
> type
> approach).  I'd have to think about how you could initialize 
> such things
> in a
> generic way -- perhaps with some sort of element nested inside an
> <action>.

Yes, I'd like to have a sublement to every ActionMapping
	<links>
		<basiclink>name</basiclink>
		<link id="success">name</link>
		<link id="failure">name</link>	
		... more links ...
	<links>
The basic link is kind of a fallback, when anything happens, go to the
basic link, could be an error page.

> > * Give me an easy slot to plug in a XSLT Transform engine 
> (not necessarily
> > cocoon,
> >   but at least some XSL postprocessing, like piping output 
> once through an
> >   choosen XSL)
> >
> > Well, maybe it is a different project, but then it had to 
> copy a lot of code
> > from struts :-)
> >
> 
> Hey, this project is "Struts", not "Kitchen Sink" :-).

It's jsut that I found many interesting ideas, lots of allready working
code but doubt if the changes i think of are still within the range of
an design on basis of struts framework or are s.th. different.

Well, btw for me as a German struts had no meaning, it was just the
name of your project until I looked in the dictionary and finally 
realized that the same thing like the \strut in TeX :-)

> Actually, plugging in an XSLT transform is really a servlet container
> level
> issue.  In fact, some mechanism for defining portable filtering
> (including XSLT
> transformations) at the container level is being discussed in the next
> spec rev.
> 
> In the mean time, I'm planning to let you incorporate some sort of
> filtering
> with a Struts tag like this:
> 
>     <struts:xsl stylesheet="xyz.xsl">
>         ... the body of your JSP page which ...
>         ... now renders XML not HTML ...
>     </struts:xsl>
> 
> based on the "xsl" taglib in the jakarta-taglibs project at
> <http://jakarta.apache.org>.

Last time I've been there, it was all empty. I have to look!

> Simply continue throwing out good ideas (on the STRUTS-DEV mailling
> list) and
> you'll make my day.  I want to start bouncing approaches off the
> developer's
> list before implementing them.  Of course, specific code contributions
> are
> always welcome too, but they are not required.

Good.

I still don't like the fact, that I have to stop and restart server to get
all applications parameters set. Using Resin as a development container, I
simply used to edit my java sources, container configuration, web.xml and
Resin reread and reinitialiuzed all apropriately. I'd like to see that with
Struts, having a low priority 2s Thread to watch all configuration files and
reread them if necessary. Of course set up had to be rewritten in a way that
it can be repeated at any time without messing up the system.

Re: ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: NewJAKARTA-STRUTSSubproject)

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

On Wed, 14 Jun 2000, Craig R. McClanahan wrote:

> "Craig R. McClanahan" wrote:

> I had forgotten that the <struts:errors> tag expects a String array
> of message keys, not actual message text.  Therefore, the validate()
> method should return String[] instead of String, and it doesn't need
> any arguments -- the internationalization stuff is handled within
> the errors tag.

Actually, I think the way you said it first was right.  The localized
message gets inserted in the array, not the message key.  For example,
in struts-example's LogonAction:

  if (user == null)
      errors.addElement(messages.getMessage(locale,
		        "error.password.mismatch"));

Although, I think I would like putting the error key in the array
instead.

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI

Re: ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: NewJAKARTA-STRUTSSubproject)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Craig R. McClanahan" wrote:

> I agree with what to do with the result.  My only nit-pick is that I don't see the
> need for a String[] response.  If you are returning HTML that you want to have
> pretty-printed (if someone does a "view source"), you can always insert your own
> \r and \n characters.
>

Never mind.

I had forgotten that the <struts:errors> tag expects a String array of message keys,
not actual message text.  Therefore, the validate() method should return String[]
instead of String, and it doesn't need any arguments -- the internationalization stuff
is handled within the errors tag.

>
> Which of course means that the <struts:errors> tag should handle a single string
> attribute also ... I will fix that.
>

Just fixed this as well.  If you only have a single error, you can now save that as
the request attribute -- you don't have to package it as a String array if you don't
want to.

Craig

Re: ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: NewJAKARTA-STRUTSSubproject)

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Hutchison, Jeff" wrote:

> On Wed, 14 Jun 2000, Craig R. McClanahan wrote:
>
> > "Hutchison, Jeff" wrote:
> >
> > > [snip]
> > > I agree, self-validating beans do sound cool.  I think the validate()
> > > approach mentioned by Frank might be useful.  I'm reminded of two
> > > different types of validation that Brett McLaughlin mentioned in a
> > > presentation I saw at the O'Reilly Java conference earlier this year.
> > >
> >
> > As long as you call the validate() method *after* all the property setters,
> > I'm fine with this.  That way, the form bean still faithfully represents the
> > state of all the user input fields when you redisplay.
>
> As long as you don't mess with the ActionServlet, you'll always satisfy
> this contract, right?  If someone needs to override some default
> controller behavior, they'll need to understand this.  Would it make sense
> to utilize the GoF Template design pattern and build some hooks into the
> process() method?  This might be a way to plug in some custom behavior
> (like maybe authentication checking) while still enforcing basic
> contractual stuff that the framework depends on (like all setters called
> before validate).  Not sure if there are many interesting use cases for
> this, just thinking out loud while our latitude for change is still
> (relatively) large.
>

Sounds like it might be a reasonable thing to look at.  A very simple approach
might be to define "preprocess()" and "postprocess()" methods that are called
before and after "process()", and let you override these in a subclass.

Of course, there's always overriding process() itself, like this:

    public void process(.....) ... {

        ... do the "before" stuff ...
        super.process(request, response);
        ... do the "after" stuff ...

    }

which works just as well.  The only time this simple approach doesn't work is when
you want to intersperse your special processing code in between some of the things
that ActionServlet.process() normally does.

>
> > There are going to be cases where validation like this is not necessary.
> > How about if we have a new interface (ValidatingFormBean) that extends
> > FormBean?  Then, the controller servlet can do an "instanceof" check to see
> > if this behavior is required.
> >
> > Returning the error messages that describe the problems has one interesting
> > wrinkle in internationalized applications -- what language do you use?  To
> > make this decision properly, the validate() method would need to know the
> > current user's Locale and have access to an appropriate ResourceBundle or
> > MessageResources object to grab the messages from.
>
> > Given all of this, how about the following method signature:
> >
> >     public String validate(Locale locale, MessageResources resources);
> >
> > which would return a String containing the HTML (presumably) text you want
> > to display with the errors in it, or null if there were no errors.  The
> > controller servlet would call this method if it exists on the current form
> > bean, and if it got a non-null resource you would save a request attribute
> > and forward control to a JSP page identified in the mapping -- presumably
> > the name of the input form page (we'd need to add this as a standard mapping
> > property).
>
> How about returning String[] and having the controlling servlet save
> it as a the Action.ERROR_KEY request attribute?  That way the standard
> "errors" custom tag can be used to display the validation errors.
>

I agree with what to do with the result.  My only nit-pick is that I don't see the
need for a String[] response.  If you are returning HTML that you want to have
pretty-printed (if someone does a "view source"), you can always insert your own
\r and \n characters.

Which of course means that the <struts:errors> tag should handle a single string
attribute also ... I will fix that.

>
> >
> > Does that sound like a reasonable approach?
>
> Yes.  Once the dust settles on the approach, I'd be eager to take a
> swipe at it.
>
> --
> Jeff Hutchison <jh...@inst.strykercorp.com>
> Stryker Instruments Kalamazoo, MI

Craig

ValidatingFormBean (Was: Re: AW: AW: ANNOUNCEMENT: New JAKARTA-STRUTSSubproject)

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

On Wed, 14 Jun 2000, Craig R. McClanahan wrote:

> "Hutchison, Jeff" wrote:
> 
> > [snip]
> > I agree, self-validating beans do sound cool.  I think the validate()
> > approach mentioned by Frank might be useful.  I'm reminded of two
> > different types of validation that Brett McLaughlin mentioned in a
> > presentation I saw at the O'Reilly Java conference earlier this year.
> >
> 
> As long as you call the validate() method *after* all the property setters,
> I'm fine with this.  That way, the form bean still faithfully represents the
> state of all the user input fields when you redisplay.

As long as you don't mess with the ActionServlet, you'll always satisfy
this contract, right?  If someone needs to override some default
controller behavior, they'll need to understand this.  Would it make sense
to utilize the GoF Template design pattern and build some hooks into the
process() method?  This might be a way to plug in some custom behavior
(like maybe authentication checking) while still enforcing basic
contractual stuff that the framework depends on (like all setters called
before validate).  Not sure if there are many interesting use cases for
this, just thinking out loud while our latitude for change is still
(relatively) large.
 
> There are going to be cases where validation like this is not necessary.
> How about if we have a new interface (ValidatingFormBean) that extends
> FormBean?  Then, the controller servlet can do an "instanceof" check to see
> if this behavior is required.
> 
> Returning the error messages that describe the problems has one interesting
> wrinkle in internationalized applications -- what language do you use?  To
> make this decision properly, the validate() method would need to know the
> current user's Locale and have access to an appropriate ResourceBundle or
> MessageResources object to grab the messages from.

> Given all of this, how about the following method signature:
> 
>     public String validate(Locale locale, MessageResources resources);
> 
> which would return a String containing the HTML (presumably) text you want
> to display with the errors in it, or null if there were no errors.  The
> controller servlet would call this method if it exists on the current form
> bean, and if it got a non-null resource you would save a request attribute
> and forward control to a JSP page identified in the mapping -- presumably
> the name of the input form page (we'd need to add this as a standard mapping
> property).

How about returning String[] and having the controlling servlet save
it as a the Action.ERROR_KEY request attribute?  That way the standard
"errors" custom tag can be used to display the validation errors.

> 
> Does that sound like a reasonable approach?

Yes.  Once the dust settles on the approach, I'd be eager to take a
swipe at it.

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI

Re: AW: AW: ANNOUNCEMENT: New JAKARTA-STRUTS Subproject

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Hutchison, Jeff" wrote:

> [snip]
> I agree, self-validating beans do sound cool.  I think the validate()
> approach mentioned by Frank might be useful.  I'm reminded of two
> different types of validation that Brett McLaughlin mentioned in a
> presentation I saw at the O'Reilly Java conference earlier this year.
>

As long as you call the validate() method *after* all the property setters,
I'm fine with this.  That way, the form bean still faithfully represents the
state of all the user input fields when you redisplay.

There are going to be cases where validation like this is not necessary.
How about if we have a new interface (ValidatingFormBean) that extends
FormBean?  Then, the controller servlet can do an "instanceof" check to see
if this behavior is required.

Returning the error messages that describe the problems has one interesting
wrinkle in internationalized applications -- what language do you use?  To
make this decision properly, the validate() method would need to know the
current user's Locale and have access to an appropriate ResourceBundle or
MessageResources object to grab the messages from.

Given all of this, how about the following method signature:

    public String validate(Locale locale, MessageResources resources);

which would return a String containing the HTML (presumably) text you want
to display with the errors in it, or null if there were no errors.  The
controller servlet would call this method if it exists on the current form
bean, and if it got a non-null resource you would save a request attribute
and forward control to a JSP page identified in the mapping -- presumably
the name of the input form page (we'd need to add this as a standard mapping
property).

Does that sound like a reasonable approach?

Craig

Re: AW: AW: ANNOUNCEMENT: New JAKARTA-STRUTS Subproject

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

I'm extracting a portion of this from a long message posted to
struts-user because I wanted to comment on the development of the
FormBeans.

McClanahan, Craig wrote (I think):

> > Self-validating form beans sound cool at first blush, but consider
> > one issue about the process flow -- one of the roles of the form
> > bean itself is to faithfully represent the last set of input
> > fields that the user entered (whether the whole transaction is
> > semantically valid or not).  If the setter methods in your form
> > bean, for example, were to through IllegalArgumentException on
> > invalid values, your form bean would not be completely up to date
> > -- so that when you redisplayed the the form to the user again, it
> > wouldn't show the bad value that he/she actually entered.
> > I would suggest that validation be done either in the action class
> > itself, or in the "data access layer" bean or EJB that actually
> > represents your business objects.

Nestel, Frank wrote:
 
> Not sure if we are thinking about the same thing, I liked the
> approach in the "Advanced form processing using JSP" artivle by
> Govind Seshadri on JavaWorld. Extending that idea every FormBean
> should be required to have a validate() method which returns a data
> structure (Hashtable) about postion and type of error...

I agree, self-validating beans do sound cool.  I think the validate()
approach mentioned by Frank might be useful.  I'm reminded of two
different types of validation that Brett McLaughlin mentioned in a
presentation I saw at the O'Reilly Java conference earlier this year.

Coarse Grained Validation - generic validation of data types: required,
numeric, date, phone, email, etc...  This might be appropriate for
validation within either the browser (using JavaScript) or in a FormBean
validate() method.  For the validate() approach, each setter can
optionally call a superclass addValidationError() method, and the
validate() method can check to see if any errors were added and return a
boolean signalling success or failure.

Fine Grained Validation - very specific validation of business rules:
probably best done in the data access layer.

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI