[Seaside-dev] how to discern request?

[Julian Fitzell]

No, there's still no way in 2.9. Once upon a time, I believe Seaside
used to indicate this in the URL with "view" and "act" or something
and obviously we could return to doing something like this if desired
but I doubt most people will like that.

Also, at a generic level, you can't even count on there being two kind
of SessionContinuations. I kind of suspect that the cleanest behaviour
at the moment is to subclass ActionPhaseContinuation to add the
creation of the DB transaction. This makes sense because the
SessionContinuations are supposed to define the body of the
Application's "main()" function (ie. what it is that the application
does for each instance).

Actually, you could also create a new SessionContinuation that created
the transaction and then called an action continuation, passing in the
snapshot. Then specify your new continuation as the action
continuation in the config. This might be better than subclassing
given single inheritance.

We're still trying to work out how to specify the flow between these
Continuations and the interfaces here will almost certainly change so
suggestions are welcome.

Julian

On Tue, Mar 10, 2009 at 3:09 AM, Ramon Leon <ramon.leon at allresnet.com> wrote:
> There isn't a test method in 2.8 as far as I know, but if you follow the
> sequences of #performRequest: in WAApplication and find the point at which
> it resumes the continuation found by looking up the actionKey (_k).  Once
> there, the class of the continuation will tell you which phase you're in.
> It would be much nicer if there were an easier way to tell but that's the
> solution I came up with when I recently needed to know this as well.
> Perhaps this has been solved more elegantly in 2.9.
>
> On Mon, Mar 9, 2009 at 5:23 PM, Sebastian Sastre <ssastre at seaswork.com>
> wrote:
>>
>> hi seasiders,
>> I need a hint on how to be able to discern when a request is going to
>> produce an
>> action phase or a render phase.
>> I don't see testing methods in WARequest to ask this. How can I deduct
>> what is
>> going to happen?
>> thanks,
>> sebastian
>> PD: the applicability of this is interesting: I want to know if the
>> transaction
>> filter needs to commit or can use a read only transaction
>>
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>