[Zope3-dev] [ANN] CPSSkins4Five and CPS4/Z3ECM Paris sprint report
Hi! I've written a report on the work I did during the CPS4/Z3ECM sprint i Paris: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_04_23_cps4-z3ecm-paris-sprint there is also a new zope2 product called CPSSkins4Five for running cpsskins (for zope3) on zope2 . http://svn.z3lab.org/trac/z3lab/browser/CPSSkins4Five/trunk/ here is an animation too: http://www.z3lab.org/sections/front-page/design-features/cpsskins4five-preview all this is very experimental and requires branches that haven't been merged into zope2/zope3/five trunks yet. But as a proof-of-concept it works. Regards /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
Florent Guillaume wrote: Philipp von Weitershausen wrote: If people don't like the 'browser2' prefix, I'm open to other suggestions. For all I care, the three directives I suggested could be on the 'browser' namespace, only browser2:page and browser:page clash. So perhaps browser2:page should be named something else. I can't seem to come up with good alternatives, though. I haven't looked closely, but can't we have one whose behaviour changes according to what attributes it has? If old attributes are provided, a deprecation message is sent but the old code is used. Otherwise the new behaviour is in effect. Heh, of course. In fact, that was my original idea, but Tres & Co. objected to it (changing browser:page in-place instead of creating a new directive). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
Philipp von Weitershausen wrote: If people don't like the 'browser2' prefix, I'm open to other suggestions. For all I care, the three directives I suggested could be on the 'browser' namespace, only browser2:page and browser:page clash. So perhaps browser2:page should be named something else. I can't seem to come up with good alternatives, though. I haven't looked closely, but can't we have one whose behaviour changes according to what attributes it has? If old attributes are provided, a deprecation message is sent but the old code is used. Otherwise the new behaviour is in effect. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Is using a convenience base class really that much more complexity for > the user? It's perhaps a little more typing, but it gives you less magic > in return. Less magic is less complexity in a way. Depends on what you mean with "convenience class". I don't mind convenient classes. But if I really need to create one class that does nothing except server as a placeholder for each of my pagetemplates, I wouldn't call that convenient. ;) > So, basically, register pages and all other adapterish things with an > directive? Fine by me :). Pretty much yes. > ... hence the compromise :) Yup. And it seems the compromise was worse than the problem. ;) As Calvin sais: "A good compromise leaves everybody mad". -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
Andreas Reuleaux wrote: On Sun, Apr 23, 2006 at 02:52:14PM +0200, Lennart Regebro wrote: On 4/23/06, Andreas Reuleaux <[EMAIL PROTECTED]> wrote: Sorry, I wonder if you read my suggestion carefully. In particular I suggested having a period where only the new (and ugly) statement is allowed, and only after that to reintroduce the old statment with a new meaning. Yes, so you suggest that we deprecate a statement for a statement that we intent to deprecate. And that just makes no sense. The reason I was suggesting to introduce a new statement (, , ...) with the intent to later deprecate it, was the lack of good notation, at least something that is as good as the original , that is after all how this dicussion thread started. If everyone is fine on this list that is just as good as then I can certainly live with that for a longer time - Philipp expressed some concerns in this thread though (http://mail.zope.org/pipermail/zope3-dev/2006-April/019229.html). Yes, mostly because our nomenclature talks about "pages" all the time. Plus, "publish" is a verb. Most ZCML directives are nouns. I was just suggesting a possible way to allow for a smooth transition and in the long run to aim for the best notation possible. - I am certainly open for discussion though what that best notation is. Same here. Man, there must be some people out there who are smarter than we and can come up with a decent name... To stress the comparison with the Python language once more and to give a concrete example: In Python 2.x we have range() and xrange() In Python 3.y we will have range() with the meaning of the former xrange() That is because xrange() is the better function and range() is the better (simpler) notation. Like Lennart said, Python 2 to 3 is a quantum leap. It's not comparable with Zope 3.3 -> 3.5. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
Lennart Regebro wrote: On 4/23/06, Andreas Reuleaux <[EMAIL PROTECTED]> wrote: Sorry, I wonder if you read my suggestion carefully. In particular I suggested having a period where only the new (and ugly) statement is allowed, and only after that to reintroduce the old statment with a new meaning. Yes, so you suggest that we deprecate a statement for a statement that we intent to deprecate. And that just makes no sense. I agree it would be more confusing than anything else. If people don't like the 'browser2' prefix, I'm open to other suggestions. For all I care, the three directives I suggested could be on the 'browser' namespace, only browser2:page and browser:page clash. So perhaps browser2:page should be named something else. I can't seem to come up with good alternatives, though. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Lennart Regebro wrote: On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: A publishable view must provide IBrowserPublisher. We happen to call such browser views "pages". This requirement and this nomenclature has worked well since very early days of Zope 3. I'm not suggesting to change that. I'm just suggesting to change the awareness of that fact for the end user to make everything less magical. Sure. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Hmm, the goal wasn't to make things more complex. If you think that having three directives, each of which does exactly one thing, is more complex than having one directive that does everything together, I must have failed somehow. Well, yes I do. I see that the code for the directives are less complex but it gets more complex for the users of these directives. The complexity has just moved. So it´s not actually more complex, just in different ways. Is using a convenience base class really that much more complexity for the user? It's perhaps a little more typing, but it gives you less magic in return. Less magic is less complexity in a way. I think browser2:page is an extremely easy directive. Because it's so stupid. It will eat an IBrowserPage factory and register it as an adapter. Implementing IBrowserPage OTOH is also dead simple given our convenient base class. Just implement __call__. Perhaps I'm too deep into the matter to see the aroused complexity. What's wrong with having to implement a specific attribute (__call__)? Because it means that wee need to have one class per view. And that in turn means that we either have to have a lot of essentialy empty classes, Not sure what you mean by that. One page is implementing by one class. The "implementation" of the page is in __call__. So I can't see how these classees would be empty. They at least have a __call__ method. or create magical classes dynamically. That in turn creates this complexity. I´m trying to see if we can get rid of it. Be my guest. The browser2:pagesFromClass were added as part of the compromise so that people can conveniently put code for pages that use a lot of common code on one class. I admit that this will still have to use magic, however, there people explicitly choose to use magic. Currently they almost have no choice. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. #2 is what I'm suggesting so I'm not quite certain how to count the -1 from above. No, you are suggesting to refactor them and maybe rename them. My #2 is to deprecate them completely and do nothing else. So, basically, register pages and all other adapterish things with an directive? Fine by me :). Which, I think, is what you wanted to do before, but loads of people (including me ;) ) screamed. ... hence the compromise :) Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > A publishable view must provide IBrowserPublisher. We happen to call > such browser views "pages". This requirement and this nomenclature has > worked well since very early days of Zope 3. I'm not suggesting to > change that. > > I'm just suggesting to change the awareness of that fact for the end > user to make everything less magical. Sure. > > All this proposal does it to try to split that magic up into three > > different ZCML statements to make it slightly less complex. It is > > after all a compromise. I would like to see if there s a way we > > instead can actually fix the problem completely. > > Hmm, the goal wasn't to make things more complex. If you think that > having three directives, each of which does exactly one thing, is more > complex than having one directive that does everything together, I must > have failed somehow. Well, yes I do. I see that the code for the directives are less complex but it gets more complex for the users of these directives. The complexity has just moved. So it´s not actually more complex, just in different ways. I guess you can say that's why I´m -1 on the proposal. I'd like to get rid of complexity, not move it around. :-) > Fixing the problem completely is certainly a pious wish, but we may > never get there. Hence the compromise. I'm trying to improve what can be > improved now. Just see how much of a fuss this tiny proposal made already. I know what you are trying to do, and I'm not saying that's a bad thing. I'm just saying that I don't really think this proposal does it, or at least not enough. :-) All I'm doing is trying to point out why this is so hard to fix, and maybe try to see if there is an alternative route. > > There are two parts to that requirement. > > 2a: Be a class that implements IBrowserView. > > IBrowserPublisher Right, sorry. > > 2b. Be callable. > > Which is expressed by IBrowserPage. Basically, IBrowserPage extends > IBrowserPublisher by a __call__ method. > > > Can we get rid of one of these? > > Why? Because that would fix the problem. > What's wrong with having to implement a specific attribute (__call__)? Because it means that wee need to have one class per view. And that in turn means that we either have to have a lot of essentialy empty classes, or create magical classes dynamically. That in turn creates this complexity. I´m trying to see if we can get rid of it. > > Summary: I think that we at this moment should do either: > > 1. Nothing. > > 2. Remove browser:page and browser:pages completely. > > 3. Remove requirement 2a or 2b on views. > > #2 is what I'm suggesting so I'm not quite certain how to count the -1 > from above. No, you are suggesting to refactor them and maybe rename them. My #2 is to deprecate them completely and do nothing else. Which, I think, is what you wanted to do before, but loads of people (including me ;) ) screamed. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On Sun, Apr 23, 2006 at 02:52:14PM +0200, Lennart Regebro wrote: > On 4/23/06, Andreas Reuleaux <[EMAIL PROTECTED]> wrote: > > Sorry, I wonder if you read my suggestion carefully. In particular > > I suggested having a period where only the new (and ugly) statement > > is allowed, and only after that to reintroduce the old statment > > with a new meaning. > > Yes, so you suggest that we deprecate a statement for a statement that > we intent to deprecate. And that just makes no sense. The reason I was suggesting to introduce a new statement (, , ...) with the intent to later deprecate it, was the lack of good notation, at least something that is as good as the original , that is after all how this dicussion thread started. If everyone is fine on this list that is just as good as then I can certainly live with that for a longer time - Philipp expressed some concerns in this thread though (http://mail.zope.org/pipermail/zope3-dev/2006-April/019229.html). I was just suggesting a possible way to allow for a smooth transition and in the long run to aim for the best notation possible. - I am certainly open for discussion though what that best notation is. To stress the comparison with the Python language once more and to give a concrete example: In Python 2.x we have range() and xrange() In Python 3.y we will have range() with the meaning of the former xrange() That is because xrange() is the better function and range() is the better (simpler) notation. > > Such things (reintroduction of a known notation with a new meaning) > > are happening in the Python language itself as I pointed out, > > so I assume it makes some sense. > > Python 3 is to Python 2 and Zope 3 is to Zope 2. A big and > intentionally largely incompatible rewrite, and can not be compared > with this. See above. -Andreas > > -- > Lennart Regebro, Nuxeo http://www.nuxeo.com/ > CPS Content Management http://www.cps-project.org/ > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/reuleaux%40web.de > > > > !DSPAM:444b82a6122645714319380! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Lennart Regebro wrote: I'm -1 on this proposal. I agree, browser:page is too complex and magic. The reason for it's complexity and magic is that there are two things that clash: 1. The need to have simple and easy view registrations, and 2. The requirement that view must be callable classes. A publishable view must provide IBrowserPublisher. We happen to call such browser views "pages". This requirement and this nomenclature has worked well since very early days of Zope 3. I'm not suggesting to change that. I'm just suggesting to change the awareness of that fact for the end user to make everything less magical. The second requirements mean that you have to create a lot of callable classes that do nothing particularily useful. There can created by the programmer, which is a lot of stupid work. Requirement 1 sais that we shouldn't do that. The result is that we then create them automatically which creates a lot of hard to understand magic. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Hmm, the goal wasn't to make things more complex. If you think that having three directives, each of which does exactly one thing, is more complex than having one directive that does everything together, I must have failed somehow. Fixing the problem completely is certainly a pious wish, but we may never get there. Hence the compromise. I'm trying to improve what can be improved now. Just see how much of a fuss this tiny proposal made already. Evidently we do NOT want to get rid of requirement 1, because then people will again find making views a pain. Therefore, lets think about f we can get rid of requirement 2. There are two parts to that requirement. 2a: Be a class that implements IBrowserView. IBrowserPublisher 2b. Be callable. Which is expressed by IBrowserPage. Basically, IBrowserPage extends IBrowserPublisher by a __call__ method. Can we get rid of one of these? Why? For example, could we have an optional argument on view registration that tells the view which attribute to be called? (I know, that's not possible when views are just adapters, it's an example). What's wrong with having to implement a specific attribute (__call__)? After all, having well-defined APIs means that you have to implement certain attributes/methods. We do and require it for lots of other stuff, why can't we require it for browser pages? It makes everything darn simple if you can tell people "Just implement IBrowserPage" when they ask how to write a publishable browser view. If we can't get rid of either 2a or 2b, we will either have to sacrifice requirement 1, and making views will be a boring pain, or have to have a lot of hard to understand magic with dynamically created classes. If we want to sacrifice the ease of registration, which this proposal does to a small extent Does my proposal really make registration harder? I think we in that case should go all the way and remove the browser:page completely. It can in that case be moved out to a separate product for people like me, who want it. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. #2 is what I'm suggesting so I'm not quite certain how to count the -1 from above. #3 I don't understand. Views are adapters. Publishable views need to provide IBrowserPublisher (this an old requirement in Zope3, you just never saw it because browser:page did magic). IBrowserPage makes IBrowserPublisher-compliance easy by offering you __call__ to implement. I can't imagine how it can get simpler than that. But I'm open to constructive suggestions. Thanks for your comments. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On 4/23/06, Andreas Reuleaux <[EMAIL PROTECTED]> wrote: > Sorry, I wonder if you read my suggestion carefully. In particular > I suggested having a period where only the new (and ugly) statement > is allowed, and only after that to reintroduce the old statment > with a new meaning. Yes, so you suggest that we deprecate a statement for a statement that we intent to deprecate. And that just makes no sense. > Such things (reintroduction of a known notation with a new meaning) > are happening in the Python language itself as I pointed out, > so I assume it makes some sense. Python 3 is to Python 2 and Zope 3 is to Zope 2. A big and intentionally largely incompatible rewrite, and can not be compared with this. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On Sun, Apr 23, 2006 at 09:36:37AM +0200, Lennart Regebro wrote: > On 4/23/06, Andreas Reuleaux <[EMAIL PROTECTED]> wrote: > > I think the naming vs. vs. ... is > > not that important as the original name can be > > reintruduced (with the meaning of the new concept) after the > > deprecation period, i. e. I am thinking of having two (maybe three or > > four) different periods: > > We can't deprecate a zcml statement for the introducion of a statement > that we know is gonna be deprecated. It makes no sense. Sorry, I wonder if you read my suggestion carefully. In particular I suggested having a period where only the new (and ugly) statement is allowed, and only after that to reintroduce the old statment with a new meaning. Such things (reintroduction of a known notation with a new meaning) are happening in the Python language itself as I pointed out, so I assume it makes some sense. -Andreas > > -- > Lennart Regebro, Nuxeo http://www.nuxeo.com/ > CPS Content Management http://www.cps-project.org/ > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/reuleaux%40web.de > > > > !DSPAM:444b6fce120951804284693! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Update: The browser:page compromise
On 4/23/06, Andreas Reuleaux <[EMAIL PROTECTED]> wrote: > I think the naming vs. vs. ... is > not that important as the original name can be > reintruduced (with the meaning of the new concept) after the > deprecation period, i. e. I am thinking of having two (maybe three or > four) different periods: We can't deprecate a zcml statement for the introducion of a statement that we know is gonna be deprecated. It makes no sense. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
