David Baird wrote:
My objectives are threefold. First, clarify the code, because I'm
tired of having to study it in detail every time I need to figure
stuff out.
I agree with this.
Second, fix bugs, if there are any. The 2 major bugs I have
in mind are that I think the view exception handling should be
separate from the pre-view exception handling,
Agreed. If the view processing just failed, I see little reason to
depend on it to process an error template.
and I think send_output should return/have access to the return code.
Agreed. We can do this now, I think.
Third objective is to understand the workflow well enough to have a
clear idea about how it needs to change. I think as my ideas on this
become clearer, I see less and less need for change, which is why I
pepper all my comments about the _run_workflow stuff with caveats.
That's hopeful :)
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.
<snip>
But what about setting $r->output if you add a done flag?
You then have four cases:
done & output set = current case to prevent view processing
done & no output = BUG?
No, in this case, the server returns a response code to the browser,
e.g. SERVER_ERROR or REDIRECT, but no content. That's difficult to do
at the moment.
not done & output set = old-style application preventing view
processing or BUG in new-style application
An easy bug to deal with though - just issue a warning and send the
output, just like old-style.
not done & no output = current normal case
How do you avoid these leading to extra documentation and increasing
code complexity, both in Maypole and in applications?
Not counting the bug, you now have three cases because there *really
are* three cases. At the moment, Maypole only offers 2 cases. You can
get around it for specific purposes like authentication, primarily
because that happens early in the request, and there are (more or less
tricky) ways to skip processing the model *and* the view and just
return a response code.
You're quite right of course. And in CGI, even the trick is broken.
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.
Cheers, Dave
-------------------------------------------------------
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
