[Zope3-dev] Re: AW: Proposal, free views

Philipp von Weitershausen philipp at weitershausen.de
Sun Sep 23 18:07:25 EDT 2007


Roger Ineichen wrote:
>>> This proposal describes a way to make the usage of such 
>> built in views optional.
>>
>> "Such built in views" means what? "Optional" how? And why?
> 
> I mean with built in views just views which comes within a 
> package. Such view component are located in the browser folder
> and built on the BrowserPage classes. I guess the term views
> is common for that and should be well known.

Yes, but the overall language of the proposal is very confusing. Sorry. 
But it just is. It starts with the title which I coudln't make sense of 
at all. And the introduction is just as confusing.

>> "The additional component.zcml could be used to include only 
>> component related configuration whitout the view parts 
>> defined in the browser.zcml. Because the browser.zcml get's 
>> included from the configure.zcml but not from the component.zcml"
>>
>> OK, I understand what you want to do: Start the practice of 
>> having views in one zcml and components in another, so you 
>> can include only the component one if so desired. I don't 
>> understand why, though.
>>
>> "Right now it's not possible to use another layout pattern 
>> without to support zmi_views and zmi_action and it's menut 
>> item pattern. The views defined in all packages also require 
>> the use-macro, fill-slot pattern which is not what we allways 
>> whant. Right now there is no option to get rid of this 
>> patterns except to duplicate packages and replace existing views."
>>
>> That's what you will have to do anyway. Because if you don't 
>> include the views, you will have to replace them in another 
>> package. And you can override them in another package already...
> 
> Yes, this is what we like to do. We like to write 3rd party 
> packages. But the problem is, this views are using templates which
> we don't support, e.g. use-macro, fill-slot etc. Also the 
> configure.zcml file registers menu items for zmi_views and 
> zmi_action which is does not exist in our setup.

So what? Will it hurt you to configure those zmi_* menus, even if they 
won't be used? Will it hurt you having those views around, even if you 
won't be using them?

And even if you don't care about them at all, you can still make sure 
you don't inherit your skin from IDefaultBrowserLayer. Then you will 
never ever get those views.

> I guess it should be possible to use Zope3 without the need
> of zmi_views and zmi_action menu items

Maybe. You still haven't said why it is so important to you.

Also, the whole menus thing is a new aspect. The proposal mentions it, 
but from what I understood, it doesn't define it as a problem. You might 
want to revise your proposal to include this aspect if it's important to 
you.

> Whih is not the case right now. See all the ftesting.zcml files in the different 
> egg packages.

I don't see anything about zmi_* menus in ftesting.zcml files. All I see 
is the inclusion of zope.app.zcmlfiles which loads all the stuff a 
typical Zope 3 application needs (including the zmi_* menus).

I think the problem with the zmi_* menus is a differnt one. Currently, 
all packages simply seem to assume that all their dependencies are being 
loaded anyway.

Let's take the zmi_* menu thing as an example. Every package that 
configures views for any of the zmi_* menus depends on the menus being 
configured. Such a package should really say:

   <include package="zope.app.zcmlfiles" file="menus.zcml" />

at the top of its configuration. Likewise, a component that depends on 
the annotation adapters to work should load zope.annotation's 
configuration at the beginning of its configuration, and so on. We're 
not doing this right now. If we did, a lot of things would actually get 
much simpler for egg-based projects.

I've made this one of the sprint tasks for the NeckarSprint: 
http://wiki.zope.org/zope3/NeckarSprint2007.

> Pobabbly the proposal should be simpler and propose.
> 
> "Get rid of zmi_views, zmi_actions, StandardMacros and
> hardcoded template relations in views"

As said, it seems that the proposal text could really use some 
refinements regarding your actual problems and your actual goals.


-- 
http://worldcookery.com -- Professional Zope documentation and training


More information about the Zope3-dev mailing list