On 9/29/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > 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.
Yes, and all I'm doing is throwing out ideas that seem to make sense. That doesn't mean they *do* make sense, we need to chew them over first and see what we can agree on. 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. 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, and I think send_output should return/have access to the return code. 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. > > >>>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. Yuk. I went to bed last night and realised I was talking bollocks. But 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(), and the most obvious way is to have a flag. Also, REDIRECT is not necessarily the only return code we should check for. > > 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? 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. 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. 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
