[Zope3-Users] ZCML debugger?

[Roman Susi]

Stephan Richter wrote:
> On Sunday 12 February 2006 10:19, Roman Susi wrote:

>>Or at least some good documentation on what is the meaning of ZCML
>>constructs.
> 
> 
> Have you looked at "http://localhost:8080/++apidoc++"? It contains a 
> dynamically generated ZCML documentation section. If you think that this 
> facility is not well-organized you could easily contribute improvements 
> there.

After trying to understand what is really so difficult about Zope 3 way,
I think that the difficulty lies in grasping the links between all those
 things: utilities, adapters, services, interfaces, etc.

That is, when I open (e.g.)

http://localhost:9080/++etc++site/tools/PsycopgAdapter/@@introspector.html

I see information which (presumably) contains everything I need to use
PsycopgAdapter (of course, this is not so - I need to go to base class
(?) to see

http://localhost:9080/++apidoc++/Code/zope/app/rdb/ZopeDatabaseAdapter/index.html

- this way I have better picture.

But, the question (and big barrier, IMHO) is to see how these
descriptions (nice and elegant) will show up in your own code.

What am I going to write in configure.zcml? In an adapters.py (if I need
it). In mycontentclass.py?

And there are many things to remember, as they differ for different
kinds of "things" I do like to use. Some kinds of names appear that I do
not know where theybelong (like in:

<<<This object is registered as:

    * provided: zope.app.rdb.interfaces.IManageableZopeDatabaseAdapter
    * name: pgsql
    * component: PsycopgAdapter
>>>

- I do not know where the name pgsql is accessible from, what is its
visibility scope, its supposed usage.

If I compare this situation to Python, it is always quite
straightforward to look at the source of the module or to
help(thesamemodule) to see that I need first make an instance of some
class and then use its methods.

So, probably, Zope3 needs a kind of a tour which explains those links
which are not explicitely visible.

I am sure, that after reading the whole Zope 3 book AND doing something
real I will probably be able to see those invisible threads which keep
Zope 3 intact.

Right now I understand that Zope3 has different "spaces", from which
everything can be acquired: (P) usual Python modules hierarchy (plus
file-system files) and (C) content containment  hierarchy (with some
globally available things like utilities).

(At page template level there may be more to this - macroses have their
own "line of command" - (M))

So, at ZCML we are dealing with (P). In Python code - also with (P). In
page templates - with (C) and (M), but (P) is accessible from context.
In the ZMI we actually see (C) but can have a glimpse of (P) in the form
of Introspector.

And there is also one dimension - directive prefixes...

But why all this need to be THAT difficult? Why some simpler, more
explicit model can't be used so names can be quite uniformly traces to
their origins?

Of course, we need to separate Logic (P), Presentation (M+ZPTs+P) and
Content (C)... But still this is so difficult to grasp doing first steps.

> Regards,
> Stephan

Sincerely yours,
Roman