On 2015-12-03 6:34 PM, Mariano Martinez Peck wrote:
Hi guys,
This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :)
For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :)
WACurrentRequestContext use: self during: aBlock
In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance.
So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance.
Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this.
Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance???
Thoughts?
-- Mariano http://marianopeck.wordpress.com
I have a thought. It may just show my shortcomings, but here we go. I base my idea on the notion that a resumable notification is a way to go to an earlier context in the sender chain to get an object, return back to a place later in the sender chain, and then use that object. Your problem is you want an object at a location in the sender chain and it is not there. If you execute WACurrentSession value, you are told that this is not useful as you're out of scope. I would suggest that this is weird to the Smalltalker way of thinking because this is Lisp-like lexical scoping dragged by Avi into Smalltalk. If these things are true to this point, then the problem isn't how to get what you want where you want it but knowing exactly what it is you want. Somewhere earlier in the sender chain is an object. When you find it, you'll use a resumable notification to bring it forward to where you want to use it. So, what object do you want? All my examples are from Seaside2.6. Because we are having a hard time finding the object we want, I'm going to write it in all CAPS in the code examples that follow. WASESSION responseForRequest: ... snip... [WACurrentSession use: SELF during: [ self withEventHandler: [ self performRequest: aRequest ]]] This can be re-written as: WACurrentSession use: ANOBJECT during aBlock [ self with ErrorHandler: [ self performRequest: aRequest ]] on: WACurrentSession do: [:n| n resume: ANOBJECT ] The self in the first example is becoming the pseudo variable in the second example. That's pretty unusual to me. And you know that WACurrentSession value is just a way of saying WACurrentSession raiseSignal. So, now, perhaps you know what object you want, you want that session object, and you want to drag it back to later in sender chain. Use a resumable notification. Maybe something like: WARequestContext push: aRequestHandler during: aBlock [ [ WACurrentRequestContext use: SELF during: aBlock ] ensure: [ handlers removeFirst ] ] on: GiveMeTheSessionRightNow do: [:n| n resume: SELF ] Go back in the sender chain for the object you want. Drag it back to the future. GiveMeTheSessionRightNow raiseSignal FWIW, Chris