On Mon, 24 Jan 2005 10:24:56 -0800 (PST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I thought of something similar too Jim, but my thought was that now they are > coding classes that don't truly adere to the general form of an Action. I > would rather have the basic structure remain the same and just make them have > to remember to call the setup code.
If you have to revert back to a standard action, just rename the method call, it shoudl be the exact same format as the original execute. > > Think of it this way... the more a team veers from "standard" Struts (or > standard anything for that matter!), the more a new team member has to learn > and comprehend before they can really be effective. In my mind, a single > method call that someone has to remember is better with the idea of swappable > human resources in mind than having to learn and understand a new structure > for an Action (even if it is very simple, as what you show is). Except that a newbie is less likely to remember exceptions like this action has to call a special method first. If a newbie tries to inherit from the final execute, he gets an error, goes to investigate and goes oh.. okay. > > I suppose we could have the best of both worlds if you implement a custom > RequestProcessor that looks for some flag attribute in request that is only > set from the setup code and redirects to some error page if it's not set. > That way, the Actions can remain structured as usual, and if a developer > forgets that setup call, they'll know about it right away. > > But then, that starts to feel like babysitting my developers, and I for one > don't do that. I hire those that I have confidence in, and I let them do > their thing based on my architectural blueprints. I trust them to get it > right, or at least quickly and efficiently fix it if they don't! :) I trust them to.... I just excpect them to be human. In addition the less "extra" stuff they have to remember, the fewer mistakes they can make. If you see code where ti spends most of it's time figuring out exceptions then it does doing work, you probably immediately think "Time to refactor". Same thing with processes we have to use when coding. The fewer "exceptions" I have to think about, the better. In my suggestion, the programmer can forget about what they have to call and the langauge takes care of larting them if they forgeet, and telling them how to fix before they even run a unit test. As for using a custom request processer, that's further afield from standard struts then my suggestion. You could use a filter for the same thing, and not have to worry about what happens when you upgrade struts. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Mon, January 24, 2005 1:15 pm, Jim Barrows said: > > On Mon, 24 Jan 2005 10:05:08 -0800 (PST), [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > >> > >> On Mon, January 24, 2005 12:37 pm, Gianpiero Caretti said: > >> > FYI, that's exactly what I am doing rigth now! > >> > >> Great minds think alike :) > >> > >> > The only think I don't like with this solution is that the JSP writer > >> has > >> > to > >> > know the existence of the "command" attribute into request. Moreover > >> if > >> > the > >> > Action writer forgot to call the "setup" method the request attribute > >> will > >> > not > >> > set. > >> > >> True enough, but at some point you have to trust those under you. So > >> long as you make this information known, you have to trust that they > >> will use it. > > > > If they remember, don't get in a hurry or otherwise do something human. > > Why not do something like > > private static blah execute(blah) throws Exception { > > criticalSetupstuff; > > continueExecute(blah); > > } > > protected blah continueExecute(bladh) throws Exception { > > whatever the execute should do. > > } > > > > That way you can gurantee that anyone inheriting from this action will > > get the crttical setup stuff. > > > >> > >> -- > >> Frank W. Zammetti > >> Founder and Chief Software Architect > >> Omnytex Technologies > >> http://www.omnytex.com > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
