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.
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. <snip> > > > 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 > [This will also return the headers & content etc as appropriate for the > particular HTTP code] to whoever has a pressing need to return whatever obscure HTTP code. d. ------------------------------------------------------- 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
