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

Tue Apr 27 04:17:57 EDT 2004

Stephan Richter wrote:
> 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!

Yes, I understand, I will looking for a nother way.

> > 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.

Ok, I agree

> 
> > 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?

I send you a link off topic.
If somebody also is interessted in to see this skin, send me a mail.

> > 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.

Ok, I agree, perhaps I can find a nother way.

> 
> Regards,
> Stephan
> --
> Stephan Richter
> CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. 
> student) Web2k - Web Software Design, Development and Training
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub:
> http://mail.zope.org/mailman/options/zope3-> dev/dev%40projekt01.ch
> 
> 

Mit freundlichen Grüssen
Roger Ineichen
_____________________________
Projekt01 GmbH
www.projekt01.ch
Langackerstrasse 8
6330 Cham
phone     +41 (0)41 781 01 78
mobile    +41 (0)79 340 52 32
fax       +41 (0)41 781 00 78
email r.ineichen at projekt01.ch
_____________________________
END OF MESSAGE