David Baird wrote:
On 9/27/05, Aaron Trevena <[EMAIL PROTECTED]> wrote:
On 9/27/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
Well, Aaron said he wanted the done flag before the workflow changes,
but your explanation seems to be that the done flag is a detail of your
workflow implementation, so I'm still confused.
Yes - I'd want the done flag for a bunch of situations such as :
* generated xml, no need to look at templates just send it back already
* fetch static page/image/etc and serve it straight out
* redirect to ssl of this page, don't process data, don't do anything else
* custom 404
* zillions of other things.
I hadn't thought much about what it would be used for, Aaron's clearly
got a bunch of ideas already. I'm coming more from the angle of
removing implicit behaviour. Then it's easier to know what's a bug and
what's a feature. For instance, at the moment, the view isn't
processed if there's already some content. I'd prefer to make an
explicit call that switches the view off. Similarly, the model isn't
processed if there's already a template set. I'd prefer to switch the
model off explicitly. So for that kind of thing, you need flags to
manipulate.
Ah, OK, it's a clarity thing, not a functionality thing. AFAIK, we've
discussed how to do all Aaron's examples already without a done flag.
And I suspect it's key that you say 'flags' rather than 'flag' in the
final sentence. If you introduce a done flag now, won't you need to also
keep all the existing mechanisms because of backwards compatibility? So
the code will just get more complicated. It would seem better to first
get an agreement with everybody about where we want to go.
Are you talking about something like the ability to rerun handler_guts?
Something like this in handler?
Kind of, but that only gives you an internal redirect from inside
handler_guts(). If you want to redirect from before (e.g. during
authentication) or after (maybe to handle an exception thrown during
view processing), you need some flags to tell you how to start over,
in particular, whether you need to call handler_guts again (because
it's already run), or not (because it's not yet run).
I'm confused again :) authenticate is run inside handler_guts, so is
view processing. What's before handler_guts is accessing the request,
and what's after it is sending the output. So I don't understand.
David Baird wrote:
> On 9/27/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
The difficulty I have is in understanding how it is supposed to
work and be extended or modified. i.e. what's a feature, what's an
implementation detail and even sometimes what's a bug.
>
> Absolutely. Part of that I think comes from the naming of methods.
> is_applicable(), authorize(), additional_data() - really, they're all
> just hooks into different stages of the request. Another part comes
> from implicit changes in behaviour, depending on whether content has
> been generated, whether a template has been set etc.
I agree the method names are a bit idiosyncratic, and the control-flow
side-effect of setting some attributes was initially a surprise. But
both those 'features' are eventually learned and we could document more.
We could also change the method names (well, add aliases) if we thought
it would help. 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?
not done & output set = old-style application preventing view
processing or BUG in new-style application
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?
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
