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 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="" 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:

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.

-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to