Ted Husted wrote:
> Using the same element name more than once is really only the tip of the iceberg. We
>can also delete or rename a
> form bean from the file and Struts will not catch the problem until runtime.
Not in my system! :) XDoclet to the rescue. Form bean definitions are
generated completely - move a class to a different package, delete it,
rename it, no problem.
> Heck, we can set validate to true
> and omit the input property and not catch the problem until validate actually fails.
Now this is a problem.
> Or now specify an input
> forward that doesn't exist.
Again, a problem.
> We can also specify entries from the Application Resources that don't exist
Using my DbResources, this is not a "problem" per se. No crash, only
the resource string returned is the config/locale/key combination
requested giving a very visual indication that something is missing.
>, or ask
> Actions to find forwards that can't be found.
Again, a problem. And this one could be very tough to find with a tool,
but Cactus tests (using StrutsTestCase) find these easily.
> Forms can specify formbean properties that don't exist,
True. But we have a starter JSP generator that generates the fields
from a form bean using XDoclet. So that issue doesn't crop up until we
add a field later, but the problem is minimized.
> ActionMappings can specify classes that don't exist, and so on.
XDoclet *could* take care of this, but I choose not to codify action
mappings with @tags, but do it separately.
> I agree that it would be a Good Thing if someone were to write a utility that vetted
>the configuration to be
> sure all the references resolved, but doing a proper job with something like this
>sounds like a task for 1.1+.
If we ever got into a situation where these problems cropped up often,
I'd build something to catch them, but I've not found these to be much
of a problem using XDoclet for some of the dirty work, as well as other
tricks.
Erik
p.s. on the topic of Validator - its working nicely for us. We end up
writing some custom validations, but for the most part we've not had any
problems with it. I saw earlier that the DTD issue I encountered has
been fixed - but I worked around it with XDoclet's generation of
validation.xml by omitting the DTD from the output.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
