> I now uses mod_perl with a specialized handler. The path decides the > template and the action is specified by the 'run' key in the POST or > QUERY string. The result from the action is sent as extra data to the > template and can be viewd there.
Right, that's what I want, and Apache::Template doesn't work this way. You can only add an action by subclassing Template::Service::Apache and overriding the params() method. > I have chosen to let a failure of an > action to result in that the previous page is redisplayed. That's > what usually is needed to bring back the same forms so that the user > can try to do something else. (The mod_perl handler redirects the > browser to the right page.) Yes, the application logic gets to decide on the view that should be used. It's not as simple as "always use the file from the URI". > Eh... What I wanted to say was that I think it keeps the application > logic separate. And the handler actually require() the requested > action handler and then loades the template specified by the path > unless one of the action funktions decides to redirect the browser. I think we're in complete agreement about how it should work. Apache::Template isn't quite there yet. I should probably just shut up about this, because I find it easy enough to write a custom mod_perl handler that does what I need. The code for integrating with TT is typically only a couple of lines, just like the stuff in the tutorial. My only concern is that I don't want people to think they need to use Apache::Template if they're using TT with mod_perl. - Perrin
