Very nice example and analysis from Peter Pilgrim
> -----Original Message----- > From: Pilgrim, Peter [mailto:[EMAIL PROTECTED] > Sent: 17 December 2004 10:59 > To: 'Struts Developers List' > Subject: RE: Commons Chain Cookbook: Why have Struts Actions? > > > > > > -----Original Message----- > > From: BaTien Duong [mailto:[EMAIL PROTECTED] > ==////== > > > > > > Ted Husted wrote: > > > > >On Wed, 15 Dec 2004 17:22:15 +0000, Pilgrim, Peter wrote: > > > > > > > > >> I was thinking in truth, only providing access to the ``catalog'' > > >> and ``command'' not necessarily changing the execution model. But > > >> if that is the case, could a Struts ``Action'' as it appears in > > >> 1.2.6 actually be a commons chain `Command' type? If it is, then, > > >> it opens the doors for the ``chaining action'' conundrum all again. > > >> > > >> > > >> > > > > > >It's my own feeling that there should be a clean break > > between the presentation layer (Struts) that collects and > > display values, and the business logic layer (e.g. Chain) > > that should do everything else. > > > > > >I started a new project this week based on Context, Command, > > and (as of five minutes ago) Spring. The paradigm is that the > > presentation layer collects whatever values are needed and > > puts them into a Context. A controller component executes the > > associated Command (or Chain) and returns the outcome in the > > Context. Both the Context and Command are extended so that > > they can handle all the business processing: Input and Output > > Validation, Execution, Error and Exception Handling, and > > Message Resolution. > > > > > >For input, the Context has convenience properties for > > Locale, User, Role, and for output, there are properties for > > Output, Errors, Messages, and Fault (Exception). I expect > > there to be more, but I'm only adding what I need when I need it. > > > > > >When the Context returns, it can be examined by the > > presentation layer, which can then display the output, > > messages, or errors. > > When I reread this note, it occurred to me that this is > similar to the way Expresso Controllers are implemented, > except the ``Context'' is split into ``ControllerRequest'' > and ``ControllerResponse''. The design was inspired by the > Java Servlet API specification `ServletRequest', > `ServletResponse'. > > So I'd agree with this `bigger' all-seeing-context design > in principle. I'd factor out some interfaces for Struts > web environment so that people in theory could re-sig > the implementation. > > Can a ``Context'' ever be too big? I mean, everytime a > web user hits a submit then a naive implementation would > create a big context object with a request, response, > errors, etc. What if an naive Struts 1.3+ developer did this > in his or her `FooCommandAction' for every web request > > class FooCommandAction { > public Context createKiddieOnContext() { > ... > > PhotoImage image = new PhotoImage( 2048, 2048 ); // > 4Mega Pixel > grabPhotoFromPersistence( "mallorca0001.jpg", image ) > context.put( "myPhoto", image ); > ... > return context; > } > > } > > > > > > > > > > > > This is great Ted. What it means is that each individual backend > > software component catalog can determine finer grain of authorization > > and the amount of supplied information. The web layer will > > take care of > > the first pass and assemble the supplied fragments. Please > > let all the > > mortals know when it is available. > > > > This is C#, so I think he'd have to port it to Java first. > > > Thanks > > > > BaTien > > DBGROUPS > > > > >It's all in C# now, since I'm working in .NET, but I'd like > > to port it back to Java 1.5 and maybe PHP 5. > > > > > >-Ted. > > > > > > > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > -- > Peter Pilgrim > Operations/IT - Credit Suisse First Boston, > 10 South Colonnade, London E14 4QJ, United Kingdom > Tel: +44-(0)207-883-4497 > > ================================================================== > ============ > This message is for the sole use of the intended recipient. If > you received > this message in error please delete it and notify us. If this message was > misdirected, CSFB does not waive any confidentiality or privilege. CSFB > retains and monitors electronic communications sent through its network. > Instructions transmitted over this system are not binding on CSFB > until they > are confirmed by us. Message transmission is not guaranteed to be secure. > ================================================================== > ============ > > > --------------------------------------------------------------------- > 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]
