> However, everyone who responds to me asks me why I don't want to > return some output, so I am clearly expressing myself badly.
Just a little note in the fray. I hear you Elizabeth, and I understand what you're saying. You're not crazy. :-) > We readily admit that there is more than one way to skin a cat, > but would still like someone to comment on this particular method of skinning. It's late, so I hope that'll keep me from a laboriously longwinded reply. :-) The idea of separating an action from the resultant output is a known pattern. Struts (jakarta.apache.org/struts) does this - every 'action' just does it's thing, adds stuff to a data context, and returns a 'result' which maps in the config to either another 'action' or a 'view' component. Another MVC framework, Turbine (jakarta.apache.org/turbine), calls their version of this 'pipelining'. And there are a half dozen other Java servlet based frameworks I know of with similar features. I came up with this concrete example for 'rm->rm->output' : A product edit form calls rm-SaveData to save stuff -> then needs to display a product menu (rm=Menu) rm(SaveData)->rm(ProductMenu)->output(ProductMenu w/ standard leftnav) SaveData doesn't know where it's going next. Lemme repeat that, there is no decision tree there. Yes the decision is made _somewhere_, as Jesse said. However, the knowledge of app-flow stays out of individual runmodes and in a central config. SaveData just knows how to save stuff and then "succeeds" or "fails". On success, SaveData chains into the ProductMenu rm which gets products from the DB, and produces output. On failure, SaveData chains somewhere else, perhaps back to EditData. SaveData doesn't have to know anything about how a ProductMenu is created. ProductMenu handles it's job and doesn't know about SaveMenu... except perhaps indirectly by displaying "MESG" if one exists in the Template Hash that says "Confirmed - we saved those product changes." I think the big paradigm hurdle for me was the non-persistent CGI process (sans MOD_PERL of course). In that world which most of us know well, I think it's a bit dogmatic that we think 1:1 CGI to web page output. CGI springs into existence...does it's stuff...and then sends output. But in the persistent process world (aka MOD_PERL or java Servlets), chaining from one application into another application while maintaining all your variables, is normal stuff. The process stays alive, and so there's no penalty for bouncing from one action to another action before writing output. The app can undergo specialization and doesn't have to do it all anymore. Indeed, in the examples above, some of the 'view' components truly do only that. This isn't meant to start a Perl v.s. Java flame... I've put into production both sub-classed CGI::Application apps (good stuff!) as well as Servlet apps. My point is just show that Elizabeth's point of view I believe does have some merit and is similar to other like-minded folks .... and isn't completely zany. <grin> Cheers, Timo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
