Dear all,
For those that have used Seaside, and you try to debug with the Debugger, you know that upon request processing seaside uses Exceptions mechanism to always have access to the current request, error handler, etc. The way that this is done is via subclasses of WADynamicVariable:
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.
Once inside the debugger, things get complicated. While you can restart, proceed, etc (because the process you are debugging is inside the scope of the dynamic variables), you cannot evaluate any piece of code that at the end use the session or request because you get a WARequestContextNotFound kind of error. The reason is obvious: The evaluation, do-it, print-it, etc etc you on a piece of text or via the debugger inspector, creates another closure/context which is not in the scope of the dynamic variables.
For a client, we also have custom subclasses of WADynamicVariable, for example UserContextInformation. And that means that almost every time in the debugger I really need access to that object.
It does work for me, and if you think this could be useful for Seaside itself, I can commit it there.
The idea is very simple. I have a WADynamicVariablesErrorHandler subclass of WADebugErrorHandler. We reimplements there #handleException: in order to simply iterate all values of all dynamic variables (all WADynamicVaraible subclasses) and store those into a dictionary in a class variable of WADynamicVariablesErrorHandler.
Then, I simply override (this is the part that must be cleared if we integrate this in Seaside) WADynamicVarible >> #defaultAction to be something like this:
WADynamicVarible >> #defaultAction
^ (WADynamicVariablesErrorHandler storedDynamicVariable: self class)
ifNil: [ self class defaultValue ]
That way... when we handle an exception, we save out all values into a class side. And then, in the debugger, whenever we evaluate, inspect, print etc anything that would do a #value over a WADynamicVariable subclass, it ends up calling #defaultAction (because there will be no handler in the stack) and there, we first check if the have the value for that dynamic variable. If we do, we answer that, if not, the defaultValue :)
There are tests too. There is WACurrentRequestDebuggingTest which you can try from /tests/seasidepharodebugging
For the user, there is almost nothing to do. All WADynamicVariable subclasses are managed automatically. All you need is to register the exception handler:
app filter configuration at: #exceptionHandler put: WADynamicVariablesErrorHandler.
The only drawback here is that this doesn't work with multiple debuggers as the last debugger will override the class variable values and hence the OLD already opened debuggers will be getting a wrong (the latest) value for the dynamic variables.
What do you think? I think that while it might not be the best solution and it has limits, it is every is extremely simple and does the job.
Maybe you see problems I am not seeing?
Let me know if do you want this integrated or not. In the meanwhile, I am loading it from my repo for my apps and keeping the override (I would like to get rid of it!!!).
Best,
--
Locked
