Re: [Zope-CMF] Buildout recipe for CMF?
On Dec 13, 2007 5:22 PM, Andreas Jung [EMAIL PROTECTED] wrote: Hi, is there a buildout recipe that can unpack the CMF source archive properly? The problem is basically that the top-level folder contains the products as subdirectories. So the product dirs must be moved or linked. Theres a recipe that can do that, it's called 'plone.recipe.distros'. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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] Move CMF collector to Launchpad (redux)
And, you can add 'aliases' to bugs too, though I haven't actually used this feature myself. You can for example name issue '#2339' as the 'funky-shiny-issue' or whatever you want, I believe. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Move CMF collector to Launchpad (redux)
I'm +1 on the move. Reply-by-email, just to cite one feature, is way more important than full transcript in my scale. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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] Effective Date inconsistencies
On 6/23/07, Alexander Limi [EMAIL PROTECTED] wrote: snip Not so: - EffectiveDate returns a *string* 'None' when it has no value (wtf?) snip At which point I want to ask: Can we fix this in CMF 2.1, so it is possible to get False values from the date objects? The current situation seems pretty ridiculous. I might have missed it if there is a better way, but I couldn't find any. Maybe completely out of context, but have you verified this is a CMF 2.1 issue and not Archetypes? I know Archetypes overrides many of the methods from CMF, and it might get the corner cases like this wrong. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: [dev] removing Zope2 interfaces
On 3/9/07, yuppie [EMAIL PROTECTED] wrote: Sidnei da Silva wrote: One possible ill effect is persistent references to interfaces due to PAS. I've reported that a few days ago, but nobody seems to have noticed. Maybe I wasn't clear: I was talking about oldstyle interfaces using Zope2's Interface package instead of zope.interface. I did not mean any newstyle interfaces of Zope2. I guess that doesn't affect PAS? PAS used old-style interfaces at one point, and stored references to them in __implements__ attributes on persistent objects. I know because I had to write migration code for an app of mine. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: [dev] removing Zope2 interfaces
On 3/9/07, Jens Vagelpohl [EMAIL PROTECTED] wrote: I'm not following, are you saying PAS referred to old-style interfaces defined in the CMF? I wasn't aware of any dependencies there. Not in CMF sorry, just pointing out a general issue. If people have any persistent references to interfaces and your remove those interfaces then stuff might break. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: [Zope-dev] TypesTool speedup
Mutable default values are evil. I would get rid of that. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: tools-as-utilities, merging, releasing, etc
That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Zope 3 events from workflow
I think there was something else that needs handling in this event effort. There's an exception that is raised when an object is moved within a transition to signal the move. That should be converted to an event, and the corresponding exception handling in the WorkflowTool should be converted to a subscriber. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Zope 3 events from workflow
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote: Sidnei da Silva wrote: I think there was something else that needs handling in this event effort. There's an exception that is raised when an object is moved within a transition to signal the move. That should be converted to an event, and the corresponding exception handling in the WorkflowTool should be converted to a subscriber. Potentially, but I would see that as orthogonal to this patch, wouldn't you? I don't have an opinion on that. In fact, I'm on vacation. I shouldn't be reading emails. :) -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Zope 3 events from workflow
Something that strikes me, by looking at this code is that we also want events that map to 'notifySuccess' and 'notifyException' too (ie, ITransitionSuccessEvent and ITransitionFailureEvent), not only 'before'/'after'. (see _invokeWithNotifications). Those could be fired from the 'notifySuccess', etc. And the code that is currently in 'notifySuccess' would move to a subscriber. I guess that 'notifyCreated' could be replaced by a subscriber to 'IObjectCreatedEvent' or equivalent. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Zope 3 events from workflow
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote: I don't think I fully understand the use case or usage of notifySuccess() and notifyException(). They are called by portal_workflow, on the workflow definition. They don't seem to be used in the current code at least. There is at least two cases which you may or may not be aware of. Workflows other than DCWorkflow and multiple workflows. If you have multiple workflows (or even a single workflow with multiple automatic transitions) you will have multiple events being fired. 'notifySuccess' is called at the workflow-tool level, notifying each workflow associated with the object that an action has succeeded, no matter which workflow suceeded in fulfilling the action. The confusing part here is that there's a 'notifySuccess' on the tool itself, and another in the workflow object. From looking at the tests and the code in the workflow tool, it appears that the tool's 'notifySuccess' and friends are never called directly by any internal code, but instead expected to be called by external code performing 'fancy stuff', to deliver notifications to any workflows associated with a certain object, without having to know which workflows are those. That certainly smells like events to me. I agree that maybe this refactoring is lower priority, I'm just making sure it's not forgotten just because the main workflow used is DCWorkflow, and maybe clarifying some not-so-clear use cases beyond DCWorkflow's owns. I think for code *outside* DCWorkflow/portal_workflow the most sensible things to subscribe to would be the IBeforeTransitionEvent and IAfterTransitionEvent events in my patch - you care that a transition is about to happen or has just happened, much like we have script_before and script_after. But you just cover transitions from DCWorkflow. WorkflowTool is not just about DCWorkflow. Where do those stand in the light of events? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Zope 3 events from workflow
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote: I agree that maybe this refactoring is lower priority, I'm just making sure it's not forgotten just because the main workflow used is DCWorkflow, and maybe clarifying some not-so-clear use cases beyond DCWorkflow's owns. Right. It strikes me though, that if there will be a (zero-or-)one-to-one correspondence between subscribers and workflow definitions, then it may be easier to use the template method pattern (kinda) as we do now rather than decouple it with subscribers. Otherwise, you just end up with a few subscribers in separate functions that logically are tightly coupled with the workflow definition. If on the other hand, there is a need for an open ended number of components outside workflow definitions to react to these events, then using zope.event subscribers makes sense. From the use cases I've seen, that's not really the case, though. That is always the case I believe on any default implementation using events. The power of firing the events is on empowering the extensibility of the framework. The decision on firing an event should be based on 'is this event useful outside the framework' not on 'is this event useful inside the framework'. I agree that the internal implementation can just stay as it is, but from an outside perspective, for people extending the framework, having the events being fired there is certainly helpful. New workflow implementations could choose between implementing 'notifySuccess' or using a event subscriber for example. But you just cover transitions from DCWorkflow. WorkflowTool is not just about DCWorkflow. Where do those stand in the light of events? That's a good point. I'm not really clear on where the line goes between WorkflowTool and DCWorkflow. Are state and transition defs a property of WorkflowTool or DCWorkflow? Is WorkflowTool just concerned with abstract actions (named by strings)? state and transition are properties of DCWorkflow, as you don't see any mention of those in the WorkflowTool. Workflow Tool only deals with actions named by strings. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: Zope 3 events from workflow
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote:
Right - that was the question I was asking. *Is* this an event that's
useful outside the framework?
I believe so. For example, a subscriber that wants to know if an
action has succeeded, no matter where/when, so it can purge an
external cache (hint, hint) will want to subscribe to
'IWorkflowActionSuccess', not to I{Before,After}TransitionEvent.
It wants to know if the action succeded, not execute something
before/after the action happens.
It also wants to fire only when the action succeeds, not when an
exception is raised.
Okay. I still think (and I think we agree) that such an event
fundamentally has a different type of audience than the before/after
transition events in DCWorkflow (which use DCWorkflow-specific
information that's generally useful in CMFCore, Plone and elsewhere). I
won't try to do this refactoring in the patch I'm proposing, but of
course it could be done later.
The more I think about it, the more I wish you do it as soon as
possible. It wouldn't take you long, since you have it all in your
head by now.
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
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: Zope 3 events from workflow
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] wrote: Where would this go? My first patch (btw, anyone up for merging it?) was to DCWorkflow. I could make another one to WorkflowTool, I guess, if you can suggest where and what payload it needs (it's hardly difficult to fire an event). That sounds good. We could fire from _invokeWithNotification() at just before (or after) notifyBefore(), notifyException() and notifySuccess(), passing the same parameters + 'w' (the workflow definition) as the first parameter. I was thinking of something like that, but outside the 'for' loops, thus not passing the 'w' (the workflow definition). Or maybe passing 'wfs'. I'd still keep them as separate patches that could be reviewed/merged separately. Sounds good to me. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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] Problems with defaultView/defaultViewable and CMF
I'm having some issues with DynamicType's implementation of 'default view' conflicting (read: overriding) Five's default view. I've posted a message to the z3-five mailing list, but most certainly people from this list will want to comment as well. Here's the message for reference: http://article.gmane.org/gmane.comp.web.zope.z3base.five/182 I'm not exactly sure how to solve this at the moment. -- Sidnei da Silva Enfold Systems, Inc ___ 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] caching policy manager
On Wed, Sep 13, 2006 at 09:15:14AM +0200, Jens Vagelpohl wrote: | It is a long-standing bug that the CMFDefault File index_html (and | download, which is obsolete in newer CMF versions) simply defers to | index_html from OFS.File. That one doesn't know anything about Cache | Policy Managers, it only deals with the Zope ZCacheable cache manager | mechanism. | | If you could, please file a bug report at http://www.zope.org/ | Collectors/CMF/. All that needs to be done is to override index_html | (which I believe was never done because the implementation in | OFS.File is quite a beast - it was much easier to just reuse it). As a workaround you can install the PolicyHTTPCacheManager product and associate your file objects with it. The PolicyHTTPCacheManager provides the ZCacheable mechanism, but when invoked defers to the Caching Policy Manager. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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
RES: [Zope-CMF] CachingPolicyManager and Image/File content
Title: Re: [Zope-CMF] CachingPolicyManager and Image/File content The PolicyHTTPCacheManager is ZPL. I'm willing to donate it's code. -- Sidnei da Silva Enfold Systems, Inc. http://www.enfoldsystems.com De: [EMAIL PROTECTED] em nome de Jens VagelpohlEnviada: qua 5/4/2006 17:40Para: zope-cmf@lists.zope.orgAssunto: Re: [Zope-CMF] CachingPolicyManager and Image/File content -BEGIN PGP SIGNED MESSAGE-Hash: SHA1The combining of Zope's HTTPCacheManager and the CMFCachingPolicyManager is yet another item which really should not bein some standalone thingy but integrated into theCachingPolicyManager itself... I hope to do this in time for CMF 2.1.jensOn 5 Apr 2006, at 21:06, Stefan H. Holek wrote: I have it working fine using the PolicyHTTPCacheManager from CacheFu. http://dev.plone.org/collective/browser/CacheFu/trunk/ PolicyHTTPCacheManager Stefan On 5. Apr 2006, at 15:19, Bert Vanderbauwhede wrote: Hi, I'm currently setting up a CMF site for testing purposes. While configuring the CachingPolicyManager, I discovered that it didn't work for the Image and File content types. However, it worked perfectly for the Document content type. I only got it working for Image and File after I modified the index_html () method in CMFDefault/Image.py and CMFDefault/File.py. Anyone knows what I'm doing wrong? Or is this a known problem? I'm using CMF 1.4.7. Is this problem perhaps solved in a later version? -- Anything that happens, happens. --Douglas Adams ___ 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-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (Darwin)iD8DBQFENCs9RAx5nvEhZLIRAtf0AKCYG8xSa4oZ52MXGYDJuaDPKFDYtwCgumIZ7yM1Js9vAPGirq299TLHrrg==XXfO-END PGP SIGNATURE-___Zope-CMF maillist - Zope-CMF@lists.zope.orghttp://mail.zope.org/mailman/listinfo/zope-cmfSee http://collector.zope.org/CMF for bug reports and feature requests ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
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 one reason: People running python2.3 must switch to python2.4 for Zope 2.9. That's somewhat painful, at least on Windows. I don't recall if OS X comes with Python 2.4 by default. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
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 after Rocky is done. So | | there's really no reason for people NOT to upgrade, I guess. | | There is at least one reason: People running python2.3 must switch to | python2.4 for Zope 2.9. That's somewhat painful, at least on | Windows. | | AFAIK installing multiple Python versions on Windows isn't a problem. | Plus, doesn't Zope 2 ship with its own Python anyways? Yes, the issue is not installing python, but packaging Zope. People building installers for Windows have to have a MSVC 7 and there might be a significant amount of work involved on making all dependencies of those installers work on Python2.4. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: Re: [Plone-developers] Re: Re: The components of Archetypes
On Sun, Jan 15, 2006 at 12:06:43AM -, Martin Aspeli wrote: | So - one problem is that there is a lot of Plone software out there that | just assumes all content types are Archetypes. If you know about software that does this, please speak up. Best I can tell there's no software that depends on content type being Archetypes, though some stuff like the ReferenceBrowser depends on the IReferenceable API. | But beyond that, CMF requires a lot of boilerplate, like above, that I'd | rather not have to remember or deal with. So, what are the options? Does it? I think CMF basically needs a portal_type (I think the class that provides this is DynamicType or something). Other than that the *content type* doesn't need much boilerplate. What you need is to register the factory type on the portal_types tool, but that's not part of the *content type*. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 08:24:56PM +0100, Dieter Maurer wrote: | Paul Winkler wrote at 2005-11-30 10:33 -0500: | ... | When you customize a FSPageTemplate, you get a plain ZopePageTemplate. | So you'll need to find a way to post-process the output of those | without requiring a change to core Zope, or this becomes a Zope | proposal. Unfortunately I haven't a clue how you could avoid that. | | Instead, you change the makeZODBClone (or similar method) | of FSPageTemplate and create a (new) CMFPageTemplate. | (rather than a plain ZopePageTemplate). | | This would be a good thing (not only in the light of Paul's | proposal) as a plain ZopePageTemplate behaves too differently | from a FSPageTemplate (i.e. it is not Caching Policy Manager aware). But then again, neither is FSImage/FSFile and OFS.Image/OFS.File. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] RestrictedPython, TALES Expressions and CMF
(sorry for the cross-post) I'm currently facing an issue that seems to be a result of a bad interaction between CMF, TALES and Restricted Python. The issue currently happens when: 1. A TALES 'Path Expression' in 'Caching Policy Manager' is evaluated 2. The result of evaluating a sub-expression is a Python Script (eg: object/modified where 'modified' is a Python Script) 3. The context as built by CMF doesn't define 'here' What happens in this case is that the call will end up in PageTemplates/ZRPythonExpr.py:call_with_ns, which is reproduced here for your pleasure: def call_with_ns(f, ns, arg=1): td = Rtd() td.this = ns['here'] td._push(ns['request']) td._push(InstanceDict(td.this, td)) td._push(ns) try: if arg==2: return f(None, td) else: return f(td) finally: td._pop(3) Now, given that there has been a decision of deprecating 'here' in favor of 'context', I'm not exactly sure about the fix. CMF seems to create expression contexts in two places off the top of my head: In 'CMFCore/Expression.py' and 'CMFCore/CachingPolicyManager.py'. None of those define 'here' or 'context' but instead just 'object'. In 'Products/PageTemplates/TALES.py', in the 'translate' function, 'here' is also hardcoded, but that should be less of an issue as code reaching into that function *should* have a proper expression context. The question then is, which code is wrong? PageTemplates for relying on 'here' being defined, or CMF for not defining 'here'? I volunteer to provide a fix with tests as soon as someone clarifies which one needs to be fixed. As a reminder, 'actions' as defined by 'portal_actions' tool and anything that derives from 'ActionProviderBase' suffer from the same issue. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] Small CMFCatalogAware refactoring
On Mon, Sep 12, 2005 at 01:46:00PM +0200, Jean-Marc Orliaguet wrote:
| Julien fixed a bug. Only poorly designed software implements hardcoded
| references to paths ('portal_catalog'). And he needed it to implement a
| separate catalog for portlets. So let's move on
Sorry, but I totally disagree with that. CMFCatalogAware is not the
only place that has references to portal_catalog. There are a couple
other references spread around CMF. Either you come up with a CMF-wide
fix and a proposal, or you make that change somewhere else.
I, for once, would instead make 'getToolByName' hookable so that it
can return a different 'portal_catalog' based on whatever constraints
you need to distinguish which catalog to use, and then ensure
'getToolByName' is used all around where a catalog is needed.
For the records, whatever is the plan for Zope 3-ification of the CMF,
the first place that should be touched is 'getToolByName' IMHO.
--
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
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] Small CMFCatalogAware refactoring
On Mon, Sep 12, 2005 at 02:03:24PM +0200, Jean-Marc Orliaguet wrote: | Hi Sidnei | the difference is that portal_catalog is both a tool and a catalog | instance (with its indexes, records...). Other CMF tools are just tools | and their path can well be hardcoded in CMF since they provide only | functionality. That's not good enough of an argument for me. Are you suggesting that in some places it's used as 'catalog' and in some places it's used as 'tool'? If that's the case, then we should identify such places and use different 'tokens' for each use. Eg: 'portal_catalog' and 'portal_catalog_tool' or something. Still, the place to add indirection would be 'getToolByName'. As Tres said above, let's not invent another component architecture. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: [CMF-checkins] SVN: CMF/branches/1.4/CMFCore/ - Backport Jens V. changes to Geoff D.'s Caching Policy Manager branch
On Mon, Sep 12, 2005 at 01:40:35PM +0100, Jens Vagelpohl wrote: | | On 12 Sep 2005, at 13:46, Sidnei da Silva wrote: | | Log message for revision 38449: | | - Backport Jens V. changes to Geoff D.'s Caching Policy Manager | branch | | Sidnei, you're a bit overeager - I am still waiting for feedback from | Geoff! ;) Ups! Should I back out? I've reviewed the changes and they look very good to me. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] Small CMFCatalogAware refactoring
On Mon, Sep 12, 2005 at 02:36:21PM +0200, Jean-Marc Orliaguet wrote: | Still, the place to add indirection would be 'getToolByName'. As Tres | said above, let's not invent another component architecture. | | I agree that the correct of doing it is through the equivalent of a | getUtility(IToolInterface, name=''), but there is a need for this now. Why can't we make it so then? | the _getWorkflowTool() hook was accepted by the way. Why is this different?? I wouldn't say it was accepted, just overlooked. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: [CMF-checkins] SVN: CMF/branches/1.4/CMFCore/ - Backport Jens V. changes to Geoff D.'s Caching Policy Manager branch
On Mon, Sep 12, 2005 at 01:54:38PM +0100, Jens Vagelpohl wrote: | Ups! Should I back out? I've reviewed the changes and they look very | good to me. | | You don't have to back them out, you could always create a second | patch *if* there are any further changes before merging. I'm just | waiting for sign-off from Geoff for that. That's what I thought. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: Small CMFCatalogAware refactoring
On Mon, Sep 12, 2005 at 09:10:02AM -0400, Tres Seaver wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | Jean-Marc Orliaguet wrote: | | then there is a list of hooks that can be migrated to the new | getToolByName() when it materializes. At least this shows the need for | named utilities in CMF. | | Those won't be named utilities; they will be adapters, with | tool-centric interfaces. For code which currently spells the lookup:: | | catalog = getToolByName(some_context, 'portal_catalog') | | I prefer:: | | catalog = ICatalog(some_context) | | rather than:: | | catalog = getUtility(IGenericTool, 'portal_catalog') | | which will permit us to do component-style indirections based on the | type of 'some_context'. And then I think the component architecture supports named adapters no? Maybe I'm just dreaming *wink*. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: CachingPolicyManager improvements checked in to svn
| The z3interfaces tests are based on the assumption that Five is | available if zope.interface is available. Five creates IActionInfo | dynamically on startup. | | That's obviously not true in your setup. Looking again at these tests it | would be more robust to include the interface imports in the try/except | ImportError statement. For the records, I had other tests failing for the same reason in PAS. It's common to have zope.interface but not five if you install twisted in Ubuntu it has a dependency on the python-zope-interface package or something. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] Content Type Registry Improvement
Hi, I'm trying to write a Content Type Registry predicate that needs access to the context to be able to decide what content type to create, however in ContentTypeRegistry, findTypeName, the predicate is not wrapped in acquisition when called. I would like to propose to wrap the predicate into an acquisition context before calling it so that smarter predicates can be created. Here's the proposed change: Index: ContentTypeRegistry.py === RCS file: /cvs-repository/Products/CMFCore/Attic/ContentTypeRegistry.py,v retrieving revision 1.14.10.2 diff -u -r1.14.10.2 ContentTypeRegistry.py --- ContentTypeRegistry.py 23 Apr 2004 21:11:33 - 1.14.10.2 +++ ContentTypeRegistry.py 25 Jul 2005 18:30:04 - @@ -538,6 +538,7 @@ for predicate_id in self.predicate_ids: pred, typeObjectName = self.predicates[ predicate_id ] +pred = pred.__of__(self) if pred( name, typ, body ): return typeObjectName -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: Content Type Registry Improvement
On Mon, Jul 25, 2005 at 09:26:15PM +0100, Jens Vagelpohl wrote: | | On 25 Jul 2005, at 21:06, Tres Seaver wrote: | Looks fine. Can you add it with a test? | | Before that: Move your sandbox to SVN. Don't check into CVS. Ok, will do. Is it worth backporting the fix to 1.4? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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: [dev] failing tests and other unit test issues
| Good question ;) | | All I know is that | | - CMF uses that pattern in all test files | | - 'Products.CMFCore.foo' seems to work with any testing setup | | - with my setup 'CMFCore.foo' doesn't work if I run tests outside test.py Sorry, I meant instead of the try: except, just import from Products.CMFCore.tests.utils as there's another try:except in there. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher Mais informado que gerente de funerária. ___ 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
