[Seaside-dev] Debugging in Seaside 3.0 (issue 340)

Michael Lucas-Smith mlucas-smith at cincom.com
Sun Sep 20 16:14:21 UTC 2009


Lukas Renggli wrote:
>>> Recommendations:
>>>     1) An official "technique" could be published somewhere, on the
>>> seaside wiki perhaps, on how to implement debugging in Seaside for each
>>> implementation.
>>>     2) The WAExceptionHandler* classes can be removed to dissuade people
>>> from expecting a way to do this reasonably.
>>>
>>> What do people think about this?
>>>       
>> I'm not particularly found of it. I don't like clever process tricks.
>>     
Clever process tricks is what used to happen in Seaside 2.8. Now it's 
not doing anything clever at all.
In VisualWorks, when an exception is unhandled, a DebuggerService is 
created for the process and a DebuggerClient opens up on it. The 
DebuggerService provides all the controls to manipulate the process.

The two options are: let the GUI show the debugger, which is fine for 
most cases. Capture the service in a collection and let a web page show 
the debugger - which is the technique I described above.
>> Additionally where do you store the processes and how do you reap
>> them?
They go in to a collection, you either reap them when you're done 
debugging (resume or terminate) or you can terminate them before you 
debug. That's the same as the GUI is right now, which pops up a debug 
dialog asking you what you want to do with it.
>>  Moreover not all platforms have a comet server.
Right, as I said before, the debugging code is platform specific anyway, 
there's basically nothing reusable - except for the technique itself. 
Polling is just as acceptable, but there's no reasonable spot in the 
regular seaside to start polling or cometing for debug exceptions. My 
preference would be for seaside to not attempt to be a debugger at all - 
but for us to merely say "and this is how you can implement web 
debugging if you want to"
>>  I'd rather just
>> open a debugger in the image, which is what your eventually going to
>> do anyway.
>>     
Except if you don't have a GUI. But I pretty much agree with you on 
that. Right now we have classes in Seaside 3.0 which try to interrupt 
the current process to show you a walkback that can have a Debug button 
on it - that's the stuff that pretty much can't work and needs to be 
dumped. When removed, the two modes are: walkback, pass-thru to image.
>
> Yeah, I agree with Philippe. Far too complicated.
>   
I disagree. Either a dialog pops up in your GUI or the exception goes in 
to a collection. That's not complicated at all. I believe Seaside should 
not get in the way at all, the exception handling code should be 
platform specific.

Cheers,
Michael


More information about the seaside-dev mailing list