[Zope-CMF] Re: trouble applying extension profiles
Lennart Regebro wrote: On 3/31/06, Rob Miller <[EMAIL PROTECTED]> wrote: i've committed this on the 1.6 branch. this is a pretty significant change in behaviour. before, a reimport would delete EVERYTHING that was not explicitly protected by the ".preserve" file of the currently active profile. now, content will _only_ be deleted if it is in the "structure" hierarchy so that it will be recreated. this means that removing something from the structure folder and rerunning the import step will NOT remove content, you'll have to do so by hand. How about some sort of ".delete" file for that? great idea. i've spent as much time as i can on it this week, but if nobody else gets to it i might be able to implement this next week. -r ___ 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
Re: [Zope-CMF] Re: trouble applying extension profiles
On 3/31/06, Rob Miller <[EMAIL PROTECTED]> wrote: > i've committed this on the 1.6 branch. this is a pretty significant > change in behaviour. before, a reimport would delete EVERYTHING that > was not explicitly protected by the ".preserve" file of the currently > active profile. now, content will _only_ be deleted if it is in the > "structure" hierarchy so that it will be recreated. this means that > removing something from the structure folder and rerunning the import > step will NOT remove content, you'll have to do so by hand. How about some sort of ".delete" file for that? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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: trouble applying extension profiles
Rob Miller wrote: Jens Vagelpohl wrote: There's a bug filed already: http://www.zope.org/Collectors/CMF/404 I have asked Tres to look at it since he did most of the content-related stuff but haven't heard from him. If you know a solution, by all means, go for it. okay, i've got an implementation locally that will only remove content if the content is something that will be recreated by the current import step. the current behaviour is catastrophic; it removes all content from the site root down unless it is explicitly marked as 'preserved' by the currently active configuration! i've committed this on the 1.6 branch. this is a pretty significant change in behaviour. before, a reimport would delete EVERYTHING that was not explicitly protected by the ".preserve" file of the currently active profile. now, content will _only_ be deleted if it is in the "structure" hierarchy so that it will be recreated. this means that removing something from the structure folder and rerunning the import step will NOT remove content, you'll have to do so by hand. i think this is preferable to the other approach, because it was far too easy to have everything in your site wiped out; i think content deletion should be treated very conservatively. since this is a behavioural change, though, i'd like to get some feedback to make sure this works for folks before moving further. can anyone else who cares about this take a look at what i've done and let me know if that works for you? if this works for everyone, i'll merge it into the 2.0 branch and the trunk. thx, -r ___ 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: How do deal with cmfcatalog-wrapped objects?
yuppie wrote:
> Andreas Jung wrote:
>> we have a CMF-based application where I am trying to migrate from
>> TextIndexNG 2 -> 3.
>>
>> For a content-type class A I have configured an adapter to implement
>> IIndexableContent. However when the object is reindexed CMF wraps
>> the object as IndexableObjectWrapper which by itself implements
>> the IndexableObjectWrapper interface. The low-level indexer of TXNG
>> get the wrapped object and has no idea what to do with the object
>> since the interface of the wrapper shadows the interface of the
>> wrapped object.
>> Any idea how to deal with this problem?
>
> I'm currently fighting with the same issue. And I was in the process of
> writing a mail to the Zope-CMF list when your mail came in. AFAICS this
> is more a CMF issue than a Five issue, so I add Zope-CMF to the
> recipients list.
>
>
> Just for the records, I'm sure you already figured that out yourself:
>
> Plone 2.1 doesn't have this issue because it has no interface
> declaration on its ExtensibleIndexableObjectWrapper. If the wrapper
> doesn't have its own __providedBy__ attribute the __getattr__ method
> looks it up in the wrapped class, making the interface declarations
> completely transparent.
>
> Plone 2.5 has an interface declaration so I guess it has the same
> problem as the CMF.
>
>
> The quick and dirty solution would be to remove the interface
> declaration from the wrapper. The clean solution would be to make sure
> that all the interfaces that are actually provided - the wrapper
> interface *and* the interfaces of the wrapped object - can be looked up.
> But implementing that seems to require deeper knowledge of the interface
> machinery than I have.
This problem has already been solved in Zope 3. There we like to wrap
objects that don't provide ILocation (__parent__ and __name__
attributes) in something that *does* provide ILocation. The resulting
object is a proxy for the original object and in addition that it
provides __parent__ and __name__ attributes. The proxy provides whatever
the original object provides plus ILocation.
We call this concept a /decorator/. This is not to be confused with
Python 2.4's function decorators. In Zope 3's case, think of decorator
as a proxy that also adds stuff to the object (e.g. the ILocation API).
Hence, it decorates the original object, like a Christmas tree if you will.
There are two options:
1. I think for the long term, IndexableObjectWrapper could be made a
decorator. This works as follows:
from zope.proxy import getProxiedObject
from zope.app.decorator import Decorator
class IndexableObjectWrapper(Decorator):
def allowedRolesAndUsers(self):
ob = getProxiedObject(self)
allowed = {}
for r in rolesForPermissionOn(View, ob):
allowed[r] = 1
localroles = _mergedLocalRoles(ob)
for user, roles in localroles.items():
for role in roles:
if allowed.has_key(role):
allowed['user:' + user] = 1
if allowed.has_key('Owner'):
del allowed['Owner']
return list(allowed.keys())
2. In the short term we can apply the following trick
(IndexableObjectWrapper needs to be a new style class!):
from zope.interface import providedBy
from zope.interface.declarations import ObjectSpecificationDescriptor
from zope.interface.declarations import getObjectSpecification
from zope.interface.declarations import ObjectSpecification
class IndexableObjectSpecification(ObjectSpecificationDescriptor):
def __get__(self, inst, cls=None):
if inst is None:
return getObjectSpecification(cls)
else:
provided = providedBy(inst.__ob)
cls = type(inst)
return ObjectSpecification(provided, cls)
class IndexableObjectWrapper(object): # new-style!
implements(...) # it can implement as much as it wants
__providedBy__ = IndexableObjectSpecification()
...
This is obviously untested, but I'm pretty confident that this would work.
Philipp
___
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: How do deal with cmfcatalog-wrapped objects?
Hi Andreas! Andreas Jung wrote: we have a CMF-based application where I am trying to migrate from TextIndexNG 2 -> 3. For a content-type class A I have configured an adapter to implement IIndexableContent. However when the object is reindexed CMF wraps the object as IndexableObjectWrapper which by itself implements the IndexableObjectWrapper interface. The low-level indexer of TXNG get the wrapped object and has no idea what to do with the object since the interface of the wrapper shadows the interface of the wrapped object. Any idea how to deal with this problem? I'm currently fighting with the same issue. And I was in the process of writing a mail to the Zope-CMF list when your mail came in. AFAICS this is more a CMF issue than a Five issue, so I add Zope-CMF to the recipients list. Just for the records, I'm sure you already figured that out yourself: Plone 2.1 doesn't have this issue because it has no interface declaration on its ExtensibleIndexableObjectWrapper. If the wrapper doesn't have its own __providedBy__ attribute the __getattr__ method looks it up in the wrapped class, making the interface declarations completely transparent. Plone 2.5 has an interface declaration so I guess it has the same problem as the CMF. The quick and dirty solution would be to remove the interface declaration from the wrapper. The clean solution would be to make sure that all the interfaces that are actually provided - the wrapper interface *and* the interfaces of the wrapped object - can be looked up. But implementing that seems to require deeper knowledge of the interface machinery than I have. So if nobody can come up with a patch for the clean solution I propose just to remove the interface declaration in CMF. An alternative approach would be to modify TextIndexNG and try to unwrap the object if no adapter can be found. But that would mean that TextIndexNG would depend on the knowledge of CMF specific implementation details. Cheers, Yuppie ___ 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] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - "CachingPolicyManager: Make Max-Age parameter dynamic", [Accepted] http://www.zope.org/Collectors/CMF/405 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "CMFSetup: Workflow Tool export fails with workflows which have scripts", [Pending] http://www.zope.org/Collectors/CMF/373 - "CMFCore.Skinnable.SkinnableObjectManager can merge skin data", [Pending] http://www.zope.org/Collectors/CMF/375 - "Proxy Roles does't work for a Script using portal_catalog.searchResults", [Pending] http://www.zope.org/Collectors/CMF/380 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "Content in Setup gets Cleared (Content Import Handler)", [Pending] http://www.zope.org/Collectors/CMF/404 - "workflow interface out of date on 1.5 branch", [Pending] http://www.zope.org/Collectors/CMF/407 - "'except ...: pass' in CMFCore/TypesTool.py:_queryFactoryMethod() nullifies VerboseSecurity", [Pending] http://www.zope.org/Collectors/CMF/410 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "First Day of Week", [Pending] http://www.zope.org/Collectors/CMF/400 - "CachingPolicyManager: Support OFS.Cache.CacheManager", [Pending] http://www.zope.org/Collectors/CMF/408 ___ 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
