Re: [Zope3-dev] Re: Update: The browser:page compromise
On 4/24/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > If we don't adopt a new namespace, perhaps 'browser:published'would > serve as a 'nominalized adjective" noun form of 'browser:publish'. one is called pageTemplate, how aboot calling the other pageAttribute? -- 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> 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).
There is no particular reason to have the new directives in the same
namespace as the old ones, but note that the "convenience prefix"
('browser' vs. 'browser2') is strictly up to the author of the ZCML
file, and not up to the directive author.
Changing the namespace declration at the top of that file would be a
sign that one had adopted the new semantics, which seems like a good
gesture to me.
If we don't adopt a new namespace, perhaps 'browser:published'would
serve as a 'nominalized adjective" noun form of 'browser:publish'.
In any case, I would argue for having the new directives deployed as
alternatives for at least a release *before* we talk about deprecating
the old ones.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETPPr+gerLs4ltQ4RAlVrAJ9oc7be5KfBUJE18IkHd02kwDM3rQCgssxu
IMcJnwDkvchb7Wj13Fft84M=
=CX7u
-END PGP SIGNATURE-
___
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: 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
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
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
Re: [Zope3-dev] Re: Update: The browser:page compromise
On Sat, Apr 22, 2006 at 06:28:35PM +0200, Florent Guillaume wrote: > Philipp von Weitershausen wrote: > >Thanks to everyone who commented on the first versions of this proposal. > >People seem to object changing the old directives. I respect that. > > > >I've therefore changed the proposal to introduce *new* directives. See > >http://dev.zope.org/Zope3/TheBrowserPageCompromise once again. > > If this will be the recommended way of doing things, I'd hate to have a > "browser2" forever or even for the next year. This is just ugly. > > I'd prefer to user either a clean new prefix, or a new name in the > browser namespace, for example . > 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: * during the deprecation period both concepts coexist with different notations and (, ...) allowing for smooth transitions * maybe some period where only the new concept is allowed i. e. only (, ...) to really enforce the use of this new concept * can then be reintroduced as a synonym for (, ...) the ugly syntax might be deprecated this time * finally drop the ugly syntax (, ...) Might be interesting to look at how such incompatible changes are introduced to the python language itself, see Guidos slides on Python 3.0 http://www.python.org/doc/essays/ppt/accu2006/Py3kACCU.ppt I. e. during the Python 2.x series new concepts are introduced with a new notation allowing for coexistence with the old concepts e. g. new style classes vs. old style classes xrange() and range() etc. But then in Python 3.x the simple old notations will be reused for the better concepts. I. e. the version number 3.x will make clear: incompatible changes. 2.x and 3.x will be developed in parallel. I am not suggesting Zope 4 yet though. Just my two cents. -Andreas > >Note that > >I'm not mentioning deprecation of the old directives which doesn't mean > >I want to do it. Here is a poll: > > > >* Should the old directives be deprecated? (I think so) > > Yes. > > >* When should that happen? (I'd say now, meaning Zope 3.3) > > ASAP. Dynamic class generation sucks. > > >* When should they disappear? (I'd say in Zope 3.5) > > 1 year after deprecation as usual. > > 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/reuleaux%40web.de > > > > !DSPAM:444aa53e108331203678650! ___ 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: >> Thanks to everyone who commented on the first versions of this proposal. >> People seem to object changing the old directives. I respect that. >> >> I've therefore changed the proposal to introduce *new* directives. See >> http://dev.zope.org/Zope3/TheBrowserPageCompromise once again. > > If this will be the recommended way of doing things, I'd hate to have a > "browser2" forever or even for the next year. This is just ugly. It's not pretty, I give you that. > I'd prefer to user either a clean new prefix, Got any idea? I certainly couldn't come up with anything better than browser2 :). > or a new name in the browser namespace, for example . H. On one hand this makes the purpose of the thing that's registered a bit clearer (published pages vs. unpublished views). On the other hand, goes nicely hand in hand with zope.publisher.browser.BrowserPage and IBrowserPage. And we've been calling these things pages for the longest time as well... >> Note that I'm not mentioning deprecation of the old directives >> which doesn't mean I want to do it. Here is a poll: >> >> * Should the old directives be deprecated? (I think so) > > Yes. > >> * When should that happen? (I'd say now, meaning Zope 3.3) > > ASAP. Dynamic class generation sucks. > >> * When should they disappear? (I'd say in Zope 3.5) > > 1 year after deprecation as usual. 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
[Zope3-dev] Re: Update: The browser:page compromise
Philipp von Weitershausen wrote: Thanks to everyone who commented on the first versions of this proposal. People seem to object changing the old directives. I respect that. I've therefore changed the proposal to introduce *new* directives. See http://dev.zope.org/Zope3/TheBrowserPageCompromise once again. If this will be the recommended way of doing things, I'd hate to have a "browser2" forever or even for the next year. This is just ugly. I'd prefer to user either a clean new prefix, or a new name in the browser namespace, for example . Note that I'm not mentioning deprecation of the old directives which doesn't mean I want to do it. Here is a poll: * Should the old directives be deprecated? (I think so) Yes. * When should that happen? (I'd say now, meaning Zope 3.3) ASAP. Dynamic class generation sucks. * When should they disappear? (I'd say in Zope 3.5) 1 year after deprecation as usual. 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
