On 9/29/05, David Baird <[EMAIL PROTECTED]> wrote: > On 9/29/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > > David Baird wrote: > > > my general point still stands, that internal_redirect (which I'm only > > > using as an example, not as the motivation) needs to know whether > > > we're before, during, or after handler_guts(), > > > > I still don't see this. Can you give an example of a need to redirect > > before handler_guts? How about one that occurs after? I've got a mental > > block about what we're trying to achieve.
I don't see any more benefit in redirecting after handler_guts than before, I know that in Apache you can redirect internally at any point in any phase of the transaction and this would be a good thing to replicate. > Um, before handler_guts(), no, I guess not. Afterwards depends on if > we want to rearrange the sequence. I think that processing the view > shouldn't happen inside handler_guts. That's a significant barrier to > comprehension, especially if we're talking about re-running > handler_guts. So I'd like to move the view and its exception handling > out of handler_guts. You might want to issue an internal_redirect > after catching a view error. I would like to see the handling of the request split into seperate parts, each with hooks along the lines of mod_perl. This would make it far clearer and easier. > > > At the moment, if you want to cut short processing, set a return code, > > > and send that to the browser, you have to dig around in handler() and > > > handler_guts() and figure out what return code you need to return, > > > from what point in the processing, in order to persuade Maypole to > > > immediately return from handler(). I'd prefer to have an explicit API > > > for that. Then I don't need to figure out how to skip stuff - the > > > whole workflow proceeds, start to finish, skipping the unnecessary > > > bits, and we have a single point where the handler returns from. > > > > I think I agree with you, but are we talking at too low a level? Isn't > > what we're saying that we want two new 'APIs' (i.e. methods rather than > > flags)? Something like: > > > > $r->internal_redirect(some parameters) > > [Peter Speltz and others probably know what the parameters should be. I > > don't!] > > > > $r->return_http_code(valid HTTP::Status value) > > [This will also return the headers & content etc as appropriate for the > > particular HTTP code] > > > > These can manipulate flags, or response objects, or throw and catch > > exceptions, or whatever as they need in order to implement the > > functionality. > Possibly. I'm a little uncomfortable about trying to predict what > people might want to do with a system. I think with a couple of flags > and a couple of hooks, we can provide the framework to build things > like internal_redirect() and return_http_code(). Then we could leave > the implementation of it to whoever has a pressing need to return > whatever obscure HTTP code. There is a reason that everything from CGI to mod_perl to ASP and PHP have a redirect method - people use it, a lot. Hence a need to provide a redirect method for the request. Thats hardly an obscure http code. Also you might want to send customised/branded/ live/test/staging error pages to the browser with varying levels of content, and not necessarily relying on a model or view which could break before the error information can be returned to the browser. I think providing a 'stop! everything is done! just send what we have back to the client' flag will be bloody useful, not much point doing a bunch of stuff you don't need to when you plan to redirect to a different page or action instead. Same applies for providing hooks - there is no reason people shouldn't be able to do stuff like splice sessioninfo out of a path before it is processed by maypole - I've worked with a system that does this before and it was all done in rewrite and horrid hacks - being able to do it nicely with a hack will make Maypole able to solve a wide range of current web application problems with clean maintainable solutions instead of hacks spread accross cgi scripts and apache configurations. regards, Aaron ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
