[Zope3-dev] Some Z3 thoughts

[Lennart Regebro]

Jim Fulton wrote:
>>   - When trying to look at some interfaces:
>>     Module zope.pagetemplate.pagetemplate, line 35, in __get__
>>     parent._cook_check() you get an error:
>>     AttributeError: 'NoneType' object has no attribute '_cook_check'
> 
> 
> I don't understand this. What were you doing?

Oh, I went to the "introspection" page and clicked on some of the 
interfaces listed. Some worked, some didn't, and this was constistent 
over types. Obviously I forgot to write up which interfaces didn't work.

But OK, this seems to not be a known problem, so I'll look into it more 
closely.

>>   - Views registered with zope.Public doesn't show up. Any other
>>     permission (Zope.View for example) works.
> 
> Hm. That's odd and bad.
> 
> It would be good to submit issues for all of these:
> 
> http://collector.zope.org/Zope3-dev

OK.

>> Inconstistencies:
>>
>>   - ContainerTypesCONSTRAINT / ItemTypePRECONDITION ???
>>     They do the same thing!
> 
> 
> No, they don't.  They are both about constaining the containment 
> relationship, from different ends.

Yeah, but one is called contraint, and the other precondition. ;)
No big deal, it just stood out to me as an inconsistency in something 
othwerwise carefully consistent.

>> Wouldn't it be nice:
>>
>>   - Wouldn't it be nice to at least recommend a place for third-party
>>     packages? Otherwise things are gonna get SERIOUSLY messy.
> 
> 
> Not sure what you mean.  Are you talking about places in an installation,
> or in the repository?

Sorry, in the installation. I like the Zope2 way of having a separate 
Products where you put all the third-party stuff, but there doesn't seem 
to be anything like that for Zope3.

>>   - Wouldn't it be nice to be able to specify more than one interface in
>>     a for="blabla.Interface" specification in zcml? Or maybe that is
>>     really unusual (even though it happens in the MessageBoard example).
> 
> You can, but it probably means something else than you intend.
> 
> One problem we have is that, in many places, we mix definition and
> configuration.  For example, in a page definition, we define a component,
> and we say how to do it.  I'd like to have a way to separate these, so
> you can, for example, define a page once and register it as many times
> as you need.

OK, that sounds reasonable.