[Kss-devel] "Could not adapt" error with event subscribers firing during an ajax call

[Godefroid Chapelle]

Balazs Ree wrote:
> On Fri, 09 Nov 2007 07:52:13 +0100, Jeroen Vloothuis wrote:
>> Perhaps we should make handling these subscribers more robust by
>> default?
> 
> This is an important question and we already talked about it a bit. We 
> can have two basic approaches:
> 
> 1. let an exception raised as currently
> 
> This has the advantage that we consider the things that are done by the 
> event handlers not optional but essential part of the application. If 
> they do not happen the application is broken, it is best to signal that 
> with an exception so we are forced to fix it

I totally agree this is the way to go.

UI of Ajax application does not work if Ajax actions result in 
incoherent screens.

In a component world, the only way (that I know)
to let other UI components to know about changes of state of objects 
they display is the subscriber--observer pattern.

Obviouly this implies subscribers need to be robust enough, which is hard.

> 
> 2. swallow them generically and maybe log it
> 
> This has several problems. First part of the application is silently not 
> running correctly altough it seems to run. Second we usually do not 
> discover if this happens. Third it is against the "explicit is better 
> then implicit" principle.
> 
> 
> Let me tell a real life example. There are currently two event handlers 
> on plone.app.kss trunk, that are broken for whatsoever reason (probably 
> another component programmer made a change somewhere else, without caring 
> that our tests actually fail as a consequence). I did not want plone 
> trunk to break entirely but I also did not have time to fix them yet. So 
> I disabled the event handler code and I am logging an ERROR saying that 
> the code needs to be fixed each time it is invoked.
> 
> Even this way, because I disabled the exceptions, probably none of you 
> have noticed that there is a problem at all. So fixing the problem is 
> pushed to infinity. But at least I needed to manually disable the events 
> which is I believe much better then the option 2. when it would just 
> magically happen.
> 
> 
> However in current case I suggest we really take a deep look of what 
> happens, because acquisition + portal_factory problems can be a real pain 
> if ignored.
> 


-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be