Hi Philip > Betreff: Re: Proposal, free views > > Roger Ineichen wrote: > > Please review this proposal. I'll implement it shortly if > nobody has > > objections. We need it for our work here at the Foliage sprint. > > > > If you have objections, please tell me what you think is > not well done > > and tell me your ideas to solve the problem in another way. > > > > http://wiki.zope.org/zope3/FreeViews > > I don't understand the name of this proposal. In fact, I have > no idea what it's supposed to mean. I think the proposal > should've been named something like > > "Conventions for splitting up component and view registrations"
I didn't find a better name 5 o'clock in the morning. It's related to the movie "free willy" ;-) > (Btw, the reST formatting is messed up). > > > btw, > > the proposed implementation does not affect existing projects and > > their setup. It also does not affect egg based projects. It only > > offers us a additional hook which allows us to load component > > configuration from packages without the built in views. > > > In the proposal you write: > > """ > Views or let's say browser pages and it's derivates are based > on a specific layout pattern. The default views are using > macros and slots. > This is not allways what we like to use. > > This proposal describes a way to make the usage of such built > in views optional. > """ > > I understand the motivation. But I don't agree with the > solution. I've you're not ok with the existing views, then > you currently have two options > > * Simply *ignore* that they exist. Zope actually has > facilities for doing this on a technical basis. Simply don't > inherit your skin from IDefaultBrowserLayer, and voila, you > won't get any pre-configured views at all. I can't have unused code in our codebase. We have swiss banks as customers and can't pass their security assesment with such a setup. Belive me, it's not easy to fit their needs. > * If you're interested in replacing a few select views with > your own implementations, you can use ZCML overrides. Or use > layers (which is a similar solution to the previous one). Same here, we can't have unused code in our codebase. This will increase the security assesment and I don't like to write more documentation for them. > That said, I do wish there was a way to specifically disable > ZCML directives. We've been talking about this for a long > time, actually. I think the biggest use case is for disabling > event handlers. But naturally it could be used to disable > other things, too. I agree, +1 anytime if you propose such a solution. > So, if the two options I gave above won't work for you, I > think we should rather look into making it possible to > disable certain ZCML directives, or even disable the > execution of certain ZCML files altogether. I think we will split packages in its base parts. For exapmle this means we will create a package zope.session that contains the python api and degrade zope.app.session to contain the zmi views. > My reservations toward to proposal aside, you also write: > > """ > But if we like to load only the component related > configuration without any view configuration, we could use > > <include component="foo.bar />" > """ > > Why do we need to change ZCML? Isn't > > <include package="foo.bar" file="component.zcml" /> > > sufficient? Let's not make ZCML any more complicated or > magical that it already is. Magic? The directive is well define with a interface IInclude ;-) Regards Roger Ineichen > -- > http://worldcookery.com -- Professional Zope documentation > and training > _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com