[Zope3-Users] Trouble with Skins

Arne Nordmann mail at arne-nordmann.de
Wed Jun 27 06:45:13 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Herman,

thank you very much for your answer.

> However, this case shows me that I'm not the only one with such problems. 
> These ComponentLookupErrors and cryptic tracebacks (at least for newbies) 
> drove me mad and costed me hours to resolve. In the end it was always "my 
> fault", e.g.:
> 
> - Forgot to add the appropriate  layer to the request
> - Forgot to omit __parent__ in my formlib class
> - Forgot to register something or registered it for the wrong interface
You were completely right. The problem was an absent comma in
standardmacros.py and an incorrect closed <metal>-tag. [1]

> I'm curious how others deal with this problem because I'm often paralyzed by 
> this ComponentLookupError. The traceback also does not show which interface 
> my objects provide - for example it cannot be seen if a BrowserRequest 
> provides a specific layer or not. To solve this problem, I had to insert 
> something like "print IMyLayer.providedBy(request)" into the Zope source to 
> find out what happens.
Phillip von Weitershausen had a great talk at the DZUG conference this
year about "Zope on a Paste"[2]. He demonstrated some kind of middleware
that does what you asked for - giving you the possibility to look into
every object in the moment the error occurred.
I wonder if a tool like this will find it's way to the ordinary Zope3
user. Phillip?

> Maybe a Zope3 "newbie-debug"-mode would help a lot that throws a traceback 
> like this (regarding to the original problem)?
> 
> ------------------------------------
> ... Original Traceback ...
> --- Verbose Traceback ---
> ...
I'm completely with you at this point. When I came to the point to solve
a problem based on a traceback for the first time, I was stuck.
Even when I solved those problems in the past, I often couldn't find a
hint in the traceback retroactively, even with knowing the actual problem.

I often thought about something like you suggested - a kinda comfort
traceback.
One of the advantages of a CMS-like system like Zope is, that you don't
have to care about the entire machine that is working in the background
behind your application. But from the moment on you get the error, you
are forced to deal with the traceback that gives you lots of information
on parts of this machine you don't really want to deal with.

As I mentioned, I'm loosely thinking about this kinda comfort traceback
for months, but I don't really think that my understanding of the Zope3
machine is deep enough to do this on my own.
Perhaps there should be a draft or some kind of feature request thrown
to the Zope3-dev list to exchange opinions with the developers.

Regards,

Arne

- -----
[1] For those, who deal with the same error:
- - I forgot to type the comma in the value of the attribute 'macro_pages'
of zope.app.basicskin.standardmacros.StandardMacros (see example 10.3.2
in Phillip's book "Web Component Development With Zope3", 2nd Edition)
- - I falsely closed a <metal:slot>-tag with </metal> instead of
</metal:slot> in my custom page macro.

[2]
http://www.zope.de/redaktion/dzug/tagung/potsdam-2007/folien/zope-on-a-paste.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGgj+5RawDj1XqbtwRAg1nAJ4sru+DtJXqF+r+hw3ESJpPslMYlACbBFnd
49eUvBiLeIj7sAMvdGJpwVw=
=c7AO
-----END PGP SIGNATURE-----


More information about the Zope3-users mailing list