> 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.
The directive is well define with a interface IInclude ;-)
> http://worldcookery.com -- Professional Zope documentation
> and training
Zope3-dev mailing list