[Zope3-dev] Re: Reminder: Feature Freeze May 1
Jim Fulton wrote: Don't forget that the feature freeze for the June release is May 1! That is only 10 days away! New features should be check in in a *stable* form by then. While we won't necessarily do a beta release then, anything checked in for the new release must be ready for a beta release when it is checked into the trunk. What's the ETA for merging the various branches? Yours in Z3, Phil's in Z2, maybe Five... ? I'd rather have them sooner than later. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +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: Reminder: Feature Freeze May 1
Florent Guillaume wrote: Jim Fulton wrote: Don't forget that the feature freeze for the June release is May 1! That is only 10 days away! New features should be check in in a *stable* form by then. While we won't necessarily do a beta release then, anything checked in for the new release must be ready for a beta release when it is checked into the trunk. What's the ETA for merging the various branches? Yours in Z3, Phil's in Z2, maybe Five... ? I'd rather have them sooner than later. I'll merge mine as soon as I can. There's some chance that that will happen today. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.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 browser:page 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 Designhttp://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
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
Re: [Zope3-dev] RFC: The browser:page compromise
Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise I've long been thinking about how to make browser:page / simpler and less magical. Some radical ideas weren't received well and I couldn't convince even myself 100% that they were the way to go. Other brainstormings were dead ends. I therefore call this proposal a compromise. It simplifies, but it shouldn't annoy (Tres...). Note that I'm specifically only addressing browser:page /, not browser:view /; nor am I coming up with a framework for dealing with forms and their handlers (Jeff...). 'Nuff said. Your turn :) I've been focussed on my adapter branch so didn't pay attention to this until I saw some discussion about it on IRC last night. :) I've only skimmed this thread. I don't have time for more. I'm -1 on this proposal. The browser2:pageTemplate and browser2:pagesFromClass directives don't really gain anything, because they still generate classes. They don't have to generate classes. They could just do clever factory construction to avoid class creation. We can arrange for browser:page to not generate a class when used as you propose using browser2:page. Note that there are two sources of magic in browser:page: - providing a template - specifying a permission When adding the ability to specify a template, I chose to use class generation. Another approach would have been to augment the factory. This is the approach that Tres described. This is what the adapter directive does when a permission is provided. Basically, it replaces the original factory with a factory that calls the proginal factory and then adds the security information to the generated instance. We would need to do this for browser2:page as well. This too is magic, but presumably it is less magic than generating a class. I suggest we add a factory attribute to the browser:page directive. When a factory attribute is used. then a class would not be generated. The bahavior would be much as you've proposed for browser2:page. I would allow a template to be provided. If a template is provided, then the given factory computes the object that is bound to the template. In this case, the view object is actually a form of bound template. Of course, it would be an error to use the class and factory options together. It would also be an error to use the factory option with the attribute option. As far as best practices are concerned, people could advocate for using factory rather than class. I would certainly support this point of view. :) Eventually, we might even deprecate use of the class attribute. BTW, I would also like to see the for attribute made optional, as it is for the adapter directive. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
