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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
