On Wed, 10 Nov 2004 00:46:26 +0000, Adam Hardy <[EMAIL PROTECTED]> wrote: > On 11/09/2004 11:30 PM Joe Germuska wrote: > > > > I obviously have an affinity for the way we do it here (something I > > elaborated about in more detail in this list post: > > http://article.gmane.org/gmane.comp.jakarta.struts.devel/22034) but I > > would be happy to adjust my ideas if we got anything approaching a > > consensus from list members. I'm looking for more clear buy-in from > > folks before I try to forge out and code anything around this. My point > > being that even in a Struts 1.x timeframe, this could be easier. Maybe > > this really doesn't bother anyone but me -- sometimes I get that feeling! > > I can only say I prefer the post-redirect-get mechanism. It doesn't > worry me at all that it generates another round-trip for the user, > unless they were on 56K connections. But even then, the round-trip is > brief and lightweight.
That, of course, depends on the weight of the response, and the capacity of your network infrastructure to set up and tear down double the number of TCP connections (if you're not using persistent HTTP/1.1 connections). > > I think the learning curve for struts is already humungous! Wouldn't the > addition of a command-chain or a renderer steepen it further? So let's simplify it with Shale first :-). Seriously ... a chain of responsibility pattern would still fit in quite well in a couple of places in Shale: * Application wide per-request processing like authenticaiton (think about it ... servlet filters *implement* the chain of responsibility pattern already :-). * Delegation from an action event handler to a chain that defines the business logic to be performed. > Adam Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
