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

[Roger Ineichen]

Hi Philipp
 
> Betreff: Re: AW: Proposal, free views
> 
> 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.

Yes, it is, and this was the idea to get people reading it.
But probably this was not such a good idea.

> >> "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?

Yes it hurts and it hurts realy hard. 

> 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.

Your guess ist right, we can't have unused code in our codebase.
zmi_views, zmi_actions, zope.app.form, and all zmi views are 
impossible to have in our codebase.

> 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).

No comment

> 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 agree, but how?

> 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.

Feel free to change it, any improvment is welcome!

Regards
Roger Ineichen

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