Re: [Zope3-dev] AW: Proposal, free views
Philipp von Weitershausen wrote at 2007-9-25 18:49 +0200: > ... >I think we should just not raise any deprecation warnings at all. >Just the imports for BBB and be done with it. I like this very much :-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] AW: Proposal, free views
On Sep 25, 2007, at 12:49 PM, Philipp von Weitershausen wrote: ... Note that I've seen checkins that add deprecation warnings. Even worse, they're talking about removing stuff in the future. I thought we had reached the consensus that we weren't going to remove stuff anymore. In other words, that we were never ever going to break backwards-compatibility again. I think we should just not raise any deprecation warnings at all. Just the imports for BBB and be done with it. We said we would only break backward compatibility under dire circumstances. :) I think that deprecation warnings are fine to let people know "This isn't the way you should be doing this. That other way is better." It helps people use packages according to the state of the art, which will continue to evolve and it will make developers feel better, which is worth something. :) Also, if we ever *do* need to make a backward-incompatible change to a package, we'll have some license to clean up rotten apis. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] AW: Proposal, free views
On 25 Sep 2007, at 18:41 , Brian Sutherland wrote: On Mon, Sep 24, 2007 at 01:13:00AM +0200, Roger Ineichen wrote: 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. Personally, I think this is the way to go. i.e. to separate the UI from the python API in separate eggs. That way the python API egg can have relatively few dependencies, and thus be more useful to more people. The UI egg is then useful to whoever wants to bring in all the dependencies and conform to the UI. It's very strange the way Zope3 mixes high-level code (css, html, pagetemplates) with low-level python APIs. Basically forcing you to have (and manage) lots of dependencies even if you only want the python API. After pondering about a while, I think this is probably a very good solution. It should help us reduce the package interdependencies quite a lot, at least on the Python-only level. It should also add meaning back to the "zope.app" namespace. Note that I've seen checkins that add deprecation warnings. Even worse, they're talking about removing stuff in the future. I thought we had reached the consensus that we weren't going to remove stuff anymore. In other words, that we were never ever going to break backwards-compatibility again. I think we should just not raise any deprecation warnings at all. Just the imports for BBB and be done with it. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] AW: Proposal, free views
On Mon, Sep 24, 2007 at 01:13:00AM +0200, Roger Ineichen wrote: > 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. Personally, I think this is the way to go. i.e. to separate the UI from the python API in separate eggs. That way the python API egg can have relatively few dependencies, and thus be more useful to more people. The UI egg is then useful to whoever wants to bring in all the dependencies and conform to the UI. It's very strange the way Zope3 mixes high-level code (css, html, pagetemplates) with low-level python APIs. Basically forcing you to have (and manage) lots of dependencies even if you only want the python API. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] AW: Proposal, free views
Hi Philip > 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 > > """ > > Why do we need to change ZCML? Isn't > > > > sufficient? Let's not make ZCML any more complicated or > magical that it already is. Magic? The directive is well define with a interface IInclude ;-) Regards Roger Ineichen > -- > 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
