I wrote:
Before we try to make things consistent in the code, I think we ought to write down what we want to happen in the various cases (i.e. we ought to do your FSM in pseudo-code, Dave) I'll try to send some thoughts tomorrow morning.
Hmm, it's harder than I thought to write something sensible. Too hard, in fact. So here are some ramblings instead, together with a hacked about Maypole.pm, mainly showing a simplified handler_guts. I haven't sullied it by trying to compile it :)
So ... rip it to shreds! Page/request types: We need to deal sensibly with:- 'static pages' - Pages, images or other files where the content doesn't change and there's no authorization to be done (e.g. a logo) - as for static pages but where authorization is required (e.g. adult images) - 'plain templates' - Pages that need to be processed by the view but not by the model
- model-driven templatesI think we should recommend the idea of configuring Apache such that it never passes static pages to Maypole. Then we can ignore them :)
I think the second type can be dealt with by declaring a model subclass to process the request (the action needs to fill $r->output with the image or whatever) and adding the 'table name' of the class to a list of ok_tables. Does that work?
The other two classes are already dealt with. My prejudices on error handling: - diagnostics ought to appear in the apache log- diagnostics should not appear in the browser unless debug is set (but some identifier to refer back to the apache log should)
- error responses that are presented to the end-user should be customizable ... and on text formatting:- readable text or HTML formatting should not be configured in Perl code, it should be in the templates, or at least overridable there. I need to correct that, automatic database introspection is OK but there needs to be a way for the template writer, not Perl programmer, to override it. So 'application_name' should be removed from the config, for example.
And on one particular division of responsibilities:
Backend provides:
-----------------
- get_request
- parse_location
( ItSeemsToMe that the last four lines (or certainly the last two)
would be better brought out to Maypole->handler(), in order to
remove the circular dependency caused by parse_path )
Controller provides:
--------------------
- parse_path
- and should provide the converse - make_path (which is presently
implemented by the link macro and various bits of hard-coded TT) M-P-LT
deals with this.
call_exception -------------- Does anybody use this mechanism?It doesn't make much sense to me to have a method in the model that handles exceptions elsewhere:
- if authenticate dies, something weird is happening (perhaps an attack?) and we don't want to delegate that. You get to write authenticate, so you can put whatever error trapping you want directly in it.
- if the view dies, why would the model know anything about what to do? And why is it safe to run the view again OUTSIDE an eval to report the error. Surely the likelihood of that dying is quite high?
- come to that, if you're going to write an exception handler in a model class, it means you're already fiddling with the model class. So you might as well just add the error trapping to the process method.
So can we deprecate the call_exception mechanism? send_output ----------- We should modify the interface of send_output to: - take Apache/HTTP errorcode as a parameter - return Apache/HTTP errorcode as resultand modify the last bit of handler() so that returning e.g. Forbidden 403 from authenticate can be made to produce a sensible result
Also ---- template test moved from model to handler_guts postprocess added (i.e. additional_data2) $r->query deleted Cheers, Dave
Maypole.pm
Description: Perl program
