Erik, If you'd like to write a section for the UserGuide on using XDoclet with Struts, I'm sure we'd all love to read it =:0)
-Ted. 10/16/2002 8:00:00 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote: >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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
