[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. and if understand correctly, this is an artefact of views needing to abide by traversal and security. Any tool that does not expressly need security can probably do without acquisition(unless it has code depending on using aquisition for look ups). But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... +1 for removing the "across-the-board" deprecation of 'getToolByName'; I find Kapil's argument convincing here. I think leaving the deprecation for the case where the API has to fall back to raw acquisition to find the tool is pretty reasonable, as it shows the user where the missing registrations are in her site. I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. +1 to undeprecating and slimming lsm. but to echo tres, only the roll back the calls you really have to. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Adding python packages to ProductsPath
Dieter Maurer wrote: yuppie wrote at 2007-1-23 18:55 +0100: ... Yes, I object. This is a hack that resolves the issue just for some special use cases. We need a solution that works with python packages anywhere in the python path. And "packageresources" (http://www.handshake.de/~dieter/pyprojects/packageresources.tgz"; can show a way to do it. An alternative could be the upcoming egg's support for egg local resources. With "packageresources" a python package/module is identified by an url of the form "pypackage:", e.g. "pypackage:Products.CMFCore" or "pypackage:Shared.DC.ZRDB.DA". A resource (e.g. a file or directory) local to a package is identified by an url "pypackage:/", e.g. "pypackage:Products.CMFCore/skins" As you can see: this allows to specifiy location independent skin directories. yeah... I could see something similar being done with setuptools entrypoints and then accessed later by using pkg_resources. Initially we could just assume cmfish eggs are unzippable. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] PersistentComponents is not enough
plone's egg story looks non-existent until next release. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] five.intid, DirectoryViews and savepoints
The __setattr__ magic on DirectoryView surrogate is creating a great deal of issues with five.intid(which uses a zope2 implementation of keyreferences). Main issue here is that the setting of _p_oid, _p_jar and important other persistent vars gets all kinds of screwed up at the time that the object created events get fired. intid uses object created events to register objects. keyreferences need to know the objects oid, and therefore attempts to add the object to the connection and get said info. I'm seeing this trying to add a Plone 2.1 site(CMF 1.5). -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: browser views and memoization
hi yuppie!
good to know about decorators as class vars and I guess that makes sense
since they are created at import rather than instantiation.
def memoize(meth):
def memoized_meth(self, *args):
if not hasattr(self, '_memo'):
self._memo = {}
sig = (meth, args)
if sig not in self._memo:
self._memo[sig] = meth(self, *args)
return self._memo[sig]
return memoized_meth
_memo is now an instance attribute and should be garbage collected with
the view instance. Does that look sane?
I don't care about kwargs and non-hashable args at the moment. I just
want to find out if using a memoize decorator is the right approach for
resolving the problem described in my initial mail.
I think this looks cleaner and more effective than the alternatives.
-w
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: future of getToolByName
howdy lennart! Right, any tool that now exists must directly map unto a local utility, and that local utility must also have the same API. If we in CMF 2.0 feel that most tools should be made into utilities, we could register the utilities with a name, and use the old tool name. getToolByName could then both try local acquicistion, and do a query for a generic interface (ICMFTool?) with the name. this is sort of what I'm thinking. I'd also like to backport whatever we decide on to cmf1.6. The other option is to keep the tools, but also register them as utilities. That would probably need some changes in the utility registration, though, from the primitive implementation that is in 1.3. I'm less for this. one of the big advantages that plone is looking forward to is cleaning out the tool litter out of the portal root. I think forward porting old tools to utilities is acceptable if we don't force the change on developers. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: future of getToolByName
It was the promise that 'getToolByName' would always just do the right thing (TM) so that add-on developers would not have to worry. So why deprecating that now? Am I missing something? that's what I thought too... deprecation may be unnecessary, but the queryUtility api is a bit different than getToolByName. My feeling was that getToolByName should still work, but let you know something else was available. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] future of getToolByName
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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: Hi there, Just to comment on this interchange: Tim Hicks isn't the only one who we'd need to explain a few things to in the new world order. We may end up with people just dumping packages in SOFTWARE_HOME's 'lib/python' directory if we're not careful. I have some worries with the current Zope 3 world, as already expressed in some earlier discussions with Philipp. There are right now too many different ways people package their Zope 3 extensions. I feel your concern about having more than one way to do it. and about this causing some confusion. But drawing line in the sand for features that initially will only benefit developers seems like a bad idea to me. But I think the value in starting align development style in z2 with the rest of the python world outweighs a small spike in support burden. In actuality, the number of products that anyone depends on will not be using this in 2.8, but making it available to 2.8 will give people an opportunity to use this and familiarize themselves. for example, Plone will be on 2.8 for at least another 6 or more months. And some Plone installations, indefinitely longer... an education problem is an education problem now or later. On the issue of where packages go, we do need some conventions and giving zope it's own "golden path" would be a publicity boon as well as easier for everyone. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: browser views and memoization
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 performed
only once (per request).
Trying to convert this into a browser view and to split the code in
several methods I stumbled other the following issue:
If globally needed values are returned by their own method they have to
be computed again and again, although during the short live of a view
class they can be considered static.
One option would be to pre-compute those values in the __call__ method
and to store them in the view object. An other option is to cache the
results.
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 better ways to resolve this?
Will those memo dicts be removed together with the view object or does
this create a potential memory leak? (I'm not very familiar with
decorators.)
that's pretty elegant compared to shoving a multitude of values into the
view. The closest thing to it would be a PEAK binding, but even that
can't handle the variety of situations that keing the memo by function
signature gives you. very nice.
that looks safe; as far as I can tell when the decorated method is
garbage collected with the view, all refs to 'memo' should be reaped..
In python 2.4 you could use frozenset to have keyword support too. I
think something like this would work:
> def memoize(func):
> memo = {}
> def memoized_func(*args, **kwargs):
> sig = (args, frozenset(kwargs.items()))
> if sig not in memo:
> memo[sig] = func(*args, **kwargs)
> return memo[sig]
> return memoized_func
-w
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: The components of Archetypes
So, I think 1 and 2 aren't that far apart sometimes. I agree with this...and I think biggest wins are somewhere in between. I don't necessarily want a compatibility layer, I just want the declarative quality of AT to spit out something I could play with more sensibly using the z3 paradigm. And I want people to be able to get a feel for the power of the z3 way of doing things in small bitesize pieces. Once you can do this, tutorials and documentation make sense, because the investment require before getting a payoff is low. Additionally, I think sometimes doing some of 1 can be beneficial to 2. In particular, it may be worthwhile to start supporting Z3 widgets in Archetypes (I read somewhere that plone_schema makes this possible already? Cool!). In that case, it may make sense to adapt Archetypes to support them, in turn stimulating people to port their widgets, or write new widgets that way at least. That way, they get immediate functionality while doing the right thing for future development, and Z3 gets lots of cool new widgets. +100 There is alot of good stuff in AT, albeit not perfect and sometimes obscured by many man years of expedient cruft. Let's not throw the baby out with bath water just because it's been crying too much. This is an excellent opportunity to take what has work about AT and move it forward and deprecate what is not used or forgotten. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Reference Engine Componentization
sorry for the cross post, but I know there are a number of other reference engines out there and I would like to get input as we look at moving the AT ref engine being a component. here is a rough list of steps: 1) move current storage of references to use IAnnotations for new content / reference classes. Create a layer of indirection, making reference storage a configurable option. 2) refactor UID storage to use IAnnotations 3) implement IReferenceable to replace Referenceable mixin, implement IReference to coexist with Reference class 4) allow for configuration of references as z3 content classes 5) deprecate add / delete hooks, replace with event subscribers 6) convert reference_catalog and uid_catalog to z3 local utilities 7) extend reference_catalog to allow for query by interface. Deprecate query by reference class. 8) deprecate direct access to IReferenceable For this to be truly effective, all calls to the methods currently provided by IReferenceable would need to go through an adapter ie:: >>> MyATObj.getRefs() becomes:: >>> IReferenceable(MyATObj).getRefs() After implementing 1-8, storage, utilities, how references are accessed, hook behavior and what classes are referenceable will be configurable as components. the two primary access mechanisms for reference information are direct catalog query and direct access to the at reference object. Both cataloging refs and returning references is handled by the mixin Referenceable. Ideally, it would be possible to make IRefereable return objects implementing IReference from zemantic, or some other storage capable of fully describing AT style relationships, as well as handling the cataloging of said relationships. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: The components of Archetypes
thanks for starting up this conversation Rocky! I think these assertions are more or less deadon. The next step is charting a path for transition. for CMF, zope3 / five provides lighterweight analogs of AT features. What is currently lacking is a mapping layer to allow AT users to use the zope3 analog in a meaningful way within AT. As I've stated before, I think the process here is similar to how five gradually and systematically replaced functionality in zope2. Maintaining multiple content frameworks for CMF, z3 and AT is a waste of community effort, and I would like to see AT move toward being more of a glue library for components available to all. #1: Personally I believe there is too much boilerplate code required in building plain CMF types. This is the primary reason I find it convenient to use Archetypes, because a lot of that boilerplate code isnt' necessary. Its my opinion that CMF be refactored a bit to minimize this boilerplate in a similar fashion as to Archetypes has done it (which means Archetypes would no longer be any more convenient to build a type in). Bottom line: lets make CMF easier and more convenient to use z3 does a good job of reducing some of this boilderplate: it gives us dublin core and annotations. For obvious reason, it doesn't help much with factory type information. CMF is scheduled to move away from fti iirc, but some sort of localized "site" configuration of 'content types' is a basic requirement of any progeny of CMF. #2: Archetypes schema support has long provided plone developers with a way of defining (in a sensible style) the fields and types of fields created on a content type class. Personally I believe the automatic creation of mutators/accessors to be a negative thing, mentioning that explicit is always better than implicit. I think z3 schema's use of an interface to define accessors and mutators looks pretty good. But regardless, Zope 3 is providing similar support for all persistent objects. And since moving to Zope 3 development techniques is a strong goal of plone and cmf development, why not just build on top of that rather than continuing with our own AT based schema notion? Alec has the right idea here with his plone_schemas product. Bottom line: lets start working with Zope 3 schema's The issue is how to get there without maiming our developers(not an insurmountable problem, just something that needs to be faced). Some basic decoupling of the AT schema from the AT content object and decoupling of the different facets of the schema(View, Marshalling, Storage, Model, etc) are necessary to get there. here is a rough list of steps I see to move toward convergence: 1. return schema and schemata by interface rather than attribute access 2. make at wigets, fields, and validation interchangeable with z3 widgets and fields 3. start deprecating features that impede convergence: auto-generated mutators and accessors, etc 4. deprecate widgets, storage, marshalling, etc in the schema. Move the declaration of this behavior elsewhere. The AT schema is really a system for configuration and we should treat it like that, whether it be treating old schemas inclusion of view data and storage as default options, or moving schema operations to paradigms configurable by zcml. #3: Widgets is one area where development outside Archetypes has flourished. There has been a plethora of third-party widgets developed that people reuse. Zope 3 also has a widget mechanism and following the thought as in #2 ultimately this is the direction we're moving in. The problem of course at the moment is that Archetypes widget library is quite a bit more diverse than zope 3's widget library so there would definitely need to be some work porting the widgets from AT to zope 3 (plone_schemas also lets you use z3 widgets today). Bottom line: lets start migrating AT widgets to Zope 3 and use existing Zope 3 widgets today see above #4: There has been many a discussion regarding this item. Most people talk about separating out the references engine from Archetypes into its own product. As a primary goal this should allow any CMF based content type to participate in the references logic and not just ones built on Archetypes. Bottom line: lets move the references engine out of AT and into its own product I think this is a prime target and if people are interested in tackling this, I would like to work on it at the snow sprint. see next email ->> So what do you all think? In the CMF community, I know some (all?) of the CMF purists think Archetypes is generally unnecessary and adds a lot of bloat based on feedback I've received. AT is pretty unkempt compared to the likes of CMF or z3 and subject to the looser faster style of plone programmers. Breaking AT down into reusable components may improve adoption, since using some of AT wont necessarily mean you have to use the whole of AT; it will also force improvemen
[Zope-CMF] Re: CMF 1.5 manage_afterAdd & co
Dieter Maurer wrote: Florent Guillaume wrote at 2005-11-9 16:17 +0100: ... To make sure that CMF 1.5.5 will play well with Five 1.2, I have to make sure that no method manage_afterAdd redoes a recursion that one of its base classes was doing, as we have to be prepared to have the base class monkey-patched to use events, and have recursion done with events. ... Does someone have a problem with me doing that in the CMF 1.5 branch? Test with with Archetypes and Plone... Archetypes does a nice dance with "manage_afterAdd". If fact, it gets it wrong (such that objects are indexed much more than once). that dance needs to die. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: proposal for cmf:indexable directive
Namespaces represent communities and their products. Using the CMF namespace means to create a feature that is only supported in CMF (and products built on top of the CMF). without doubt, but these things are not written in stone. Being able to smoothly transfer appropriate behavior into the appropriate community and appropriate codebase is the name of the game here. Currently, Five and Zope2 are agnostic to catalogs, but cmf is not. Hopefully, this will become part of a more general zope3 cataloguing system that can utilize rdflib and other queryable sources. But right now it seems like a cmf thing. I hope CMF 2.0 will focus on making the difference between the CMF and Five/Zope3 smaller. indeed! -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] proposal for cmf:indexable directive
here is a sketch of how a working "indexable" configuration would look. Names subject to improvement. http://namespaces.zope.org/cmf"; xmlns="http://namespaces.zope.org/zope";>
[Zope-CMF] Re: CachingPolicyManager improvements
Agreed. Nevertheless we should focus on lowering the barrier of entry for new CMF contributors. People used to write tests for Zope or Plone will have less trouble if they can use ZopeTestCase. And ZopeTestCase tests are definitely better than no tests at all. and it's included as part of zope now. and plonetestcase is slow because of plone's overhead, not because of zopetestcase. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: small proposal, catalog tool
or even:: and then have the catalog look for all such adapters when indexing content. that seems to make the most sense and requires no extra lingo in the zcml. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: small proposal, catalog tool
doh... could be simpler (no need for factory or permission), just: -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: Flon functionality ported to CMF?
Yes, there certainly is a terrible tool proliferation, probably more painfully in Plone than in the CMF. IMHO it wouldn't be so bad if those were optional components that provide optional functionality, but most of them must be there or the site breaks. exactly. almost every addon has it's own set of tools, and many time these serve functions better served by z3's concept of services (PortalTranforms from AT comes to mind). at least if they were components, extending them would be easier, even though the truly optional tool / utility is rare. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: Flon functionality ported to CMF?
Yes. The current roadmap[1] calls for updating the CMF itself to exploit Z3-via-Five in a number of ways; such a UI would be very useful in that effort. It might even be useful *without* the catalog stuff (but I haven't looked at what the exact dependencies are). A primary reason for the plip was the exposure of apidoc within Plone. Also, iirc, yuppie was talking about creating a more general framework for using stub interfaces, and it would be nice to roll all of these efforts into one at the lowest possible level. re: dependencies, the one dependency that makes Flon currently plone centric is it's dependence on Plone's interface tool, which it extends to allow for the inspection of the new style of interfaces. Implementing this tool as a utility and making it backwardly compatible (ie available from getToolByName) might be useful for everyone, and not further pollute the portal root with damn tool objects. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: small proposal, catalog tool
tackling this problem a little bit ago, I found it helpful to create
adapters that returned values to index rather than gronky objects (see
the first attachment. undoubtably there could be discussion about
whether this is useful or just lazy, but I think it could promote code
reuse and less pointlessly named "adapter" vars cluttering the namespace).
This let me use a simple closure and loop to register adapters for
indexing using plones ExtensibleObjectWrapper:
from Products.CMFPlone.CatalogTool import registerIndexableAttribute
def registerIndexer(idx, iface):
default = None
def indexfx(obj, portal, **kw):
try:
return iface(obj)
except TypeError:
return default
registerIndexableAttribute(idx, indexfx)
iface_idxs = (('index1', ISomeCalledInterface),
('index2', ISomeOtherCalledInterface))
for name, iface in iface_idxs:
registerIndexer(name, iface)
Getting back to pete's points, I think another tool would be overkill,
but something like registerIndexer might work as a directive that could
be associated to content ala:
-w
##
#
# Copyright (c) 2004, 2005 Zope Corporation and Contributors.
# All Rights Reserved.
#
# This software is subject to the provisions of the Zope Public License,
# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
# FOR A PARTICULAR PURPOSE.
#
##
"""
An interface that returns a value if adapter or directly provided object is
callable
"""
from zope.interface.interface import InterfaceClass, adapter_hooks
from zope.interface.interfaces import IInterface
from zope.interface.declarations import classImplements
class CalledInterfaceClass(InterfaceClass):
def _callOrReturn(self, obj):
if callable(obj):
return obj()
else:
return obj
def __adapt__(self, obj):
if self.providedBy(obj):
return self._callOrReturn(obj)
for hook in adapter_hooks:
adapter = hook(self, obj)
if adapter is not None:
return self._callOrReturn(adapter)
classImplements(InterfaceClass, IInterface)
CalledInterface = CalledInterfaceClass("CalledInterface", __module__ =
'Products.calledinterface')
__all__=('CalledInterface')
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
