AW: [Zope3-dev] Re: AW: override metadirectives before use them notafterwards

[Stephan Richter]

On Monday 26 April 2004 17:28, Roger ineichen wrote:
> > Indeed, we won't have to. I recommend, if you need to override a
> > directive, create a new one in a different namspace, e.g.
> >
> >    <roger:containerView ... />

Yep, that would be the right way.

> Lets make a better example:
> Let's say I whould change the template contents.pt which is imported
> by the class Contents.py in the zope.app.container.browser package.
> I have different ways to do so:
>
> 1. Write a own directive <roger:containerView ... /> and use them
>    everywhere.
>
>    -1, it's to much work for just use another template.

Nope, I think you understand the intend of the "containerViews" directive 
incorrectly. It is *meant* to be a fast way to provide the standard container 
views for IContainer objects. For a real-world application, you should always 
develop your own set of views. We, as the Zope 3 developers, discourage using 
the default views coming with Zope 3. They are only meant for the ZMI and not 
end-user code. The target audience is very narrow. 

For a 3rd party product you should always use the simple zope:view, 
browser:page and browser:pages directives.

>    -1, needs a lot of changes in many configure.zcml's
>        You have to provide a own configure.zcml lib for this.

This is only true, if you want to provide your own convenience ZCML 
directives.

>    Important:
>    I write a package and add a directive, Other use them, this means
>    The package doesn't work without know how (yes you have to know what
>    you are doing, but..) and work of everybody who is useing this
> package.!!!

It is documented by default via the API doc tool.

>    -1, future added stuf are hard to support

how so?

>    -1, no easy way for doing this, makes developer use creative hacks
>        in the future.

Overwriting meta directives would be the first hack. But again, I would not 
try to write custom ZCML directives, unless I had good reason to do so. 
"containerViews" is an example where I would not do it.

BTW, please do not overuse ZCML! It is meant for bootstrapping and the 
limitations of it were inserted on purpose!

> 2. I can write a own contents.pt and copy to the
>    zope.app.container.browser package.

Oohhh, no!

> 3. Write a package and add script who copies the template.pt
>    to the container package by a bootstrap process.

Oooh, no!

> 4. Override the meta directive and let ZConfig use the new
>    overriden directive.
>
>    ++1, whould be a clean way for to change basic implementations.
>
>    +1, I can write a own Contents class and a own contents.pt template
>        and register a new meta directive. I can exactly implement
>        what's have to replace.

This will never happen. Forget it. Try to find other solutions!

> Another question is, what's the target.
> But it whould be nice if we can change exsisting implementations.
> I think that's a big difference.
> I'm shure we see this in the future. 

But ZCML are not components. You change behavior by changing components. For 
example you could write a custom Presentation service that fits your needs 
better and allows for simpler overrides of the views.

But ZCML is not the thing to be replaceable.

> It's just a question of, can we  provide
> this in a clean way. Otherwise we see some ugly hacks like monky patches
> in zope2, just why the clean way means to much work.

It is as clean as it can get. Write an object that provides a certain 
interface and register instead of the default one. This is exactely what the 
ZCML overrides functionality is aimed at.

> If we could override meta directives we get more flexibility, less work
> and a clean layer for to inject own implementations.
> (Just for some parts, not at all)

Nope, nope, nope. It will not buy us more flexibility. In fact, it will become 
a maintenance disaster as various 3rd party products want to override ZCML 
meta-directives in their way. That would lead us right back to the problems 
Zope 2 has.

> Do we get bad thing's where I don't see at this time?

Yes, see above.

> A good example of this restriction is the zmi skin.
> I was developing a new (zmi) skin with different additional
> futures like.
> - a zmi tree with a principal annotation of the state for each user
> - drag and drop support form the folder contents view to the tree (move)
> - slots with boxes (the tree box is in a slot, every body can register
>   own boxes in this slots)
> - boxes can be expanded or collapsed (persistence for each user) etc etc

Cool stuff. Where is that skin?

> All this futures I could implement without any problems in a new skin
> except the changes in the contents.pt template. It needs just a
> javascript:oncklick event on the img tag of a objects image.

Right, so that is a true limitation to the current skin mechanism that I am 
not happy with either. I ran into similar problems when doing the original 
ZWiki code. I have no good answer for this. But it might be for the better in 
the long-run, if you develop your own contents.pt template, since you will 
probably make more changes as development progresses that is incompatible 
with the default rotterdam skin. However, overriding meta-directives is 
definitely not the right approach.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training