[Zope-CMF] Re: RFC: browser views and memoization

2006-01-16 Thread Vladimir Iliev
yuppie wrote: Hi! The skin scripts for complex forms in CMF like folder_contents are currently big monolithic blocks of code. All the values needed in the template are computed in a predefined order that makes sure expensive tasks like querying the catalog or listing folder contents are

[Zope-CMF] CMF Collector: Open Issues

2006-01-16 Thread tseaver
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - Discussion replies removal, [Accepted] http://www.zope.org/Collectors/CMF/391 - 'CMF Default Workflow [Revision 2]' Extension broken,

[Zope-CMF] Re: RFC: browser views and memoization

2006-01-16 Thread yuppie
Hi Whit! whit wrote: yuppie wrote: I ended up using this method as decorator for most methods: def memoize(func): memo = {} def memoized_func(*args): if args not in memo: memo[args] = func(*args) return memo[args] return memoized_func Are there

Re: [Zope-CMF] Re: Re: [Plone-developers] Re: Re: The components of Archetypes

2006-01-16 Thread Christian Scholz
Hi! Martin Aspeli wrote: Hi Alec, I see that plone_schemas covers most of what I was asking about, which is great :) I took a look at plone_schemas' example type. I can't get it to install (Zope won't start, some conflict of versions, I'm sure), but looking at the code, I notice that

[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Philipp von Weitershausen
Martijn Faassen wrote: In an earlier thread I argued that this modified version of Five 1.2 should perhaps get a new name to indicate the additional feature. Do you all think that this would be feasible, or should we just go on with 1.2.1? If we give it a new name, the question is obviously

Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Jens Vagelpohl
On 16 Jan 2006, at 11:26, Philipp von Weitershausen wrote: Martijn Faassen wrote: Are we really sure a further Five feature release for Zope 2.8 is actually needed? What's happening with CMF and Plone in this regard? Is Plone 2.5 still targeting Zope 2.8? Yes. Is CMF? CMF 1.6 is. I

[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Philipp von Weitershausen
Tim Hicks wrote: The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. You can turn that

Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Sidnei da Silva
On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | Then again, Zope 2.9 is stable (people don't really trust a .0 | release) and we could release Five 1.4 any time after Rocky is done. So | there's really no reason for people NOT to upgrade, I guess. There is at least

Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Philipp von Weitershausen
Sidnei da Silva wrote: On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | Then again, Zope 2.9 is stable (people don't really trust a .0 | release) and we could release Five 1.4 any time after Rocky is done. So | there's really no reason for people NOT to upgrade, I

[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Lennart Regebro
On 1/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: It's a fundamentally different way of developing and installing products. Therefore it's good to ask why we would want to expose such a fundamentally new feature for Zope 2.8. Do we really want to start explaining to people that My product

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Philipp von Weitershausen
Martijn Faassen wrote: Is Plone 2.5 still targeting Zope 2.8? Yes. Yes to which question? Yes to Is Plone 2.5 still targeting Zope 2.8. Perhaps these use cases aren't driven by Plone/CMF core and some other packages would like to use this in Zope 2.8? Can they be identified? The

Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Sidnei da Silva
On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote: | Sidnei da Silva wrote: | On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | | Then again, Zope 2.9 is stable (people don't really trust a .0 | | release) and we could release Five 1.4 any time

Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Philipp von Weitershausen
Sidnei da Silva wrote: On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote: | Sidnei da Silva wrote: | On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | | Then again, Zope 2.9 is stable (people don't really trust a .0 | | release) and we

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Rocky Burt
Martijn Faassen wrote: Okay, I read CMF 2.0 is targetting Zope 2.9 now, but Plone is, as of yet, still targeting CMF 1.6. Whether they really will I guess also depends on Plone's commitment to release this spring and suppress changing things around. I think there are two reasons Plone 2.5 is

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Rocky Burt
Philipp von Weitershausen wrote: Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Rocky Burt
Philipp von Weitershausen wrote: Yes. In fact, if one exists, it's automatically put on your PYTHONPATH for that instance. I think we should make Zope 2.8+ instance skeleta grow a lib/python directory. This can hardly be considered a feature, so we should be able to sneak it into the next

[Zope-CMF] Re: GenericSetup zcml registration of profiles

2006-01-16 Thread Rocky Burt
Tres Seaver wrote: Florent Guillaume wrote: I propose to add a new directive registerProfile in GenericSetup so that profile registration can be done through zcml. What namespace should I use? How about 'http://namespaces.zope.org/genericsetup'? Ohh, could I state the obvious and suggest

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Florent Guillaume
Philipp von Weitershausen wrote: The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Rocky Burt
Florent Guillaume wrote: Rocky how does your effort relate to Basket by the way? ISTR that Basket aims at answering a similar use case. Basket is for distributing zope2 products in egg form. I've been working with Chris closely on it. In fact I added the support that allows people to write

[Zope-CMF] Re: GenericSetup list property purge

2006-01-16 Thread Florent Guillaume
Florent Guillaume wrote: I recently introduced the fact that in extension profiles list properties aren't purged by default. But really this introduces problems, as if you simply import an extension profile twice you'll get all you lists doubled. So I think I'll use the opposite semantic,

[Zope-CMF] Re: GenericSetup zcml registration of profiles

2006-01-16 Thread Florent Guillaume
Rocky Burt wrote: Tres Seaver wrote: Florent Guillaume wrote: I propose to add a new directive registerProfile in GenericSetup so that profile registration can be done through zcml. What namespace should I use? How about 'http://namespaces.zope.org/genericsetup'? Ohh, could I state

Re: [Zope-CMF] Move GenericSetup out of CMF

2006-01-16 Thread Jens Vagelpohl
On 15 Jan 2006, at 18:38, Jens Vagelpohl wrote: Before cutting the CMF 2.0 alpha GenericSetup should move out of the CMF repository. I'm volunteering to do that. Is there anything or anyone I need to wait on before doing so? Everyone: I'll be working on this tonight. Please get all

[Zope-CMF] future of getToolByName

2006-01-16 Thread whit
I remember some discussion of this in the past. Transitionally, it would be helpful to be able to register local utilities to a tool name, and then have getToolByName spit out a deprecation warning and return an appropriate object. thoughts? comments? does this exist somewhere already? -w

Re: [Zope-CMF] Move GenericSetup out of CMF

2006-01-16 Thread Jens Vagelpohl
On 16 Jan 2006, at 18:28, Jens Vagelpohl wrote: On 15 Jan 2006, at 18:38, Jens Vagelpohl wrote: Before cutting the CMF 2.0 alpha GenericSetup should move out of the CMF repository. I'm volunteering to do that. Is there anything or anyone I need to wait on before doing so? Everyone:

[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8

2006-01-16 Thread Rob Miller
i'm -1 for expending extra effort to get this working on Zope 2.8. new features should arrive w/ new versions. Plone 2.5 will require CMF-1.6, which will work w/ both Z2.8 and Z2.9. those who want this feature can run Plone on Z2.9, no prob. i'd much rather see us focus our efforts on

[Zope-CMF] Re: future of getToolByName

2006-01-16 Thread Rocky Burt
whit wrote: I remember some discussion of this in the past. Transitionally, it would be helpful to be able to register local utilities to a tool name, and then have getToolByName spit out a deprecation warning and return an appropriate object. thoughts? comments? does this exist somewhere