[Kss-devel] Superfluous view registration?

Balazs Ree ree at ree.hu
Wed Mar 12 19:05:16 CET 2008


On Wed, 12 Mar 2008 18:11:04 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>> This is, besides the unittest you mentioned, also completely tested in
>> all variations in the "error" demo and selenium test.
> No it is not tested in the Selenium tests. That is what made me think
> this was a useless view (since kss.zope does not load it and all
> Selenium tests ran fine).

True, I would add that this also proves we need more work before we can 
release kss.zope - and there will be still other missing bits to 
discover. And even in kss.core, Selenium coverage is not yet 100% 
although it is closing. But indeed we miss something here.

> The Selenium test in question has this code:
> 
>     @kssaction
>     def errTest(self, id, act):
> 
> What happens is that the `kssaction` decorator itself catches exceptions
> and returns an entirely different body (normal KSS style). Here is a
> small snippet of that code (from actionwrapper.py).

There are more different cases that can happen, you refer one of them 
here and what you are looking for is in another case. We can have errors 
raised explicitely (KSSExplicitError, this is what you refer here), we 
have normal exceptions (that have a default zope error response, that's 
where the payload gets added in the headers), and we have timeouts. All 
these cases are handled differently (look at the buttons in the row in 
the selenium test). But you are right when you say that the Selenium 
tests are not complete, see my remark below.

 
>         try:
>             result = self.f(obj, *arg, **kw)
>         except KSSExplicitError, exc:
>             # Clear all the commands, and emit an error command
>             obj.commands.clear()
>             obj.commands.add('error', None, message=str(exc))
> 
> So it seems that at the very least we have lack in our tests.

Indeed. Let me count the things that we _do_ test though: on the server 
side we test that the method puts the kss payload correctly in the 
headers. On the client side, we test that the error message that is sent 
in the payload appears in the log correctly, in all the 3 different error 
scenarios (eplicit error, normal error, timeout, the latter is commented 
out though).

> What I
> would like to know is when would this view be used if `kssaction` seems
> to do it's own thing?

It's when there is a normal exception, and the default error template 
annotates the error information by using this method. Please have a look 
at how it is used in Plone with the default error template. (At least I 
hope it's not currently broken: another place where we will be safer once 
the psps proposal will have been implemented.)

If you could figure out how to substitute zope's default error template 
only for the context of this single test (or for all our tests) and not 
replace it globally, that would be a great thing and it would allow us to 
test the missing bit from Selenium but I could not figure out how to 
achieve it, at the time when I wrote this code and its tests.


-- 
Balazs Ree



More information about the Kss-devel mailing list