On Fri, March 18, 2005 11:09 am, Rick Reumann said: > Ok, not going down that road..<cough>wacko</cough>:)
<Insert comment about sausages and starving dogs here> > But seriously > though, you said you had about 2000 lines of code between your > ActionForms. How much time do you think it takes you type out all those > getters and setters for all those properties? Me persnoally? At one point in time, and it might still stand, I don't know, I had the record in the Army for typing speed. I'm pretty quick :) > No way, you can tell me > that autogeneration of those set/get methods wouldn't save you time and > we all know time==money. Granted. But I'm an old-school guys... I like knowing precisely where every piece of code in my application came from, how it works, and so forth. This means I like to write it all. I already have to give up a lot just by using Java, an app server, a framework, heck, even an operating system and BIOS and CPU microcode I suppose! :) Ok, NOW you can call me a wacko! :) More importantly though, I'd have to leave UltraEdit to get that capability, and that move I have found costs me more productivity than any I might be able to gain in another environment. My experience has been that IDEs (where auto-generation tends to be done) slows me down more than any gains it gives me. Clearly this is not typical, but it is true for me. (I should point out though that a class with pretty much nothing but getters and setters is NOT the case I would choose to argue against code generation in general :) This is a case I actually could live with it) > But I know, there won't be any convincing you > otherwise:) Hey, it wouldn't be me if I wasn't stubborn! :) Seriously though, when I feel passionately about something, I will argue until I'm blue in the face, but rest assured I will always listen, consider what others say and allow myself to be convinced when I believe warranted. I'm not closed-minded, but I am stubborn and perhaps slow to change sometimes :) > "An alternative approach is to use the action mapping path attribute. In > this case, you extend the ValidatorActionForm instead of the > ValidatorForm. The ValidatorActionForm uses the action element's path > attribute from the Struts configuration which should match the form > element's name attribute in the Validator configuration. > > Then a separate action mapping can be defined for each page in a > multi-page form, and the validation form can be associated with the > action rather than a page number (as shown in the example of a > multi-page form in the validator example)." Well, thank you for that. I have to admit this is new to me. I'll have to go do some reading. > Well, actually I like to have my own validate() method in each of my > Dispatch Actions. I don't like having the framework call validate for > me. One of the main reason is that if I'm in my action and I manually > call my own action's validate() method then, if validation fails, I can > make sure my prep method is always called. I wrote about this here > http://reumann.net/struts/articles/request_lists.jsp and at the end I > give an example of what I like to do. (I'm curious, in that approach you > came up with, if validation were to fail, would the extra 'setup' that > you added to the action mapping be called? If so, that would be very > nice! if not then I'd still end up having to use my prep/set up method). I was doing that same thing for a while too. It does make sense. The arguments against it of course get in to what is proper separation of the layers and all that jazz. Good question about what happens with setupItems when validation fails... I didn't think of that situation when I did it... Looking at the code, NONE of the setupItems would be executed when a validation failure occurs. I could move the code that does the mapping-level items up before the validation is called and that would allow those to fire regardless. In fact, I think that would be the only real answer because obviously the forward-level items wouldn't come in to play when a validation failure occurs. Good point for sure though. :) > Rick Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
