AW: Proposal, free views

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
>