[Zope-CMF] CMFSetup profile extensions dependencies
I'd like to discuss possible improvements to have profile extensions
check some dependencies. This will require a way to express
dependencies, which in the general case can be extremely complex -- but
we probably don't need that.
Use cases
-
1. When installing CMFDefault:default, I'm offered the extensions
SQLDiscussions and BlogDiscussions, which both change the
portal_discussions tool but are incompatible between each other.
= There may be conflicts between extensions.
2. At a customer I'm installing CPS:default, with the standard extension
CPS:simple_mode (which doesn't make sense with CMF), and finally the
customer-specific extension SomeCustomer:default. Just selecting
Somecustomer:default should get all the required profiles.
= An extension may have required profiles, and this can be cascaded.
3. CPSCalendar:default was coded with requiring CMFDefault:default but
actually CPS:default can also work with it, even if CPSCalendar doesn't
know about it.
= A profile may say that it accepts an extension even if the
extension has explicit requirements and the profile isn't listed
in them.
Proposal
Today a profile can be either BASE or EXTENSION.
I'd like to extend this value to be one of:
- None
Which means a toplevel profile, equivalent to BASE
- {}
Which means a simple extension profile, equivalent to EXTENSION
- {'requires': ('CMFDefault:default', 'CPS:default')}
Which means that this profile can only be installed with
one of the listed profiles.
(Should maybe be 'requires_any' to be clear.)
- {'conflicts': ('Bar:bar',)}
Which means that this profile cannot be installed with any
of the listed profiles.
- {'provides': {'Foo': ('Bar', 'Baz')}}
Which says that this profile can pose as Foo in package Bar and
Baz's requirements. Maybe () could mean for all packages. Maybe
this should also be taken into account by conflicts?
Comments? I'm pretty sure this can be improved in term of expressing the
dependencies, but the basic use cases are real for me.
One of the challenges would be the user interface, of course.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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] Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)
Sidnei da Silva [EMAIL PROTECTED] wrote: Hi, I'm facing a small issue with CMF 1.4 and the new 'feature' in Zope 2.8 of letting exceptions through if getObject fails, instead of returning None. Specifically, in CMFCatalogAware.reindexObjectSecurity (recently introduced by Florent Guillaume if I recall), it assumes getObject() will return None in a failure. Yes, see http://www.zope.org/Collectors/CMF/337 which I'm about to fix. This results in a traceback like this: Module Products.CMFDefault.DiscussionItem, line 311, in createReply Module Products.CMFCore.CMFCatalogAware, line 102, in notifyWorkflowCreated Module Products.CMFCore.WorkflowTool, line 360, in notifyCreated Module Products.CMFCore.WorkflowTool, line 706, in _reindexWorkflowVariables Module Products.CMFCore.CMFCatalogAware, line 81, in reindexObjectSecurity Module Products.ZCatalog.CatalogBrains, line 74, in getObject Module OFS.Traversable, line 232, in restrictedTraverse Module OFS.Traversable, line 181, in unrestrictedTraverse - __traceback_info__: ([], '1113527681') Module Products.CMFDefault.DiscussionItem, line 224, in __bobo_traverse__ AttributeError: 'dict' object has no attribute 'RESPONSE' There's two things going on here: 1. It is wrong in assuming getObject will return None. Well, actually it wasn't, but the carpet has been took away from under us :) I'll change this. 2. If I understand correctly, it's trying to traverse to the newly-created DiscussionItem which though it's indexed, will not be available but two lines after the top-level call, on createReply, line 313. I assume there's a reason for the object to be indexed before being stored, so I won't try to guess what the correct fix is. I'm not sure there's a good reason. This code looks quite dumb to me. It should do a _setObject and _getOb and do the rest of the edit, addCreator, etc. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] test failures
I have strange failures with Zope 2.7 HEAD and CMF 1.4 HEAD:
Running
bin/zopectl test -vv --dir Products/CMFCore test_PortalFolder
works.
But running
bin/zopectl test -vv --dir Products/CMFCore
gives:
==
ERROR: test_invokeFactory
(Products.CMFCore.tests.test_PortalFolder.PortalFolderFactoryTests)
--
Traceback (most recent call last):
File
/home/zopes/zope27head/Products/CMFCore/tests/test_PortalFolder.py,
line 78, in test_invokeFactory
f.invokeFactory( type_name='Dummy Content', id='foo' )
File /home/zopes/zope27head/Products/CMFCore/PortalFolder.py, line
367, in invokeFactory
pt.constructContent(type_name, self, id, RESPONSE, *args, **kw)
File /home/zopes/zope27head/Products/CMFCore/TypesTool.py, line 709,
in constructContent
ob = info.constructInstance(container, id, *args, **kw)
File /home/zopes/zope27head/Products/CMFCore/TypesTool.py, line 388,
in constructInstance
m = self._getFactoryMethod(container)
File /home/zopes/zope27head/Products/CMFCore/TypesTool.py, line 334,
in _getFactoryMethod
raise ValueError, ('Product factory for %s was undefined' %
ValueError: Product factory for was undefined
==
FAIL: test_contentPaste
(Products.CMFCore.tests.test_PortalFolder.PortalFolderTests)
--
Traceback (most recent call last):
File
/home/zopes/zope27head/Products/CMFCore/tests/test_PortalFolder.py,
line 370, in test_contentPaste
assert 'dummy' in sub1.contentIds()
AssertionError
--
Ran 432 tests in 71.072s
FAILED (failures=1, errors=1)
Any ideas ?
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: setSecurityProfile
yuppie [EMAIL PROTECTED] wrote: Florent Guillaume wrote: I'll be changing MemberData.setSecurityProfile to use user._doChangeUser() instead of hitting the attributes directly, if nobody sees a problem with that. Why not userFolderEditUser()? I checked this in (for 1.5 and HEAD). As usual unit tests took the longest time, MemberData is hardly tested at all :( Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMF - PUT_factory - need help!
Eugenio Grytsenko [EMAIL PROTECTED] wrote: I want to maintain the PUT_factory feature in CMFCore and make it more flexible. How can I include my changes in future releases of CMFCore? Thanks. Open a ticket in the CMF Collector with your proposed patch, if you feel your design is ok and has been discussed enough in the mailing-lists. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Skinnable bare except
SkinnableObjectManager.__of__ has this code:
try:
w_self.setupCurrentSkin()
except:
# This shouldn't happen, even if the requested skin
# does not exist.
import sys
from zLOG import LOG, ERROR
LOG('CMFCore', ERROR, 'Unable to setupCurrentSkin()',
error=sys.exc_info())
In an application we're seeing many ConflictErrors wrongly catched here.
I'm changing it to at least reraise the ConflictError directly.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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] CMF 1.5.2
Jens Vagelpohl [EMAIL PROTECTED] wrote: Question to the group: Any problem with starting the CMF 1.5.2 beta cycle this week or next week? No problem, however I'll still be checking in changes to CMFSetup in the next few days. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMFSetup profile changing
In the Properties tab of CMFSetup, you can choose an active site configuration, among the snapshots and the registered profiles. This sets the current context_id for the tool, and loads the import steps, export steps and toolset for that configuration. When you switch to a new base configuration, the import/export steps are loaded on top of the current ones without purging. So for instance if you: - select CMFDefault Site. The import steps now comprise 8 steps. - select CMFCalendar. The import steps now have an additional Various Calendar Settings step. - select CMFDefault Site again (or a third-party base (non-extension) profile). The Calendar step is retained. Is this intended ? If yes, why ? My reasoning would be that when you import a base profile, you want just that, not what was previously there. I'll fix that if we agree it's a bug. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: CVS: CMF/CMFSetup - typeinfo.py:1.26
On 14 Jun 2005, at 17:37, yuppie wrote: Florent Guillaume wrote: Update of /cvs-repository/CMF/CMFSetup In directory cvs.zope.org:/tmp/cvs-serv6342/CMFSetup Modified Files: typeinfo.py Log Message: Use a new XML format for import/export of types, where the properties are generic. Now arbitrary TypeInformation objects can be used, as long as they are configured using properties. [...] -class TypeInfoImportConfigurator(ImportConfiguratorBase): +# BBB: will be removed in CMF 1.6 +class OldTypeInfoImportConfigurator(ImportConfiguratorBase): will be removed in CMF 1.6 doesn't make much sense on HEAD. The HEAD *is* (a pre-release version of) CMF 1.6. Ah right, I should have said CMF 1.7. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMF-head and Zope 2.8
Tres Seaver [EMAIL PROTECTED] wrote: I would like to update the head of CMF to reflect a dependency on Zope 2.8+. In particular, I want to reset any 'import Zope' to 'import Zope2', and begin looking at using Five more directly, without worrying about testing for its absence. The CMF 1.5 branch will thus be the EOL for sites which chose to continue running Zope 2.7.x. Any objections? +1 for me. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: CMFSetup profile changing
By the way will you (or others) be at EuroPython ? It would be nice to discuss plans for CMFSetup face to face. Florent yuppie [EMAIL PROTECTED] wrote: Florent Guillaume wrote: In the Properties tab of CMFSetup, you can choose an active site configuration, among the snapshots and the registered profiles. This sets the current context_id for the tool, and loads the import steps, export steps and toolset for that configuration. When you switch to a new base configuration, the import/export steps are loaded on top of the current ones without purging. So for instance if you: - select CMFDefault Site. The import steps now comprise 8 steps. - select CMFCalendar. The import steps now have an additional Various Calendar Settings step. - select CMFDefault Site again (or a third-party base (non-extension) profile). The Calendar step is retained. Is this intended ? If yes, why ? My reasoning would be that when you import a base profile, you want just that, not what was previously there. I'll fix that if we agree it's a bug. Well. This is still a mess. Loading import/export steps from the profile did make more sense before I added extension profile support. Now I would prefer to register *all* handlers on Zope startup. The handlers are supposed to do nothing if there are no related XML-files in the selected profile. But this rule doesn't work with the provisional handlers in CMFDefault and CMFCalendar because they don't depend on an XML-file. The problem with the fix you proposed is that we currently need a complete set of import/export handlers for snapshots/exports. Switching back to the base profile would reset all handlers and make snapshots incomplete. 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 -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver [EMAIL PROTECTED] wrote: Christian Heimes wrote: Jens Vagelpohl wrote: On a general note, if this is so important I am puzzled that this is coming up now and not *months* ago. CMF 1.5.0 has been released ages ago. Beta testing periods are the time to find and solve these problems, not the middle of the maintenance release cycle... I'm puzzled, too. It looks like nobody has ever used or tested CMFBTreeFolder under CMF 1.5. I suspect the reason is that most people don't use CMFBTreeFolder directly but just mixin BTreeFolder2 with whatever classes they need. At least that's what we do. Agreed. I'll bet that there is a trivial fix which would resolve the issue. I *really* don't like the fact that the CMF-dependent parts got merged into the core Zope product in 2.8; we should remove that, and perhaps land the fixed CMFBTree module in CMFCore. I also support moving CMFBTreeFolder out of the Zope 2.8 core, if we can find a way of doing it with minimal impact (and taking into account that a little impact now is better than a big headache in the future when things diverge). The inclusion of BTreeFolder was good, but nobody thought of the CMFBTreeFolder in it. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Another small plone related change
I didn't see the checkins on the checkins list and they don't appear on the web archive. Christian, could you check that your email address on the zope.org site is the same as the one subscribed to the cmf-checkins list ? Florent yuppie [EMAIL PROTECTED] wrote: Hi Christian! Christian Heimes wrote: + +def _getOAI(self, context, object): +return getOAI(context, object) + +def _getExprContext(self, context, object): +return getExprContext(context, object) I didn't see it this morning, but after reviewing your checkins I believe 'context' is redundant and this should also work: def _getOAI(self, object): return getOAI(self, object) def _getExprContext(self, object): return getExprContext(self, object) Would you mind if I change it that way? 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 -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Conflict between PortalFolder and CMFBTreeFolder
Tres Seaver [EMAIL PROTECTED] wrote: I have another idea. The patch is attached to this mail. In short terms I have renamed PortalFolder to PortalFolderBase subclassed of Folder and created a new PortalFolder class subclassed from OrderedFolder. PortalFolderBase contains nearly all code from PortalFolder. This way it is easy to subclass from PortalFolderBase w/o ordered support. class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): class PortalFolder(PortalFolderBase, OrderedFolder): manage_renameObject = OrderedFolder.manage_renameObject.im_func tpValues = OrderedFolder.tpValues.im_func All tests are running fine. I'm +1 for this, but you can't expect us to release a new CMF 1.5 release by Saturday. If you are OK releasing a Plone 2.1 beta atop CMF 1.5.2b1, then we could probably agree to tag that beta by then. Yvo, Jens, Florent: you were the last ones to chime on on the CMF 1.5.2 thread; would that work for you, assuming we merge Christian's patch? I'm ok with it. Of course there's no problem in making a non-release related tag if it helps checkpointing stuff. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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-checkins] CVS: Products/CMFCore - PortalFolder.py:1.82
I guess on HEAD we could start using super() as we're targetting Zope
2.8 now... Or would that be gratuitous backward non-compatibility ?
Florent
Tres Seaver [EMAIL PROTECTED] wrote:
Modified Files:
PortalFolder.py
Log Message:
- Forward-port Tiran's new base class, PortalFolderBase.
=== Products/CMFCore/PortalFolder.py 1.81 = 1.82 ===
def _checkId(self, id, allow_dup=0):
-PortalFolder.inheritedAttribute('_checkId')(self, id, allow_dup)
+PortalFolderBase.inheritedAttribute('_checkId')(self, id, allow_dup)
if allow_dup:
return
@@ -485,7 +474,7 @@
# Call OFS' _verifyObjectPaste if necessary
if not securityChecksDone:
-PortalFolder.inheritedAttribute(
+PortalFolderBase.inheritedAttribute(
'_verifyObjectPaste')(self, object, validate_src)
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: Moving to CMF 1.5.2
yuppie [EMAIL PROTECTED] wrote: Besides that, I'm a bit confused by the fact that Florent didn't backport his latest CMFSetup changes to the CMF-1_5-branch. Yeah I was waiting to see if I had more changes to do on HEAD before backporting everything at once. I think I'll just backport them today or tomorrow if people think it's ok (again, CMFSetup is a bit of a special case). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Moving to CMF 1.5.2
Jens Vagelpohl [EMAIL PROTECTED] wrote: Besides that, I'm a bit confused by the fact that Florent didn't backport his latest CMFSetup changes to the CMF-1_5-branch. Yeah I was waiting to see if I had more changes to do on HEAD before backporting everything at once. I think I'll just backport them today or tomorrow if people think it's ok (again, CMFSetup is a bit of a special case). Yes please do. As far as I know the Plone guys are very interested in its rapid development as well. That's now merged (genericizing of TypeInfo export). But boy that was painful! I really wish we moved to svn... Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: What is a member?
Tom Dossis [EMAIL PROTECTED] wrote:
http://mail.zope.org/pipermail/zope-cmf/2003-November/019794.html
Florent Guillaume wrote:
What is it really to be a member of a portal ?
1) we have the Member role, but nowhere is it enforced that members
must be Member.
members represent users that are allowed to login to the portal and
use features of the site that are not public. They might have different
global or local Roles.
The 'Member' Role represents a basic set of Permissions common
members have for the site. Sometimes this Role represents the least
common denominator and all members have the 'Member' Role. In other
cases members with Roles like 'Reviewer' or 'Manager' don't have a
'Member' Role. I would not enforce one policy.
That's pretty subtle.
I've added a third party role, 'Customer' to my CMF site. I don't want
this role to 'add portal content'. I have member folder auto creation
'on' for my standard 'Members'. But this means my Customer's also have
a folder object created for them - which I don't want.
Is it simply a case of 'patch' my CMF MembershipTool to only do this
if user.has_role('Member') ... ?
Or should I be looking at it from a different perspective?
That's a reasonable patch, yes, and the right place to do it.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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] CMFSetup: non-ascii text
In many places, CMFSetup exports and imports things like titles and descriptions. For instance, for the workflow states and transitions. These fields can often, outside the USA, contain non-ascii strings. How do we export and reimport them ? 1. We can export by converting them to unicode, and the ZPT will render that as UTF-8. Which charset do we assume ? Anything better than locale.getlocale()[1] or 'latin1' ? 2. When importing, do we set the values (attributes) as unicode, or do we try to re-convert to the above charset... Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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-checkins] CVS: CMF - CHANGES.txt:1.310
Thanks for the cleanups and Event.xml :) Florent Yvo Schubbe [EMAIL PROTECTED] wrote: Update of /cvs-repository/CMF In directory cvs.zope.org:/tmp/cvs-serv21866 Modified Files: CHANGES.txt Log Message: removed CMF 1.5 change from 'HEAD only' section === CMF/CHANGES.txt 1.309 = 1.310 === --- CMF/CHANGES.txt:1.309 Wed Jun 22 09:25:25 2005 +++ CMF/CHANGES.txt Fri Jul 1 11:19:01 2005 @@ -45,10 +45,6 @@ o others (CMFCollector, CMFStaging, CMFTracker, CMFWorkspaces) moved to /CMF_Extras/ -- CMFSetup: the import/export of portal types uses a new XML format - that can hold arbitrary properties, to facilitate subclassing. The - old format is still recognized when importing. - - To document how to create a CMF release from CMF a description is now included in RELEASE.txt at the root of the CMF package. This text can guide release managers or volunteers with the appropriate release -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMFSetup: non-ascii text
On 1 Jul 2005, at 20:17, Dieter Maurer wrote: Florent Guillaume wrote at 2005-7-1 17:19 +0200: In many places, CMFSetup exports and imports things like titles and descriptions. For instance, for the workflow states and transitions. These fields can often, outside the USA, contain non-ascii strings. How do we export and reimport them ? 1. We can export by converting them to unicode, and the ZPT will render that as UTF-8. Which charset do we assume ? Anything better than locale.getlocale()[1] or 'latin1' ? 2. When importing, do we set the values (attributes) as unicode, or do we try to re-convert to the above charset... I think, we should keep all text as Unicode -- even in english speaking environments If this is not an option, the external format should use Unicode and some configuration parameter (Plones uses site_encoding) converts from/to the external Unicode. There's actually little problem for the export, we can always infer an encoding from somewhere, be it locale.getlocale or site_encoding or default_encoding or something like that, and export as UTF-8, the native XML encoding. The problem is on import, you don't really know if a non-ascii string should be stored as unicode or as an encoded str. And the software may break if it gets something it doesn't expect... Our immediate problem was with workflow transition descriptions, which contained accents. In that case, the DCWorkflow code does str() anyway so I know it's a string, but I wanted a general opinion. I can't find the time to fix that before the next 1.5.2 release in any case, so I'll do that later. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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-checkins] CVS: Products/CMFCore/tests/base - testcase.py:1.16
This is awesome by the way, and was sorely missing. We can now have much cleaner tests. Thanks. Florent - Forward-ported testing framework to suppress / examine output from warnings module and from zLOG from 1.5 branch. === Products/CMFCore/tests/base/testcase.py 1.15 = 1.16 === --- Products/CMFCore/tests/base/testcase.py:1.15 Wed Jun 15 10:17:38 2005 +++ Products/CMFCore/tests/base/testcase.py Fri Jul 15 22:31:02 2005 + +class LogInterceptor: + +class WarningInterceptor: + -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Heads up: renaming branches/tags in progress
Ok I'm about to start the renaming of svn branches and tags for CMF into a simpler numerical format. I'll post another message when I'm done, with instructions on how to switch your sandboxes (it's very simple). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Heads up: renaming branches/tags done
Florent Guillaume [EMAIL PROTECTED] wrote: Ok I'm about to start the renaming of svn branches and tags for CMF into a simpler numerical format. I'll post another message when I'm done, with instructions on how to switch your sandboxes (it's very simple). Ok this is done. Branches are now named like so: svn://svn.zope.org/repos/main/CMF/branches/1.4 svn://svn.zope.org/repos/main/CMF/branches/1.5 And tags: svn://svn.zope.org/repos/main/CMF/tags/1.4.7 svn://svn.zope.org/repos/main/CMF/tags/1.5.1-beta2 svn://svn.zope.org/repos/main/CMF/tags/1.5.2 etc. To see all the tags and branches you can do: svn ls svn://svn.zope.org/repos/main/CMF/tags | more svn ls svn://svn.zope.org/repos/main/CMF/branches | more (I haven't renamed everything, only the 1.4 and 1.5 tags and branches.) If you have a current sandbox, say CMF-1_5-branch for example, you'll have to go inside it and do: svn switch svn+ssh://[EMAIL PROTECTED]/repos/main/CMF/branches/1.5 and that's it (this operation is fast, it only changes metainformation). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMF 1.5.3 beta?
Jens Vagelpohl [EMAIL PROTECTED] wrote: Florent: Quick heads-up to me when you're done with your changes, please. Ok I'm done I think. Heads up for Plone devs (but we were discussing it on #plone): The change I made impacts the signature of CatalogTool.reindexObject, which until recently Plone was overloading. http://svn.zope.org/CMF/branches/1.5/CMFCore/CatalogTool.py?rev=37626view=rev Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Plone participation in the CMF list
Tres Seaver [EMAIL PROTECTED] wrote: I think the discussion around Archetypes, in particular, ended up stalled over the question of whether to code generation design should be preferred over configuration-based design (as found in CPSSchemas, for instance). Also now that Zope 3 is taking more and more importance in CMF, any schema-based solution should be based on Zope 3 schemas. IMO both Archetypes and CPSSchemas are too big frameworks to include in CMF. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] i18n improvements - a proposal
Dieter Maurer wrote: yuppie wrote at 2005-8-9 19:11 +0200: ... 2.) Using different domains for different products: While 'cmf_default' should be used by the core products (CMFCore, CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for CMFCalendar. Can we give CMFCore its own domain? We would like to use CMFCore without any reference to CMFDefault. Frankly I hate domains. The less domains there are, the better. Myself, I'd much rather have a single cmf domain for everything in CMF. Let addon frameworks like Plone or CPS add their own for their own use, but I think it's folly to have several domains for pure CMF packages. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] i18n improvements - a proposal
yuppie wrote: Can we give CMFCore its own domain? We would like to use CMFCore without any reference to CMFDefault. Frankly I hate domains. The less domains there are, the better. Myself, I'd much rather have a single cmf domain for everything in CMF. Let addon frameworks like Plone or CPS add their own for their own use, but I think it's folly to have several domains for pure CMF packages. Does that mean you are voting against using 'cmf_calendar' in CMFCalendar? I'm -0 on cmf_calendar. But definetly -1 on separating the rest into cmf_core, cmf_default, etc. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: CachingPolicyManager improvements
Geoff Davis wrote: RAMCacheManager has no good way to purge stale content. ZCacheable_invalidate()? (granted, in practice it's currently broken for skins... http://www.zope.org/Collectors/CMF/343 ) It's not just that RAMCacheManager has bugs. ZCacheable_invalidate, when called, invalidates everything in the cache associated with a given page template. That means that if you cache, say, a template that provides a view of a document, the only way to invalidate the view for a single document is to invalidate the view of _all_ documents. Not very useful. Yeah you can't invalidate individual views, but I don't think it would be too hard to change that code. I know I've also felt this would be useful to have in several cases. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: CachingPolicyManager improvements
whit wrote: 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. ZopeTestCase is ok. It's PortalTestCase and the like that are slow, because they instantiate a full portal. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] encoding of tool settings / CMFSetup
Hi Yuppie, Is there any need to support tool settings with other encodings than utf-8 (and ascii as a subset of utf-8)? I think there is. Take for instance the portal property title. It could very well be a non-ascii string, and contain accents. It could be (a) an str encoded in some charset, or (b) unicode. If (a), then we can assume the charset specified by the portal property default_charset (with a default of meaning latin-9 maybe), and re-encode to unicode before passing it to the export template. Export is thus not a problem. When importing though, we'll have a non-ascii utf-8 string and we have to decide if we're going to decode it to unicode or re-encode it to the default_charset. This has to be done according to the property type (for properties). For non-properties, I guess we could punt and say tough luck. But I agree that there's no need to pass around an encoding attribute, XML is utf-8 and that's it. Florent AFAICS there's not even a need for utf-8: Most settings are not visible for users and those that are (like title and description of Actions and type infos) can contain an ascii i18n message id. But supporting utf-8 would not cost us much extra and might help people who don't use translations. See also http://www.zope.org/Collectors/CMF/292 For CMFSetup/GenericSetup this would mean: All 'encoding' parameters, attributes and methods could be removed. The XML files are anyway utf-8 encoded, so there would not be any need to convert strings from one encoding to an other. (At the moment a hardcoded ascii encoding is passed around everywhere.) 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 -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] encoding of tool settings / CMFSetup
On 15 Sep 2005, at 17:16, yuppie wrote: Is there any need to support tool settings with other encodings than utf-8 (and ascii as a subset of utf-8)? I think there is. Take for instance the portal property title. It could very well be a non-ascii string, and contain accents. It could be (a) an str encoded in some charset, or (b) unicode. If (a), then we can assume the charset specified by the portal property default_charset (with a default of meaning latin-9 maybe), and re-encode to unicode before passing it to the export template. Export is thus not a problem. When importing though, we'll have a non-ascii utf-8 string and we have to decide if we're going to decode it to unicode or re-encode it to the default_charset. This has to be done according to the property type (for properties). For non-properties, I guess we could punt and say tough luck. But I agree that there's no need to pass around an encoding attribute, XML is utf-8 and that's it. The 'encoding' attribute specifies the site configuration encoding, not the XML encoding. Quoting from the getEncoding() interface: Get the encoding used for configuration data within the site. Ah ok. I haven't really looked at the code. But looking at your examples the handlers should be able to get the encoding information from their context if they want to support special encodings. So there is at least no need to support encodings in the framework. Right? Yes that's my position, they should get it from the context. That means setting the portal properties as one of the first steps during import, but it's probably not a problem. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup Architecture Proposal
Tres Seaver wrote: I owe another proposal on filesystem export / import of content, but this one was a prerequisite. Please comment on the list, as the discussion facilities on the site are pretty much useless. http://www.zope.org/Products/CMF/docs/requirements/proposals/GenericSetup_architecture What granularity do you envision for a DeltaProfile ? Individual files ? Or something finer, like just changing part of an XML file (say, change just the title of a portal type) ? If it's the latter, then we'd have to much quite different handlers than today. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CMF/branches/1.5/C CMFSetup: added support for configuring cookie auth and mailhost tools
Tres Seaver wrote: Log message for revision 38552: --- CMF/branches/1.5/CMFSetup/xml/ccExport.xml 2005-09-20 20:50:17 UTC (rev 38551) +++ CMF/branches/1.5/CMFSetup/xml/ccExport.xml 2005-09-21 09:48:47 UTC (rev 38552) @@ -0,0 +1,13 @@ +?xml version=1.0? +cc xmlns:tal=http://xml.zope.org/namespaces/tal; +tal:define=cc_info context/getCookieCrumblerInfo +tal:attributes=auth_cookie cc_info/auth_cookie; +name_cookie cc_info/name_cookie; +pw_cookie cc_info/pw_cookie; +persist_cookie cc_info/persist_cookie; +auto_login_page cc_info/auto_login_page; +logout_page cc_info/logout_page; +unauth_page cc_info/unauth_page; +local_cookie_path cc_info/local_cookie_path; +cache_header_value cc_info/cache_header_value; +log_username cc_info/log_username; / Eww. Can we have cookiecrumbler instead of cc as the element name please? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CMF/branches/1.5/C CMFSetup: added support for configuring cookie auth and mailhost tools
Jens Vagelpohl [EMAIL PROTECTED] wrote: Eww. Can we have cookiecrumbler instead of cc as the element name please? Sure, go ahead and check it in, before anybody but Pete and I have snapshots which break. ;) That's done now. Thanks Jens. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMFonFive merged
CMFonFive has been merged to the CMF trunk, yay! It depends on Five but of course that's standard now that Zope 2.8.1 is required. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CMF/trunk/GenericSetup/ Improved unicode handling by adding 'getEncoding' to all contexts, export as well as import.
If I understand, the goal is to specify the file encoding for the export. Do
we really need this? Isn't UTF-8 good enough in all cases?
Florent
Tres Seaver wrote:
Log message for revision 38662:
Improved unicode handling by adding 'getEncoding' to all contexts, export as
well as import.
Changed:
U CMF/trunk/GenericSetup/context.py
U CMF/trunk/GenericSetup/interfaces.py
U CMF/trunk/GenericSetup/tests/test_context.py
-=-
Modified: CMF/trunk/GenericSetup/context.py
===
--- CMF/trunk/GenericSetup/context.py 2005-09-28 10:35:29 UTC (rev 38661)
+++ CMF/trunk/GenericSetup/context.py 2005-09-28 11:16:22 UTC (rev 38662)
@@ -46,11 +46,12 @@
security = ClassSecurityInfo()
-def __init__( self, tool ):
+def __init__( self, tool, encoding ):
[...]
+def test_writeDataFile_simple_plain_text_unicode( self ):
+
+from string import digits
+from OFS.Image import File
+FILENAME = 'simple.txt'
+CONTENT_TYPE = 'text/plain'
+CONTENT = u'Unicode, with non-ASCII: %s.' % unichr(150)
+
+site = DummySite( 'site' ).__of__( self.root )
+site.setup_tool = DummyTool( 'setup_tool' )
+tool = site.setup_tool
+ctx = self._makeOne( tool, 'simple', 'latin_1' )
+
+ctx.writeDataFile( FILENAME, CONTENT, CONTENT_TYPE )
+
+snapshot = tool.snapshots._getOb( 'simple' )
+
+self.assertEqual( len( snapshot.objectIds() ), 1 )
+self.failUnless( FILENAME in snapshot.objectIds() )
+
+fileobj = snapshot._getOb( FILENAME )
+
+self.assertEqual( fileobj.getId(), FILENAME )
+self.assertEqual( fileobj.meta_type, File.meta_type )
+self.assertEqual( fileobj.getContentType(), CONTENT_TYPE )
+saved = fileobj.manage_FTPget().decode('latin_1')
+self.assertEqual( saved, CONTENT )
+
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: Trying to customize CMF login to use email rather than userid
Deb Lewis wrote: Have hunted through all the documentation I can find, bumbled around in base system code, and searched web sites/news groups, still stumped and figure this must be something others have done, so must be time for plaintive cry for help. Objective: trying to customize the standard login_form for a CMF site to let members log in by entering the email address from their member data rather than the userid of their account. Did a revised login_form, have supporting services to map email value from form input to a userid and detect cases where that's not possible and actual userid needs to be supplied, but can't figure out where/how to get this hooked in properly in the ZPublisher/auth/login mechanism so that the form submit for this page can get the login processed. Configuration: Zope 2.7.7, CMF 1.4.8; also GRUF (GroupUserFolder) 3.3 Any pointers to tips/solutions would be greatly appreciated. In a standard user folder, the thing that transforms the authentication tokens (login+pw, or here email+pw) into a user object is the 'authenticate' method. You'd have to patch/subclass it if you used a standard user folder, I don't know if GRUF is flexible in that respect. Note that in the context of CPS, CPSUserFolder can use any field as login field, email is indeed a very common need. Another way would be to hack the cookie crumbler so that it transforms the email into the id (by doing a lookup) before passing that info away to the user folder. That would be costly, as you'd do the lookup for every request. Another way would be to do the lookup in the login form, then redirect to logged_in after having changed the form data. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: CMFSetup: workflow scripts as external methods
Jens Vagelpohl wrote: There's an outstanding issue in the collector about workflow scripts that are external methods. Currently, creating a snapshot of a site with external methods on the Scripts tab of a DCWorkflow will just blow up. The real question here is: Do we want to support that at all? Taking a quick look at the code two options come to mind: - When extracting workflow script information, external methods are specifically ignored. The documentation is updated to reflect the fact that only DTMLMethods and Script (Python) (or items derived from them/behaving like them) are supported as far as import/export goes. That would be enough for me. - External methods gain support by extending the saved information to collect module/function values for external methods instead of trying to read the body. This *will* make an import blow up if the filesystem code the external method relies on is not in the expected location. Yeah the problem is that external method's content is non-local. I would favor the latter route, but would volunteer to implement either solution. What's the consensus? Or are there other alternatives? I'm also ok with I/O of the external methods themselves, but I feel that's too much hassle. And it's not among my use cases. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: DCWorkflow + Acqusition
Victor Safronovich wrote: Hello Florent Guillaume, Monday, October 24, 2005, 7:47:43 PM, you wrote: FG They're not skipped, they're treated specially. These exceptions are the way FG for transition code to notify the caller that something happened to the FG underlying object. But what preventtoraiseObjectMoved, ObjectDeleted in nofityException,notifySuccess? That's not what these methods are for. ObjectMoved and ObjectDeleted are designed to be raised by workflow scripts, during the transition, to inform the workflow machinery that the transition left the object in an unexpected place. notifySuccess marks the end of the transition, and is designed similarly to an event mechanism, to inform interested parties that the transition is complete. If it raises exceptions, then they won't be caught. Florent I.e. DCWorkflowDefinition.notifyCreated swallow ObjectDeleted, ObjectMoved. Why? if ObjectMoved raised in DCWorkflowDefinition.notifyCreated, WorkflowTool.notifyCreated doen`t know about that, and def notifyCreated(self, ob): Notify all applicable workflows that an object has been created and put in its new place. wfs = self.getWorkflowsFor(ob) for wf in wfs: wf.notifyCreated(ob) self._reindexWorkflowVariables(ob) -- ob reindexed in a wrong acquisition wrapper. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Finding the current skin name
Could you expand a bit on the use case ? I'm not sure I get what you
want do to, do you change skins several times in the middle of the
request ? In what way is this skin needed afterward, at what point ?
What's a correct skin ?
Florent
Laurence Rowe wrote:
In Plone ResourceRegistries (1.1 branch) I need to get the current skin
name so that the resource (a css or js file) is fetched from the correct
skin. Unfortunately it seems that there is no easy way to get the
current skin name (when it is not set by a cookie in the request). I can
work around this like follows, but it's a bit ugly:
security.declareProtected(permissions.View, 'getCurrentSkinName')
def getCurrentSkinName(self):
Returns the id of the current skin.
Ugh, there really should be a better way of doing this. This is
depending on internals in CMFCore and should be added there.
skintool = getToolByName(self, 'portal_skins')
default_skin_name = skintool.getDefaultSkin()
tid = get_ident()
if SKINDATA.has_key(tid):
skinobj, ignore, resolve = SKINDATA.get(tid)
current_skin_path = skinobj.getPhysicalPath()
#
# Perhaps test against default skin first?
#
skinnames = skintool.getSkinSelections()
# loop through skin names looking for a match
for name in skinnames:
skin = skintool.getSkinByName(name)
path = skin.getPhysicalPath()
if current_skin_path == path:
return name
return default_skin_name
Would it be reasonable to make
Skinnable.SkinnableObjectManager.changeSkin set the skin request var
name after changing the skin? Such as:
security.declarePublic('changeSkin')
def changeSkin(self, skinname):
'''Change the current skin.
Can be called manually, allowing the user to change
skins in the middle of a request.
'''
skinobj = self.getSkin(skinname)
if skinobj is not None:
tid = get_ident()
SKINDATA[tid] = (skinobj, {}, {})
REQUEST = getattr(self, 'REQUEST', None)
if REQUEST is not None:
REQUEST._hold(SkinDataCleanup(tid))
sfn = self.getSkinsFolderName()
if sfn is not None:
sf = getattr(self, sfn, None)
if sf is not None:
REQUEST.set(sf.getRequestVarname(), skinname)
Then getSkinNameFromRequest would work happily. Or is the a better way
to do this?
Regards,
Laurence
___
Zope-CMF maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: Finding the current skin name
Laurence Rowe wrote:
The basic use case is to have sections of the site with different skins.
I implement this with a call to changeSkin in
__before_publishing_traverse__ of a folderish type. As these folders may
be nested changeSkin could be called several times during the request.
The correct skin is that specified by the last call to changeSkin.
The skin name is needed afterwards by Plone's ResourceRegistries so that
the correct resource (css or js file) is returned. In answer to Tres'
question, different css or js is required because it is a relatively
easy way for site managers to customise their site's appearance. (RR
ends up returning resources with urls like site url/skin
name/resource name).
I'll follow Tres' suggestion and supply a patch shortly.
I think Tres's solution is overkill, and that your original solution is better.
The point of SKINDATA is that, as a module global, it is accessible even by
code paths that don't have any way of getting an acquisition context to get
to REQUEST.
However in your case, both changeSkin and the places where you'll need to
know the current skin name have access to REQUEST, so, as you proposed, you
can just add the skin name back in REQUEST, using
REQUEST.set(sf.getRequestVarname(), skinname).
Florent
Laurence
Florent Guillaume wrote:
Could you expand a bit on the use case ? I'm not sure I get what you
want do to, do you change skins several times in the middle of the
request ? In what way is this skin needed afterward, at what point ?
What's a correct skin ?
Florent
Laurence Rowe wrote:
In Plone ResourceRegistries (1.1 branch) I need to get the current
skin name so that the resource (a css or js file) is fetched from the
correct skin. Unfortunately it seems that there is no easy way to get
the current skin name (when it is not set by a cookie in the
request). I can work around this like follows, but it's a bit ugly:
security.declareProtected(permissions.View, 'getCurrentSkinName')
def getCurrentSkinName(self):
Returns the id of the current skin.
Ugh, there really should be a better way of doing this. This is
depending on internals in CMFCore and should be added there.
skintool = getToolByName(self, 'portal_skins')
default_skin_name = skintool.getDefaultSkin()
tid = get_ident()
if SKINDATA.has_key(tid):
skinobj, ignore, resolve = SKINDATA.get(tid)
current_skin_path = skinobj.getPhysicalPath()
#
# Perhaps test against default skin first?
#
skinnames = skintool.getSkinSelections()
# loop through skin names looking for a match
for name in skinnames:
skin = skintool.getSkinByName(name)
path = skin.getPhysicalPath()
if current_skin_path == path:
return name
return default_skin_name
Would it be reasonable to make
Skinnable.SkinnableObjectManager.changeSkin set the skin request var
name after changing the skin? Such as:
security.declarePublic('changeSkin')
def changeSkin(self, skinname):
'''Change the current skin.
Can be called manually, allowing the user to change
skins in the middle of a request.
'''
skinobj = self.getSkin(skinname)
if skinobj is not None:
tid = get_ident()
SKINDATA[tid] = (skinobj, {}, {})
REQUEST = getattr(self, 'REQUEST', None)
if REQUEST is not None:
REQUEST._hold(SkinDataCleanup(tid))
sfn = self.getSkinsFolderName()
if sfn is not None:
sf = getattr(self, sfn, None)
if sf is not None:
REQUEST.set(sf.getRequestVarname(), skinname)
Then getSkinNameFromRequest would work happily. Or is the a better
way to do this?
Regards,
Laurence
___
Zope-CMF maillist -
[EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
___
Zope-CMF maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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 1.5.5 beta phase
Jens Vagelpohl wrote: It's been exactly two months today that CMF 1.5.4 was released as the latest release from the 1.5 branch. A lot of work has been done as evidenced by the change log. I'm not sure if it's helpful for the main consumer of CMF releases (- Plone), but those who develop their own solutions on top of the CMF might appreciate a release. I propose cutting 1.5.5beta this Sunday (November 6th) and having a beta phase lasting 2 weeks, mostly because I'll be in Detroit next weekend and probably won't be able to cut a final release. The weekend after that I'm back in Germany and ready to push out 1.5.5 final. Please speak up if you don't think this is a good idea. It's a good idea but maybe would it be worthwhile to have a bug day before, no? I know there's a few things I want to change to facilitate Five 1.2/1.3 events working with CMF 1.5. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 1.5 manage_afterAdd co
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. Concretely, today CMFCatalogAware.manage_afterAdd does full recursion by itself in the children. To fix that, I would have to make CMFCatalogAware.manage_afterAdd delegate to its base class to do the recursion on non-opaque objects. But CMFCatalogAware is a mixin class, so the only way I'll do what I want is by using super(). Of course as you know, if you use super() somewhere you have to use it everywhere, otherwise Bad Things happen (see http://fuhm.org/super-harmful/). So I'll have to change the users of manage_afterAdd co in CMF to use super() correctly. Because some base Zope classes don't user super (), I have to reorder some classes. Namely, File and Image classes will have to be changed so that CMFCatalogAware is before OFS.Image.File in the bases. Plus some additional details to make getId() work. Does someone have a problem with me doing that in the CMF 1.5 branch? All with tests of course. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup: more refactoring - a small proposal
yuppie wrote: The setup handlers for adapter based import / export are just boilerplate. I'd like to move the complete responsibility for setting up tools to importToolset / exportToolset. toolset.xml already contains all the necessary information if we use the ID of the tool for computing the file names. catalog.xml would e.g. become portal_catalog.xml. GenericSetup would need some BBB code to handle CMF 1.5 profiles. Old-style tool handlers can still have their own registry step. This would make writing and maintaining tool handlers much simpler. On the other hand we loose some flexibility: - import/export of selected tools from a bigger profile: don't think we really need that What do you mean by i/o of selected tools from a bigger profile ? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 1.5 manage_afterAdd co
The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. Florent Florent Guillaume wrote: 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. Concretely, today CMFCatalogAware.manage_afterAdd does full recursion by itself in the children. To fix that, I would have to make CMFCatalogAware.manage_afterAdd delegate to its base class to do the recursion on non-opaque objects. But CMFCatalogAware is a mixin class, so the only way I'll do what I want is by using super(). Of course as you know, if you use super() somewhere you have to use it everywhere, otherwise Bad Things happen (see http://fuhm.org/super-harmful/). So I'll have to change the users of manage_afterAdd co in CMF to use super() correctly. Because some base Zope classes don't user super (), I have to reorder some classes. Namely, File and Image classes will have to be changed so that CMFCatalogAware is before OFS.Image.File in the bases. Plus some additional details to make getId() work. Does someone have a problem with me doing that in the CMF 1.5 branch? All with tests of course. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Dead branches
Could folks having old CMF branches clean them up ? See http://svn.zope.org/CMF/branches/ This seems to concern: ajung, andrew, chrism, chrisw, gregweb, jshell, mj, regebro, shane, sidnei, slinkp, tseaver, yuppie. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Dead branches
Paul Winkler wrote: Could folks having old CMF branches clean them up ? See http://svn.zope.org/CMF/branches/ This seems to concern: ajung, andrew, chrism, chrisw, gregweb, jshell, mj, regebro, shane, sidnei, slinkp, tseaver, yuppie. I'm afraid I don't know what that means. I didn't find anything relevant under http://www.zope.org/DevHome/Subversion . It means removing them using svn rm. The point is that looking at available branches is a good way to know what's cooking, and if there are tens of them that have either been merged or abandonned, it clutters everything. Also removing them is not a problem as svn doesn't lose the information, and if for some reason the history of the branch has to be retrieved, it's easy. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: backporting GenericSetup to CMF-1.5
yuppie wrote: Hi Rob! Rob Miller wrote: those of us planning out the next Plone releases are in a bit of a bind. we really want to make use of GenericSetup's newer Z3-interface-based means of defining import and export handlers, so that we can start work on rewriting our migration engine to use XML import and export, and so we can keep up w/ CMF 2.0 as it moves forward. [...] to this end, it would be very useful for us to have a 1.5-compatible version of CMF that makes use of the newer Generic/CMFSetup semantics. this would allow us to use the new site creation code (which we've nearly completed) in our next release without breaking backwards compatibility with the existing add-on products. this would also make it easier to keep up w/ CMF trunk development w/o having to maintain two radically different branches of Plone. CMF 2.X would be required, of course, with the subsequent release. how do folks feel about this? (note that we, i.e. the plone developers, are willing to do the work.) would you be willing to have an additional 1.5 release, or perhaps a 1.6 release, which includes these changes? our current tentative release schedule has a Plone alpha in late december, beta in february, release some time in march. CMF 1.5 is Zope 2.7 compatible. A Zope 2.7 compatible version of GenericSetup would be a lot of work and it would loose the new semantics because they depend on Five features. But if Plone 2.2 requires Zope 2.8 it should be easy to use CMF 1.5 with GenericSetup 2.0 instead of CMFSetup 1.5. Except for the CMF specific handlers that should work out of the box. A CMF 1.6 release that requires Zope 2.8 and essentially bundles CMF 1.5 with GenericSetup 2.0 (and compatible CMF setup handlers) might be a good idea. Hm seen in that light, I also have a need for a CMF 1.6 that drops support for Zope 2.7. The reason are the recent changes I proposed to support Five 1.2, which need super() to work properly. So it needs Zope 2.8. GenericSetup is still a moving target. I would not create a branch for 1.6 before 2.0 has stabilized. +1 on branching CMF 1.6 soon, with the goal of: - dropping support for Zope 2.7 - allowing Five 1.2 events activated to work, even if it doesn't *require* Five 1.2 events - be closer to CMF 2.0 w.r.t. setup. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup: more refactoring - a small proposal
yuppie wrote: I can see use cases like that, but I'd prefer a more decentralized solution. Using the setup tool for tasks like that makes it too complex and if I want to modify a single tool I don't want to switch to the setup tool and perform many steps to get my import. Possible alternatives: - A modified tool factory could allow adding pre-configured tools in a similar way as the 'CMF Action' and '* Type Information' factories on the trunk (that allow to choose presettings from profiles). - Tools could have an import/export tab that allows to load settings from an XML file. I don't understand, in the CMF 1.5 framework I'm using that doesn't make sense. Things go through portal_setup. Maybe in CMF 2.0 and the updated GenericSetup that's different but I'm not there yet. The new I/O adapters don't depend on the setup tool. Using the setup tool is only necessary if we want to use the snapshots in it. The add form for TypeInfos in CMF 2.0 is an example how a modified tool factory could work. If individual tools have Export/Import tabs that do the I/O, fine, but I don't see any code that does that today. You're proposing that we modify every single tool's implementation, instead of having things in portal_setup? Yes. But the code could be quite generic. AFAICS the only change that would be necessary in every single tool's implementation (or in a shared base class) is adding the new tab to 'manage_options'. Everything else could be a shared view. Anyway I've put this proposal on hold. No need to find a consensus now. So that I'm clear, I'm not against your proposal,as long as there's still a way to simply I/O individual tools. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 2.0 sandboxes
In what environement do people playing with CMF 2.0 (trunk) work ? Because when used with Zope 2 trunk, there are many failing unit tests. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup-based installation backport mostly complete
Rob Miller wrote: 1.) Please subscribe to the CMF-checkins list. This way your checkins will show up in that list and additional eyes can see them. urgh. i have to subscribe? i use gmane to follow all of the lists... *sigh* You can subscribe and then change the settings to receive no mail. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 1.6
I'd like to have some clarifications from the Plone team about what they expect to do w.r.t. events in CMF 1.6. I see two possibilities: 1. you guys are prepared to do the work needed for Plone products to use super() in manage_afterAdd co, in which case I can merge my branch into CMF 1.6 2. you feel that's too dangerous and, as Plone intends to use CMF 1.6, I'll merge for CMF 2.0 only. Be aware that if 2. is chosen, you won't be able to use Zope 3 events at all with CMF 1.6. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup feature?
I'm wondering (I haven't looked at it yet) if I can do the following with GenericSetup. I need to be able to export the same content object in different facets. For instance for a document I need to do a content export, that will dump the standard data and metadata. Then I'll also want a separate workflow export that dumps the workflow state and workflow history. Etc. Is there any provision in GenericSetup to have multiple node exporters for the same interface? Named adapters, or multiadapters on the export context ? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Test broken on 1.6 branch
Dammit, the tests are totally broken on the 1.6 branch. Don't people ever run the tests? sigh Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Test broken on 1.6 branch
Tres Seaver wrote: Note that the current breakage on the 1.6 branch is the kind of stuff that made me reluctant to borrow the trunk's CMFSetup/GenericSetup. In this case, it isn't really fair to complain about the test breakage, in that the whole point of the branch is to find and fix such things. Well if the tests are expected to be broken, it shouldn't be called branches/1.6 but branches/genericsetup-backport. 1.6 is the name of an official branch, which should be clean. I've just fixed a couple of things, which is more than the bandwidth I meant to spend on the 1.6 branch alredy. Thanks. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup uninstalling
Is uninstalling part of the use cases that GenericSetup tries to handle? How would one go about registering what has to be done to remove an extension profile for instance? Has anybody worked in that direction? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: reindexing optimizations
Alec Mitchell wrote: Howdy CMFers, So, Sidnei has been plugging away at the AT reindexes things an obscene number of times issue today, and appears to have fixed many of the AT triggered indexing redundancies. There are however still a few places in CMF where some cataloging redundancy might be avoided. One obvious place is during object creation, where the following happens: *) TypesTool.constructInstance() is triggered **) A _setObject call results in CMFCatalogAware.manage_afterAdd() which triggers a full indexObject(). *) This is shortly followed by TypesTool._finishConstruction() *) Which calls CMFCatalogAware.notifyWorkflowCreated() *) Which in turn calls WorkFlowTool._reindexWorkflowVariables() **) Which does a CMFCatalogAware.reindexObject([idxs]) on workflow specific variables (with a full metadata update) *) And calls CMFCatalogAware.reindexObjectSecurity() which reindexes the object only on the security index, and doesn't touch metadata. **) TypesTool._finishConstruction() then does another CMFCatalogAware.reindexObject(). So we have two full reindexes, and three metadata updates. The last reindex appears to be there only to catch the change to 'portal_type' in _finishConstruction. So, this final reindexObject, might safely be changed to reindexObject(['portal_type', 'Type']), This was the case in my initial code, but Yuppie changed it: http://svn.zope.org/trunk/CMFCore/TypesTool.py?rev=35903r1=35864r2=35903 I don't remember what the reason was, though I believe it was discussed a bit at the time on the lists. though the possibility exists that other indexed attributes added by 3rd parties may depend on the value of portal_type (say, I use an autogenerated Title which includes the Type). Additionally, almost immediately before this last reindexObject call, another reindexObject call has happened in notifyWorkflowCreated, which included a full catalog metadata update. As a result, updating the catalog metadata here is certainly redundant. Unfortunately, the CMFCatalogAware.reindexObject method provides no means of avoiding the duplicate metadata update, though it would be trivial to add and to use here. But as you realize, there is a problem when you have metadata computed using methods. As exemplified by portal_type / Type, just because one attribute is modified doesn't mean only one metadata (or index for that matter) is changed. Another option suggested by Sidnei on IRC, which would avoid the potential issues with limiting the variables indexed in the final reindex. Would be to let CMFCatalogAware.manage_afterAdd know (presumably via some state variable) that it is being invoked through constructInstance/invokeFactory, in which case it could safely skip the initial indexing and allow _finishConstruction to take care of indexing the object fully on it's own at the end. That's certainly a good hack. There are several ways to do it, either with a thread-local variable, or in the request, or by walking the stack's locals to check for a __dont_index__ attribute... You'd have to bench, but a thread-local variable is probably the fastest. You want to store a set of objects whose indexing should be skipped. In the long term we will probably be better served by delaying all indexing to transaction boundaries, though it will be a fair bit harder to implement, and may irk some developers who depend on immediate changes to the catalog on reindex. As Julien said it's not very hard to implement, it's just that there are application changes to consider. Still, there's agreement that CMF should move in that direction, I can provide patches taken from the CPS implementation. (And it requires Zope 2.8/ZODB 3.4 of course.) Some of the framework should pushed into Zope itself. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] CMF 1.5.5 beta phase
On 20 Nov 2005, at 16:06, Jens Vagelpohl wrote: On 4 Nov 2005, at 00:18, Jens Vagelpohl wrote: I propose cutting 1.5.5beta this Sunday (November 6th) and having a beta phase lasting 2 weeks, mostly because I'll be in Detroit next weekend and probably won't be able to cut a final release. The weekend after that I'm back in Germany and ready to push out 1.5.5 final. As you've probably seen, 1.5.5 is now out and the 1.5 branch is back in business for changes. Florent, what are your requirements for the events changes you wanted to see in 1.5.5 originally? I'm wondering if that's really 1.6 material now that we have a 1.6 branch? Let me know if you want it in 1.5 and we can plan a 1.5.6 release, or if the 1.6 branch has made this unnecessary for 1.5. I'm a bit uncertain about the time frame for 1.6, there are a number of constraints behind it. If the GenericSetup backport gets finished and a 1.6.0 release is made in not too long then I'll use that. Otherwise a 1.5.6 would be nice. I intended my changes to make it possible to use events by using super () in a number of places, but that won't even be possible for 1.6 because of these constraints (plone compatible and too much third- party products would break). So if there's a 1.5.6 I want to merge part of my changes into it (see http://svn.zope.org/CMF/branches/1.6/CMFDefault/File.py? rev=40207view=rev) so that I can at least monkey-patch the super() into place from my framework and start using events without waiting for Plone or CMF 2.0. Let's wait a bit and see how 1.6 goes. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 2 security and SimpleItem
Florent Guillaume wrote:
Florent Guillaume wrote:
I'm in the process of refactoring OFS to use new-style security
declarations (about time ;)), and I stumbled on something which may
or may not be a bug, I don't know, I'd like some else's opinion:
The class SimpleItem has the definition (it's been there since the
begining of time when SimpleItem was created):
__ac_permissions__=(('View', ()),)
The unusual thing here is () instead of ('',).
Hm I now realize that this may be there just to define the View
permission as available but that's all. But there's still a discrepancy
in the way SecurityInfo treats it.
Ok I got to the reasons for that, it all dates back to the origins of
SecurityInfo in December 2000 when it originally had methods that did
the work of both declareProtected and declareObjectProtected. I'll fix this.
Florent
Anyway I'm further in understanding securiy in Z2 than I've ever been :)
Florent
I think the intent here is that it be the object level protection,
equivalent to the modern declareObjectProtected('View').
Indeed, if the SimpleItem class had a
security = ClassSecurityInfo()
(even by itself without further security declaration), then
AccessControl/SecurityInfo, which has the code
# Empty names list sets access to the class itself, named ''
if not len(names):
names = ('',)
would actually turn the () into a ('',) and the rest of the end of
the security setup, in App/class_init.py, would set
SimpleItem.__roles__ = PermissionRole('View') and that would be it.
However SimpleItem does *not* have this ClassSecurityInfo, which
means that the code above is not called, and the final logic in
class_init.py does not turn an empty tuple into protect the object.
It means that SimpleItem does not have an object level protection of
View (but the default which is that only Manager has access), which
is probably as well but not clear from the code.
What do you think I should do?
- fix to use View?
- fix to use nothing?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: SVN: CMF/trunk/ - converted types tool setup handlers to new style
Yvo Schubbe wrote:
+ self._logger.info('\'%s\' type info imported.' % self.context.getId())
Please avoid this hard-to-read style of backslash-quoting, you could do:
self._logger.info('%s' type info imported. % self.context.getId())
(It is also my personal convention that I enclose English strings in
and all the rest in '', it's useful because it isolates them, English can
have single quotes in it, and non-english very rarely has single quotes in it)
Or even better:
self._logger.info(%r type info imported. % self.context.getId())
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: problems w/ 'File' type in CMF 1.6
Rob Miller wrote:
in trying to get Plone working against the 1.6 branch i've come across
some problems w/ the way that CMFDefault.File.File is working since the
base classes have been reordered.
the biggest problem has to do w/ the default view lookup. when
OFS.Image.File was the first base class, then that class's index_html
method would be used as the default view. with PortalContent first,
however, index_html is None. this causes ZPublisher to use __call__,
but this then calls queryMethodId('(Default)') on the FTI, which returns
index_html, which is still None. when i add CMF File objects in a Plone
site and try to browse to them, i'm getting 404s; in a pure CMF site i
get a notice that 'index_html' has an empty or missing docstring.
I'll check that. Pointing index_html to the OFS one is probably sufficient.
the other problem, not as big an issue, has to do with the comment that
is immediately after the File class definition; it explicitly says that
the base classes should not be reordered b/c this would cover up the
id() method in the OFS.Image.File class. using getId() will always
work, of course, and i'm not even sure that covering the id() method
will actually break anything, but it probably deserves a little bit of
investigation and, if all is well, we should remove the misleading comment.
Ah yes, actually I'm taking care of all that by using the
standard-for-quite-some-time getId(), and making sure the id is stored in
the id attribute (and not __name__ anymore) using _setId explicitely. I also
keep a backward compat id() method for old instances.
I'll remove the old comment that threw you off.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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: CookieCrumbler redirects to login page
sureshvv wrote: My site is redirecting logged in users to the login page intermittently without any error message (on the screen, error_log or event.log even with VerboseSecurity installed) when they access certain potions of the site. What changes do I need to make to get the permission that was denied? Can we fix CookieCrumbler to put a portal_status_message and put the full message in the error_log? Log the user through the ZMI, and deactivate the cookie crumbler (by removing it, or giving it an invalid page in its properties) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup development: progress report
of questions and feedback are welcome. Cheers, Yuppie ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup TI listing
CMFCore.browser.typeinfo.FactoryTypeInformationAddView.getProfileInfos p arses all the profiles types/*.xml files to check their meta_type. Why not check simply typesinfo.xml ? Also, why is the meta_type information duplicated in typesinfo.xml and types/foo.xml? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup TI listing
On 13 Dec 2005, at 11:01, yuppie wrote: Florent Guillaume wrote: Also, why is the meta_type information duplicated in typesinfo.xml and types/foo.xml? The adapter for the container is responsible for creating empty sub- objects. So in this case the TypesToolXMLAdapter needs to know the meta_type information to find the correct class. Ok I thought it would be something like that. I don't like it but I don't see another option. The meta_type information in types/foo.xml isn't strictly necessary, but it allows to see to which meta_type the XML file belongs and to check the meta_type before applying an XML file to an object. Yes I agree that it's good to have it in types/foo.xml for consistency and self-sufficiency. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 GenericSetup log levels
Chris Withers wrote: yuppie wrote: 1.) It would be nice to have a policy for Zope. If the Zope core officially supports the BLATHER level (not just in the deprecated zLOG module) I'm fine with using it in GenericSetup as well. It doesn't, ZODB has a mapping for it but it's a stupid name left over from before the same timeframe as STUPID_LOGGER and some of the wacky error messages that ZServer used to spit out. I really want it to die :-( Stupid is in the eye of the beholder. You don't like something that's useful for others so you want it to die. Congratulations for your openmindedness. And you apparently can't grasp the idea that there can be different levels of informativeness. Python has .info and .debug. If this stuff is useful and normal people will want to know it, it should be at info. There's no such thing has normal people. There are many profiles. And at different times the same person may want to read information at a more detailed level than usual. Just INFO and DEBUG is not enough. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? The new way (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 1.6 change broke Plone compatibility
Rocky Burt wrote: Raphael Ritz wrote: Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Zope = 2.8.5 Five = 1.2 So I got a Zope-2.8.5-final only to realize later that this ships with Five-1.0.2 :-( Your best bet is to install Zope 2.8.5-final and then install Five 1.2b (in your instance home Products dir). Not sure what other troubles Zope 2.9b1 would bring to the table here. I'm currently working on having CPS work with CMF 1.6 branch and Zope 2.9 branch. I've had a few fixes to make already, today most things should work. A few more may come when I test deeper. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Bug when removing state in DCWorkflow
Alexander Limi wrote: Can anybody familiar with DCWorkflow take a look at this? http://trac.plone.org/plone/ticket/5067 It used to work, and is a classic workflow change operation that I personally use all the time. CMF doesn't have a workflow pulldown, and has probably different ways of filtering displayed content. Can you configurm that the bug applies to pure CMF? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup: allowed_container_types
On 13 Dec 2005, at 13:50, yuppie wrote: Florent Guillaume wrote: On 13 Dec 2005, at 12:50, yuppie wrote: I'd propose to implement an update mode for list properties and to add an update file for each allowed container. Something like that: object name=MyContainer property name=allowed_content_types element value=MyType/ /property /object (Didn't have a look at the code. I guess this currently overwrites the list and maybe that's what it should do by default. But we could add an explicit mode=update to enforce an update mode.) Yes that was another option I'd considered but found more complex, but if you think it's ok I'll look at how to implement it. Yes, I prefer this option. It should be easy to implement and also useful for other properties. Workflow bindings are set in a similar way, see the example in the CMFTopic profile. The mode=update would be an attribute of property, right ? Yes. But just found that I already use purge=False for action handlers. I guess this is better than mode=update. I can't find any code for purge=False. Workflow bindings don't need that attribute - they are always in update mode if self.environ.shouldPurge() is False. Maybe it would be better to make the shouldPurge setting the default for properties as well. And override it with purge=True if necessary. Don't know. On the other hand the object importer and the skins layer importer check insert-before and insert-after. I'll reuse that, even if in my use case the list order doesn't matter. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup: allowed_container_types
On 5 Jan 2006, at 12:05, yuppie wrote: I can't find any code for purge=False. This is only on the trunk. The _importNode methods of ActionCategoryNodeAdapter and ActionNodeAdapter look for an optional 'purge' attribute. Ah ok, I had looked at CMF 1.6 only. Workflow bindings don't need that attribute - they are always in update mode if self.environ.shouldPurge() is False. Maybe it would be better to make the shouldPurge setting the default for properties as well. And override it with purge=True if necessary. Don't know. On the other hand the object importer and the skins layer importer check insert-before and insert-after. I'll reuse that, even if in my use case the list order doesn't matter. On second thought it's a bit different, for skins and objects insert-before and insert-after are attributes of the (equivalent of the) element itself, not the property... So I'll put them on the elements, and make update the default if purge is true, and add an optional purge=True on the property if you really want to purge it in an extension profile. And on third thought you implemented remove=True. I'm not married to 'purge', but - we should be consistent for all kinds of sequences - remove doesn't feel right. If I see property name=lines2 remove=True I expect this property will be removed, not just cleared. - it actually overrides shouldPurge() I'm ok with 'purge' too. I named it 'remove' because of the existing uses of that keyword, and of not finding any use of purge. And if you see: property name=lines2 remove=True element value=Foo/ /property Then the behavior felt relatively natural: first remove, and then add what's here. But ok with purge. BTW: We should document these update directives somewhere. Originally all update directives were mentioned in CMFSetup/ PROFILES.txt. GenericSetup/PROFILES.txt no longer has a complete list because most update directives are CMF specific. I also agree, I need to point my developers to a doc somewhere with these special directives. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Bug when removing state in DCWorkflow
Alexander Limi wrote: Florent Guillaume: That's been the intent of the code all along: when you query the workflow tool and ask it for the state of an object, this is passed along to DCWorkflow, and if the object doesn't have a state anymore the initial state is returned. However if you remove a valid state, nothing queries and recatalogs all the objects, so they still have an old review_state in the catalog. Update security settings is for a different use case, I'm not sure it should be retrofitted into doing this. So why did it work in earlier CMF versions? I'm curious. :) How early? The current code calls: ob.reindexObject(idxs=['allowedRolesAndUsers']) for updated objects, and it's been that since July 2002. The review state is *not* reindexed. Which is only normal for a method called updateRoleMappings. The reason why this is so important to me is that it removes the ability for non-developers to do any sort of meaningful change to the workflow. Removing a state and having the objects in that state fall back to the initial state is extremely useful - whether it was intentional or not. I understand the use case. It's just that it's not something the code was ever supposed to do. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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.0 Release Status
Jens Vagelpohl wrote: As far as the Zope target platform for CMF 2.0 goes, I was under the impression it had already quietly slipped to 2.9, even though there was never any announcement ;) Plone will probably be on CMF 1.5/1.6 in the near term rather than 2.0, so IMHO that is an argument in favor of simplifying CMF's Zope support to just 2.9 and over. This ties into the second question, which Plone core developers can answer better, about the plans for which version of Plone will go with which version of CMF. As an added question, how does the CPS release plan relate to the CMF? CPS 3.4.0 will be in beta before the end of the week. We require Zope 2.9.0 and ship with a CMF 1.6 snapshot to take full advantage of GenericSetup, and probably with a fixed Five 1.3.1 snapshot as well. Florent PS: I'll answer about the other questions relating to events later or tomorrow. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] membership tool folderish?
Why is the membership tool folderish? What's potentially stored in it? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup zcml registration of profiles
I propose to add a new directive registerProfile in GenericSetup so that profile registration can be done through zcml. What namespace should I use? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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
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 outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). Rocky how does your effort relate to Basket by the way? ISTR that Basket aims at answering a similar use case. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup list property purge
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, closer to what was the case before: purge by default for lists even in extension profiles, except if purge=False is present on the property. I checked this in. But actually this revealed what I think is slightly unclear behaviour in the case of loading extension profiles: the extension profile can happily modify objects without them being purged, but I believe that as soon as it has to create a new object, the import context should be switched to _should_purge=True for that object and the recursion inside it. What do you think? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup zcml registration of profiles
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 the obvious and suggest the default namespace prefix for genericsetup should be setup ? :) I think setup is a bit too generic. And genericsetup is therefore less generic :):) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup list property purge
On 17 Jan 2006, at 10:28, yuppie wrote: Florent Guillaume wrote: 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, closer to what was the case before: purge by default for lists even in extension profiles, except if purge=False is present on the property. I checked this in. But actually this revealed what I think is slightly unclear behaviour in the case of loading extension profiles: the extension profile can happily modify objects without them being purged, but I believe that as soon as it has to create a new object, the import context should be switched to _should_purge=True for that object and the recursion inside it. What do you think? I don't like that idea: - Applying the settings to a new object should always have the same result as applying them to a purged object. If everything is implemented that way changing the purge mode to True doesn't make any difference in deeper levels. - You would need a way to mark those parts of the extension profile that should always create new objects (or purge them if they already exist). We already have purge=True for that. - I can't see how this would resolve your issue for purge=False. The handlers for other sequences (like skin paths and object managers) just add new sequence items if the item doesn't exist already. Wouldn't that also work for list properties? Yes but other sequences have an implicit semantics which is that elements cannot appear twice. Whereas here for properties that are lists we don't know the underlying semantics. It could be desired or not to have an element present twice. Not in my use case admittedly, but you never know. Up to know I just added elements to the list, without removing identical ones already present. What I can do is, for now, make purge=False have the exact semantics than for skins or objects (remove the old element first if it exists), but we know that at some point we may have to extend that semantic to provide things like append=True or append=always and append=once... We can probably avoid deciding that now. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: DeprecationWarnings for container events
Tres Seaver wrote: I'd like to get the CMF-trunk clean of Deprecation warnings, at least when running unit tests or starting up Zope, and those emitted by OFS.subscribers are the remaining ones I know about. How do you mean for objects to handle the case where *they* need to respond to container events. E.g., the CookieCrumbler needs to register / unregister itself as a traversal hook on its container; there is no external subscriber which should be responsible for that (unlike, say, the catalog or the workflow tool). Not if you think in term of placeful subscriber, but here the standard way is to have just a subscriber that is a function, and to do: subscriber for=.interfaces.ICookieCrumbler zope.app.event.interfaces.IObjectEvent handler=.CookieCrumbler.handleObjectEvent / from zope.app.container.interfaces import IObjectMovedEvent from OFS.interfaces import IObjectWillBeMovedEvent def handleObjectEvent(ob, event): Notification from the event service. if IObjectMovedEvent.providedBy(event): if event.newParent is not None: # here register hook elif IObjectWillBeMovedEvent.providedBy(event): if event.oldParent is not None: # here unregister hook WRT content, do you have code in hand which makes the catalog and workflow tools subscribers, so that we could rip out the 'manage_afterAdd' and 'manage_beforeDelete' from the content base class? No I haven't done that yet even in CPS (for lack of time, not because of difficulty). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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-CVS] SVN: GenericSetup/trunk/ Ignore _svn directories in addition to .svn (for Windows).
On 20 Jan 2006, at 11:42, Encolpe Degoute wrote:
Florent Guillaume a écrit :
| Log message for revision 41380:
| Ignore _svn directories in addition to .svn (for Windows).
Hi,
Can you also add _darcs for ZWiki repository ?
Is that on windows? What about unix? Is it '.darcs' ?
Florent
Reagrds,
| Changed:
| U GenericSetup/trunk/context.py
| U GenericSetup/trunk/differ.py
| U GenericSetup/trunk/interfaces.py
| U GenericSetup/trunk/tool.py
|
| -=-
| Modified: GenericSetup/trunk/context.py
| ===
| --- GenericSetup/trunk/context.py 2006-01-20 10:09:36 UTC (rev
41379)
| +++ GenericSetup/trunk/context.py 2006-01-20 10:35:58 UTC (rev
41380)
| @@ -216,7 +216,7 @@
| return os.path.isdir( full_path )
|
| security.declareProtected( ManagePortal, 'listDirectory' )
| -def listDirectory( self, path, skip=('CVS', '.svn') ):
| +def listDirectory( self, path, skip=('CVS', '.svn', '_svn') ):
|
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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] status of events support?
Tres Seaver wrote: yuppie wrote: What's the current status of the events support? For reference, that branch is svn diff -r 40027:40028 svn://svn.zope.org/repos/main/CMF/branches/efge-1.5-five-compatible 1.) AFAICS the efge-1.5-five-compatible branch is only merged into the 1.6 branch. IIRC there were no plans to merge this into the 1.5 branch because these changes are not 100% backwards compatible. That means that CMF 1.5 should not be used with Five 1.2/1.3 events. Right? Why are those changes not merged into the trunk? The parts of that branch that have been merged are the reordering of base classes of Image and File. CMF 1.6: http://svn.zope.org/?rev=40207view=rev I've no idea why I didn't merge it also in trunk, I'll do that now. The non-merged thing is the one redoing the CMFCatalogAware recursion by calling super() and the removal of manage_beforeDelete friends from Image and File. This should be merged only on 2.0. 2.) The CMF 1.6 tests suppress the subscribers deprecation warnings. Wouldn't it be better to use five:deprecatedManageAddDelete? I guess yes. 3.) Is there anything else on the CMF 1.6 / 2.0 todo list that's related to events? Are there any plans to use events in CMF 2.0? Good questions. I am about to post a release status document, for which those issues are germane. I don't know the answers, BTW, beyond the fact that we *do* plan to publish container and object modification events in 2.0; we won't get around to changing the infrastructure pieces to be based on those events before a 2.0 release. I'll provide some help there if needed. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Forcing a workflow state
Martin Aspeli wrote:
I'm writing some migration code that needs to force a workflow state.
That is, a given content item has a workflow with states A, B and C, and
depending on some external state, I need to force it to be in state B,
including having B's security settings.
I've had a look at the API, but it's all very geared towards transitions
rather than setting states explicitly. Before I resort to pdb, does
anyone know the relevant part of the DCWorkflow API I should use to
force a state? I don't mind mucking about with internals, obviously.
Calling portal_workflow.setStatusOf(...) should be enough. You'll have
to pass a status dict containing at least {wf.state_var: state_id}, you
should also set the other variables your application expects.
Then update the security mappings by calling wf.updateRoleMappingsFor(ob).
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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] missing checkin messages
Some checkin messages are missing from the checkins list. For instance r41445 by Yuppie is not there. This makes it hard to follow developments... Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: missing checkin messages
On 31 Jan 2006, at 14:10, yuppie wrote: Florent Guillaume wrote: Some checkin messages are missing from the checkins list. For instance r41445 by Yuppie is not there. This makes it hard to follow developments... This is a GenericSetup checkin and can be found on zope-cvs (=gmane.comp.web.zope.public-cvs). What else are you missing? Ah. Very sorry, I have that list too but for some reason didn't expect catalog stuff in GenericSetup. I'll read my backlog in zope-cvs. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CookieCrumbler
Tres Seaver wrote: Log message for revision 41514: @@ -395,7 +383,24 @@ Globals.InitializeClass(CookieCrumbler) +def handleCookieCrumblerEvent(ob, event): + Event subscriber for (un)registering a CC as a before traverse hook. + +if not ICookieCrumbler.providedBy(ob): +return +if IObjectMovedEvent.providedBy(event): +if event.newParent is not None: +# register before traverse hook +handle = ob.meta_type + '/' + ob.getId() +nc = BeforeTraverse.NameCaller(ob.getId()) +BeforeTraverse.registerBeforeTraverse(event.newParent, nc, handle) +elif IObjectWillBeMovedEvent.providedBy(event): +if event.oldParent is not None: +# unregister before traverse hook +handle = ob.meta_type + '/' + ob.getId() +BeforeTraverse.unregisterBeforeTraverse(event.newParent, handle) I think you want event.oldParent here. Florent + class ResponseCleanup: def __init__(self, resp): self.resp = resp -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup: purging steps on new base profile
When you select a new base profile in the Properties tab, the toolset and import/export steps are not reset but simply updated. This means you can get steps unrelated to your profile that linger. I'd like to change that behavior so that the toolset and steps are reset when a base profile is selected. Comments? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: GenericSetup: purging steps on new base profile
Jens Vagelpohl wrote: On 1 Feb 2006, at 17:30, Florent Guillaume wrote: When you select a new base profile in the Properties tab, the toolset and import/export steps are not reset but simply updated. This means you can get steps unrelated to your profile that linger. I'd like to change that behavior so that the toolset and steps are reset when a base profile is selected. +1 (unless I misinterpret the desired behavior of switching between base profiles) Hm a side effect is that if you select the initial base profile, then an extension profile, then the original base profile again, you won't have what you expect. Because the current base profile id is not stored, there's no way to do detect the change to a different base profile. Should I store that property to allow for that use case? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 roadmap
Jens Vagelpohl wrote: Hi all, I finally sat down and put up a CMF roadmap page. It is pretty condensed right now, and I'm asking for feedback: http://www.zope.org/Products/CMF/docs/roadmap There's one specific item that I couldn't find enough information on to make a comment, which is events support. Florent, what is the status on the trunk and the 1.6 branch? In 1.6 and 2.0 events are not used beyond what Zope has. So events are not used to trigger cataloging on modifications for instance. Also, manage_afterAdd co still exist and have not been converted to events, so are still flagged using five:deprecatedManageAddDelete. As mentioned, Tres has a branch where he works on this. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CMF/trunk/CMFDefault/RegistrationTool.py oops! this fallbacks are broken and I guess we don't need them anyway
Yvo Schubbe wrote:
Modified: CMF/trunk/CMFDefault/RegistrationTool.py
===
--- CMF/trunk/CMFDefault/RegistrationTool.py2006-02-14 21:47:30 UTC (rev
41621)
+++ CMF/trunk/CMFDefault/RegistrationTool.py2006-02-14 22:19:40 UTC (rev
41622)
@@ -131,8 +131,7 @@
# Rather than have the template try to use the mailhost, we will
# render the message ourselves and send it from here (where we
# don't need to worry about 'UseMailHost' permissions).
-method = getattr(self, 'member_password_mail',
- getattr(self, 'mail_password_template'))
+method = getattr(self, 'member_password_mail')
Well, self.member_password_mail is simpler :)
Florent
kw = {'member': member, 'password': member.getPassword()}
if getattr(aq_base(method), 'isDocTemp', 0):
@@ -173,8 +172,7 @@
# Rather than have the template try to use the mailhost, we will
# render the message ourselves and send it from here (where we
# don't need to worry about 'UseMailHost' permissions).
-method = getattr(self, 'member_registered_mail',
- getattr(self, 'registered_notify_template'))
+method = getattr(self, 'member_registered_mail')
kw = {'member': member, 'password': password, 'email': email}
if getattr(aq_base(method), 'isDocTemp', 0):
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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 roadmap
Jens Vagelpohl wrote: There's one specific item that I couldn't find enough information on to make a comment, which is events support. Florent, what is the status on the trunk and the 1.6 branch? In 1.6 and 2.0 events are not used beyond what Zope has. So events are not used to trigger cataloging on modifications for instance. Also, manage_afterAdd co still exist and have not been converted to events, so are still flagged using five:deprecatedManageAddDelete. As mentioned, Tres has a branch where he works on this. Is this something we need to wait for for the first 2.0 beta in 1.5 weeks? High +1 on getting this fixed for 2.0. There's a lot of contrived cataloging code out there (*cough* Archetypes) and it would be beneficial to have a clean model for events in CMF, not just for cataloging things. I do realize there are always parties who would *like* something to happen, but this was a question directed at the people who *do* make it happen. If we're not sticking to some kind of schedule but wait till all wish lists are considered we won't get anywhere I am afraid. I'd love to help but I won't have much bandwidth before 1 month. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] GenericSetup tags
A few versions of CMF have been tagged, but the tags still have an svn:external pointing to GenericSetup trunk. That's bad as it means the tag checkout will change over time. GenericSetup should be tagged too, and the CMF tags point to it. (I favor the first solution.) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] five_template slots
IIRC the idea was to have a template usable from standard Zope 3 views that expected the standard Zope 3 slots, and css_slot was one of those. But I'll let Lennart answer, I've never really touched this stuff. Florent yuppie wrote: Hi! A while ago the five_template for the trunk / CMF 2.0 was replaced by the one from CMFonFive. I still have some difficulties understanding the rationale behind that change. I never got an answer to this mail: http://mail.zope.org/pipermail/zope-cmf/2006-January/023746.html AFAICS there are two use cases for the five_template: 1.) Provide generic slots used in Five and Zope 3 The five_template shipped with Five provides two slots: 'style_slot' and 'body'. The old CMF five_template did provide the same two slots. The new five_template maps 'style_slot' to a non-existent 'css_slot'. 2.) Provide cmf specific slots in @@standard_macros/page The new five_template provides 'base' and 'header', mapping them to the corresponding slots in main_template. 'body' is mapped to 'main', so all slots in main_template can be filled via the five_template. I'm not sure if we really should support that use case. At least it is less important than the first use case. Issues: --- - mapping 'style_slot' to 'css_slot' is an obvious bug, that change should be reverted - the 'header' slot behaves different than in main_template: main_template provides default content for 'header', the five_template 'header' is empty by default. I'd like to keep that in sync, but maybe we should remove the default content from main_template. Most skin templates override the 'header' slot anyway. - the Five 'body' slot doesn't map very well to the CMF 'main' slot: 'header' *and* 'main' would match better. Proposal: - 1.) Add a new 'body' slot in main_template that wraps around the 'header' and the 'main' slot. You can either use 'body' *or* 'header' and 'main'. 2.) Remove the default content in main_template's 'header' slot. 3.) Replace five_template by something like this: metal:macro metal:define-macro=page html metal:use-macro=context/main_template/macros/master head metal:slot metal:fill-slot=base metal:slot metal:define-slot=base / /metal:slot metal:slot metal:fill-slot=style_slot metal:slot metal:define-slot=style_slot / /metal:slot /head body metal:slot metal:fill-slot=body metal:slot metal:define-slot=body metal:slot metal:define-slot=header / metal:slot metal:define-slot=main / /metal:slot /metal:slot /body /html /metal:macro 4.) Change the browser view templates to use 'main' instead of 'body' (that no longer maps to 'main'). Any feedback is welcome. If there are no objections I'd like to make the proposed changes on Saturday, before the 2.0-beta2 release. Cheers, Yuppie ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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
Jens Vagelpohl wrote: On 2 Apr 2006, at 09:34, Rob Miller wrote: it's in now, r66291. and i've also committed the .delete file support implementation, again on the 1.6 branch. if there are no complaints, i'll merge to 2.0 and trunk on monday. Thanks Rob! I hope Lennart and Yvo will take a look this weekend or Monday. My own goal (or the reason for making the corresponding collector issue a release blocker) was to just prevent content deletion as described in the issue. Anything beyond that I am neutral about. FWIW I don't have an opinion on this, as we don't use the content.py I/O export methods. The XML/NodeAdapterBase is enough for us. But I'm curious as to why there are two import/export frameworks, the config one (NodeAdapterBase) and the content one (FileSystemExporter). Couldn't they be merged? Or at least some adapters reused? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 roadmap update
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:08, Chris Withers wrote: Jens Vagelpohl wrote: I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. Having such an unknown and unmaintained piece of code in the core of the cmf scares me. How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. Grégoire Weber is the one that coded it and included it. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. Given that it's unmaintained, that Plone has its own UID tool, that CPS does it differently, I'm for deprecating it quickly and slating it for removal earlier than the usual 1 year. I've also alreay pointed out the overengineering of having 3 tools for a simple UID management. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] tseaver-catalog_events branch
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I finally found some time to have a look at the tseaver-catalog_events branch. The last failing test is fixed now and I have some questions: Thanks for that, I think I was at a point where I didn't see the forest for the trees. 1.) The ContentishSublocations adapter is not registered by default, just for unit tests. Why? 2.) Instead of using a customized ISublocations adapter and _recurseOpaques in handleObjectEvent: Can't we just add a new subscriber that dispatches to opaque items like dispatchToSublocations dispatches to sublocations? I think Tres would know best what the original aim was. I think both ways work. Whichever is best is a matter of taste. Having a second subscriber would mean two recursions more or less in parallel (even though in practice I don't think it would matter); I think I prefer the new ISublocations adapter way. 3.) Does this branch make the unmerged part of the efge-1.5-five-compatible branch obsolete? Not sure what's in there. I haven't looked at it in a while or compared it to Tres's, but keep in mind it was just an early experiment to show the way, I'm pretty sure Tres's work obsoletes it. Florent Would it make sense to prevent this branch from being left behind more as normal development continues by merging it into the trunk and continuing the remaining polishing there? -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] removing ZClass support?
yuppie wrote: Is anybody using ZClasses based on CMF tools or content? I very much doubt that. Can we rip out the initializeBases* code on the trunk? Or do we need a deprecation period? Has anybody an idea where to add useful deprecation warnings? If nobody here says he uses them, I'd say rip them out and don't bother with deprecation warnings. Seeing that we, core CMF developers, haven't really supported them for ages, continuing the illusion that they're maintained is useless. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CMF/trunk/CMF - fixed the i18n domain
Sorry to beat a dead horse, but can't we have cmf as a domain everywhere and be done with it? There's really no point in separating cmf_default from cmf_somethingelse. Florent Yvo Schubbe wrote: Log message for revision 68423: - fixed the i18n domain Changed: U CMF/trunk/CMFCore/browser/configure.zcml U CMF/trunk/CMFCore/tests/fiveactions.zcml U CMF/trunk/CMFDefault/skin/configure.zcml -=- Modified: CMF/trunk/CMFCore/browser/configure.zcml === --- CMF/trunk/CMFCore/browser/configure.zcml2006-06-01 07:24:38 UTC (rev 68422) +++ CMF/trunk/CMFCore/browser/configure.zcml2006-06-01 07:44:06 UTC (rev 68423) @@ -2,8 +2,7 @@ xmlns=http://namespaces.zope.org/zope; xmlns:browser=http://namespaces.zope.org/browser; xmlns:five=http://namespaces.zope.org/five; -i18n_domain=cmf - +i18n_domain=cmf_default five:traversable class=Products.CMFCore.ActionInformation.ActionCategory/ -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: SVN: CMF/trunk/CMF - fixed the i18n domain
On 2 Jun 2006, at 09:00, yuppie wrote: Florent Guillaume wrote: Sorry to beat a dead horse, but can't we have cmf as a domain everywhere and be done with it? There's really no point in separating cmf_default from cmf_somethingelse. The point is to use CMFCalendar as an example add-on product that shows how to use a different domain for an add-on product and helps to fix related issues. If someone wants to rename 'cmf_default' to 'cmf' I'm fine with that. Yes at a minimum But -1 for merging 'cmf_default' and 'cmf_calendar'. Why? Because you lose the example of changing the domain? Isn't that what docs are for? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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
