Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

[Wichert Akkerman]

On 2009-8-17 17:48, Alec Mitchell wrote:
 Exactly.  The failures are essentially cosmetic, I can fix them either
 by removing the Quoted Printable configuration from MailHost or by
 changing the CMF tests to expect Quoted Printable instead of Base64.
 Quoted Printable is easily readable/debuggable and doesn't get
 penalized by spam filters, base64 is more compact.  It may make the
 most sense to remove the Quoted Printable config from MailHost and
 just punt this decision to some future release.

I would rather see those quopri changse go in for two reasons: it makes 
testing emails easier us humans can read quoted printable text while
base64 looks like line noice, and in my experience spamfilters tend to 
consider base64 encoded emails more likely to spam.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue

[Wichert Akkerman]

On 2009-8-8 11:53, Hanno Schlichting wrote:
 On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clarkchar...@begeistert.org  wrote:
 Is the patch for Plone or CMF?

 It's for Plone, I guess. The problem is solved in Plone 4.0 itself
 (via monkey-patching CMF).

 If it's for CMF then you should consider simply submitting a patch or
 opening a branch. But before you write any package I would like to know a
 little more about what exactly you want to do.

 The problem is the entire concept of opaque items. The only places I
 know they are still in use is the talkback objects as used by the
 discussion machinery in CMF. CMFUid also claims to implement the
 concept, but doesn't actually need any of the functionality, since it
 has its own event subscribers to deal with things.

 So the problem starts in
 CMFCore.CMFCatalogAware.dispatchToOpaqueItems, with the nice line:

 for opaque in ob.opaqueValues():

 which in turn calls later on the opaqueItems method which contains this 
 beauty:

 self_base = aq_base(self)
 for name in self_base.__dict__.keys()
obj = getattr(self, name)
if ICallableOpaqueItem.providedBy(obj):
  items.append((obj.getId(), obj))

 The whole method redispatches any IObjectEvent fired on an
 IOpaqueItemManager to any opaque item in it. In doing so, it needs to
 load every single entry in the objects __dict__ to see if it is an
 ICallableOpaqueItem.

 It happens that the CMFCatalogAware base class is such an
 IOpaqueItemManager, so any essentially any content object gets this
 treatment.

Could it be that this considers dexterity content to be opaque items? I 
have some code where events are recursively re-dispatched by CMF and I 
suspect this is why.

Wichert.


-- 
Wichert Akkerman wich...@wiggy.net   It is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Extending FTI.isConstructionAllowed

[Wichert Akkerman]

Previously yuppie wrote:
 After (re)reading all the comments and having a closer look at the code 
 I came to these conclusions:
 
 1.) CMF 2.1 checks two different restrictions: allowType() and 
 isConstructionAllowed(). PortalFolderBase._verifyObjectPaste just checks 
 allowType() because in CMF 2.1 isConstructionAllowed() does basically 
 the same permission check as CopyContainer._verifyObjectPaste. Changing 
 isConstructionAllowed() without changing 
 PortalFolderBase._verifyObjectPaste creates inconsistent behavior. The 
 _checkWorkflowAllowed change and your branch are both broken.

That sounds like there is some opportunity for code sharing there.

 2.) The distinction between allowType() and isConstructionAllowed() was 
 clear in CMF 2.1: allowType() checked a cheap, not permission related 
 CMF specific restriction. isConstructionAllowed() checked generic 
 permission related restictions. The new restrictions 
 _checkWorkflowAllowed and ITypeConstructionFilter don't fit in one of 
 these two categories.

Is there a reason that the two have to be separate? What is the downside
of one call that does all necessary checks?

 3.) I was wrong about comparing isConstructionAllowed with checkFactory 
 and checkObject. These are used for checking general container 
 constraints, not for checking user specific permissions. checkFactory 
 doesn't work for CMF because it doesn't take the portal type as argument.

Right.

 My conclusion:
 
 allowType() and isConstructionAllowed() are both the wrong place for 
 checking additional restrictions. But allowType() could become part of a 
 more general precondition that could be checked by checkObject and a new 
 checkPortalType (=CMF specific checkFactory) function.

How do you see this working? If it's simple enough I might have enough
time to work on it this week.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Customised permissions

[Wichert Akkerman]

Previously Charlie Clark wrote:
 Hi,
 
 this should be a no-brainer but apart from a recent discussion on the  
 death of local permissions I can't much on it - how do I use custom  
 permissions?
 
 I've added them in to zcml but they don't crop up in the security  
 interfaces and, surprise, surprise, I get an error when I try and  
 import a role map that uses them.
 
 permission
   id=charlie.can do everything
   title=Only rulerz can have this permission
 /
 
 Do I need additional Python calls to the security modules to register  
 this?

Not if you use collective.autopermission.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Extending FTI.isConstructionAllowed

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
  I have a use case where I need to put additional restrictions on object 
  creation, in particular I need to restrict the maximum depth of items 
  inside of a container of a specific type. The ideal place to put such a 
  restriction seems to be the isConstructionAllowed method on the FTI. 
  Currently this method is not very extensible, which leads to complicated 
  code in various FTI types.
  
  I am considering to add an extension point here, something like this:
  
  class ITypeConstructionFilter(Interface):
   def __init__(fti, container):
   Adapt on the FTI of the object being created and the target 
  container
  
   def allowed():
   Check if construction is allowed.
  
  
  current checks such as the workflow check that was added in CMF 2.2, or 
  the type constraint logic Plone has in ATContentTypes could be moved to 
  such an adapter. The standard isConstructionAllowed method could then 
  query all registered adapters to check if construction should be possible.
  
  Does this sound sensible?
 
 I'm not sure about querying all adapters:  I think it would be clearer
 to query the one adapter whose name corresponds to the type name of the
 FTI (the query all case leads to tricky / emergent behavior).

Querying a single adapter makes it very hard to use this as an extension
point. Being able to have multiple independent validation-hooks is the
whole point of my suggestion, and being able to only use a single
adapter would make that impossible.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Extending FTI.isConstructionAllowed

[Wichert Akkerman]

Previously yuppie wrote:
 It's no hook for adding restrictions, but it's a hook for using 
 different implementations.
 
  and does not support portal types.
 
 Do you mean does not support per portal type hooks or do you mean 
 does not support filtering based on portal type name?

The latter. zope.* has no concept of FTIs or portal types.

 A CMF specific precondition would look up type restrictions in the fti 
 of the container.
 
 checkFactory and checkObject are quite similar to isConstructionAllowed. 
 I think we should reimplement this based on zope.container before we 
 start adding new features.

I looked at the code in zope.container and frankly it scared me. I found
the documentation and code hard to follow, and the usage of
sys._getframe() made me drop the idea of using it.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Extending FTI.isConstructionAllowed

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
 I have a use case where I need to put additional restrictions on object 
 creation, in particular I need to restrict the maximum depth of items 
 inside of a container of a specific type. The ideal place to put such a 
 restriction seems to be the isConstructionAllowed method on the FTI. 
 Currently this method is not very extensible, which leads to complicated 
 code in various FTI types.
 
 I am considering to add an extension point here, something like this:
 
 class ITypeConstructionFilter(Interface):
  def __init__(fti, container):
  Adapt on the FTI of the object being created and the target 
 container
 
  def allowed():
  Check if construction is allowed.
 
 
 current checks such as the workflow check that was added in CMF 2.2, or 
 the type constraint logic Plone has in ATContentTypes could be moved to 
 such an adapter. The standard isConstructionAllowed method could then 
 query all registered adapters to check if construction should be possible.

I have implemented this on the wichert-constructionfilter branch of
Products.CMFCore. I intend to merge this to trunk end of this week.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] Extending FTI.isConstructionAllowed

[Wichert Akkerman]

I have a use case where I need to put additional restrictions on object 
creation, in particular I need to restrict the maximum depth of items 
inside of a container of a specific type. The ideal place to put such a 
restriction seems to be the isConstructionAllowed method on the FTI. 
Currently this method is not very extensible, which leads to complicated 
code in various FTI types.

I am considering to add an extension point here, something like this:

class ITypeConstructionFilter(Interface):
 def __init__(fti, container):
 Adapt on the FTI of the object being created and the target 
container

 def allowed():
 Check if construction is allowed.


current checks such as the workflow check that was added in CMF 2.2, or 
the type constraint logic Plone has in ATContentTypes could be moved to 
such an adapter. The standard isConstructionAllowed method could then 
query all registered adapters to check if construction should be possible.

Does this sound sensible?

Wichert.

___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Extending FTI.isConstructionAllowed

[Wichert Akkerman]

Previously yuppie wrote:
 Wichert Akkerman wrote:
  I have a use case where I need to put additional restrictions on object 
  creation, in particular I need to restrict the maximum depth of items 
  inside of a container of a specific type. The ideal place to put such a 
  restriction seems to be the isConstructionAllowed method on the FTI. 
  Currently this method is not very extensible, which leads to complicated 
  code in various FTI types.
  
  I am considering to add an extension point here, something like this:
  
  class ITypeConstructionFilter(Interface):
   def __init__(fti, container):
   Adapt on the FTI of the object being created and the target 
  container
  
   def allowed():
   Check if construction is allowed.
  
  
  current checks such as the workflow check that was added in CMF 2.2, or 
  the type constraint logic Plone has in ATContentTypes could be moved to 
  such an adapter. The standard isConstructionAllowed method could then 
  query all registered adapters to check if construction should be possible.
  
  Does this sound sensible?
 
 Question: zope.container.constraints handles this in a different way, 
 using a precondition defined in the interface. Did you have a look at 
 that code? If we switch to that pattern, we could use different 
 preconditions for containers with different interfaces. Would that be 
 sufficient for your use case?

I don't think that is sufficient since it does not provide an extension
point you can hook into and does not support portal types.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Zope dependency

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi all,
 
 The CMF eggs, even on trunk, still advertise compatibility with Zope  
 2.10. I believe we had agreed to target Zope 2.12 with trunk - please  
 correct me if that's wrong. If we do want Zope 2.12 I would like to go  
 through before the first CMF 2.2 beta and do the following:
 
   - adjust all setup.py files to show the Zope2 egg as dependency,  
 which will imply the Zope2 = 2.12dev dependency
 
   - go through and delete all BBB code for Zope versions earlier than  
 2.12
 
 If anyone thinks that's a bad idea please speak up.

I think we are targetting Plone 4 at CMF 2.2 and Zope 2.11 at the
moment, so that would be bad for us.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Zope dependency

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 However, I'd still like to bring up the question of officially  
 supported Zope releases for CMF 2.2.x. Speaking for me personally, I  
 develop CMF trunk against Zope trunk (there's that nifty CMF.buildout  
 package that makes this easy), and it's becoming a greater and greater  
 effort to ensure backwards compatibility for all kinds of  
 combinations. So, what do we want to support?

My vote for CMF 2.2: Zope 2.11 and 2.12

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Need new release 1.4.5 of GenericSetup

[Wichert Akkerman]

Previously Vincent Fretin wrote:
 Hi,
 
 I patched two things in GenericSetup branch 1.4 (merged on trunk as
 well), both items have a test.
 If possible, can you please release a new version so Plone 3.3 can ship with 
 it?
 Plone 3.3 is due normally in less than two weeks.

FWIW I am not convinced this is a showstopper, so I plan to release 3.3
based on the current 3.3rc3 and delay this until 3.3.1.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Workflow transitions automatic state changing

[Wichert Akkerman]

Previously Thomas Dingeldey wrote:
 Hi,
 
 I have a question about the transitions of a workflow.
 In ZMI you could choose the option automatic in a transition. Does the option 
 only remove the action if you call atool.listFilteredActionsFor(item) or is 
 it intended to do some more?
 
 We start a process with a workflow which runs a long time, if the process 
 starts, we move the object into another state with a transition:
 
 wf = getToolByName(self.context, 'portal_workflow')
 wf.doActionFor(self.context, 'send', comment='send')
 
 If the process is finished we like to move the object automatically into 
 another state. Provides the workflow functions which assists this?

from plone.app.workflow:

   # Trigger any automatic transitions, or else just make sure the role 
mappings are right
   auto_transition = new_wf._findAutomaticTransition(obj, 
new_wf._getWorkflowStateOf(obj))
   if auto_transition is not None:
   new_wf._changeStateOf(obj, auto_transition)

new_wf is the workflow used for this object. You can grab that from the workflow
chain configured for the object. You should probably make sure to do this for
every workflow in the chain to make support you handle objects with multiple
workflows correctly.


Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Best use of source numbers in GS upgrade steps?

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Since I made some notes while investigating, I might as well share
 them.  So here are some random observations for reference, with some
 CMFPlone versions thrown in for good measure.
 
 - GS 1.3.3 is used in Plone 3.0.6.
 
 - GS 1.4.1 is used in Plone 3.1.7.
 
 - GS 1.4.2.2 is used in Plone 3.2.2.
 
 - GS 1.4.2.2 is used in Plone 3.3rc1.
 
 - GS trunk (1.5) is used in Plone trunk (4.0).

I'm planning to switch to GS 1.5 for Plone 3.4.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Best use of source numbers in GS upgrade steps?

[Wichert Akkerman]

Previously Rob Miller wrote:
 Maurits van Rees wrote:
  Hi,
  
  I wonder what the best way is of specifying the source number of a
  GenericSetup upgrade step.
  
 ---SNIP a bunch of stuff about how using versions to mark GS upgrade steps 
 is 
 annoying---
 
 yes, as you discovered, using source and destination versions to mark when 
 upgrade steps should be run can be a bit janky.  i realized this when i first 
 ported the upgrade stuff over from CPS, but i wasn't quite sure how else to 
 handle it.
 
 thinking about it now, though, i'd say perhaps the zcml should support only 
 including a source version, with the setup tool persisting the id of each 
 upgrade step when it is run.  then the UI would show an upgrade step as 
 needing to be run if a) the loaded profile version is greater than the source 
 version specified in the ZCML and b) the id of the upgrade step is not yet 
 stored in the setup tool's list of completed steps.

-1

This is a radical change in behaviour, and I'm not convinced it is
better. There may be good reasons to skip certain upgrade steps when you
move from one source to another, which is no longer possible with your
proposal.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] IIndexableObjectWrapper

[Wichert Akkerman]

Previously yuppie wrote:
 Martin Aspeli wrote:
  Plone 3.3's IIndexableObjectWrapper implementation (in plone.indexer) 
  has a method _getWrappedObject(), to return the object that was wrapped 
  by the indexable object wrapper. It is (or rather, will be) used by 
  TextIndexNG3, which needs to access the raw object during indexing.
 
 Why is there a need to access the raw object? The wrapper should provide 
 all the interfaces and attributes required for indexing.

TextIndexNG3 needs the unwrapped object to be able to look for adapters
that provide indexable text for that object.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Proposal: MemberDataFactory

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On Mar 18, 2009, at 16:12 , Wichert Akkerman wrote:
 
  Previously Miles wrote:
  We have quite a lot of copy-and-paste code here in order to support
  using a custom MemberData class for members in particular sites.
 
  The reason for this is that the only way to use a different  
  MemberData
  class is to provide a custom wrapUser method.
 
  I'd like to propose that this is changed to use a factory registered
  through the CA to create new MemberData objects, in order that this  
  is
  pluggable without requiring a custom MemberDataTool.
 
  Can you explain the use case? I suspect you can also solve this with  
  PAS
  and a custom user factory PAS plugin.
 
 One use case I have: I need a different Member Data object (and thus  
 the whole overridden tool) for Products.CMFLDAP in order to have  
 custom overridden methods on those MemberData objects that call non- 
 standard methods on the user folder.

Personally I would rather find a way to get rid of the Member Data
object and rely PAS to provide all the required features. Is there
a reason, other than not wanting to add a dependency on PAS, to use a
Member Data object?

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Proposal: MemberDataFactory

[Wichert Akkerman]

Previously Miles wrote:
 We have quite a lot of copy-and-paste code here in order to support 
 using a custom MemberData class for members in particular sites.
 
 The reason for this is that the only way to use a different MemberData 
 class is to provide a custom wrapUser method.
 
 I'd like to propose that this is changed to use a factory registered 
 through the CA to create new MemberData objects, in order that this is 
 pluggable without requiring a custom MemberDataTool.

Can you explain the use case? I suspect you can also solve this with PAS
and a custom user factory PAS plugin.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] IndexableObjectWrapper

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On Mar 10, 2009, at 09:14 , Raphael Ritz wrote:
 
  Opinions anyone? (ideally including a reasoning beyond
  I want ZPL because that's what Zope itself uses) ;-)
 
 In general, commercial adoption of a software stack is made easier if  
 it is not accompanied by a whole soup of different licenses. The fewer  
 licenses, the better. I'm sure that issue is on your radar already.

It is, which is why the ZPL has already been rejected as an option: it
is pretty much equivalent to the BSD license, which is much more widely
accepted. The ZPL is a Zope Foundation-only license, while one goal of
this push in Plone is to encourage wider adoption of generic components,
even outside of the Zope community where possible.

The debate is currently focusing on GPL versus BSD license. Any opinions
on a choice between those two would be very welcome.

 As you know, all code you'd like pushed down the stack into the CMF or  
 Zope must be licensed under the ZPL. That's also a prerequisite for  
 being stored in the Zope Foundation repositories (a.k.a. svn.zope.org).

I do not think the Plone Foundation board is willing to consider
donating some of its intellectual property to the Zope Foundation. I am
already happy they are willing to consider selective relicensing.

But that does not need to be a problem: reusable packages such as
plone.indexer can be used by CMF even if they are not covered by the ZPL
or managed in svn.zope.org, as long as there is the license is
acceptable.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] IndexableObjectWrapper

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote:
  Previously Jens Vagelpohl wrote:
  In general, commercial adoption of a software stack is made easier if
  it is not accompanied by a whole soup of different licenses. The  
  fewer
  licenses, the better. I'm sure that issue is on your radar already.
 
  It is, which is why the ZPL has already been rejected as an option: it
  is pretty much equivalent to the BSD license, which is much more  
  widely
  accepted.
 
 If they are equivalent, why not dual-license?

What would the advantage be? The ZPL is an exercise of license
proliferation and as far as I can see gives no benefits over BSD.

  The debate is currently focusing on GPL versus BSD license. Any  
  opinions
  on a choice between those two would be very welcome.
 
 The discussion has been rehashed in several places, but given a choice  
 between pretty much anything and the GPL I'd vote -1 on the GPL.

I made a typo there: the discussion is focusing on LGPL versus BSD. I
suspect that will not change your vote though :)

  As you know, all code you'd like pushed down the stack into the CMF  
  or
  Zope must be licensed under the ZPL. That's also a prerequisite for
  being stored in the Zope Foundation repositories (a.k.a.  
  svn.zope.org).
 
  I do not think the Plone Foundation board is willing to consider
  donating some of its intellectual property to the Zope Foundation. I  
  am
  already happy they are willing to consider selective relicensing.
 
 To me this really sounds like the rift has widened, by a whole lot. It  
 reads like we're happy to base our stuff on yours, but we really  
 don't want to give back. I'm sure it's not meant that way, but it  
 reads like that.

It is not that way at all. Plone does want to give back, and by
relicensing components does exactly that. If the BSD is chosen you can
do anything you want with that Plone code, except upload it to
svn.zope.org since that implies transferring ownership, which is not
allowed. This is no different than Zope policies:  you can not
copy code from svn.zope.org to the plone repository either. Or move code
from Repoze to Zope, from Zope to FSF, etc. etc.  The license is
not the limiting factor there, but the surrounding policies are.

  But that does not need to be a problem: reusable packages such as
  plone.indexer can be used by CMF even if they are not covered by the  
  ZPL
  or managed in svn.zope.org, as long as there is the license is
  acceptable.
 
 That's not the issue I was trying to address. I was specifically  
 talking about putting functionality in the most appropriate part of  
 the stack, meaning moving it further towards the core. If there are  
 bits and pieces that make more sense in the CMF then saying well,  
 just install our package may satisfy users, but developers will  
 continue wasting time maintaining different implementations.

Why would there be multiple implementations if they can just use the
existing one? I do not see that. I do agree that work should be in in
CMF itself, and this particular instance of the indexable wrappers is an
excellent example of that. I hope that in the last few years we have
already demonstrated that we really do want to work closer with the
CMF and Zope communities. 

Perhaps in the future the Plone Foundation would be willing to donate
code to the Zope Foundation. At this moment that is a bridge too far,
and I fear that as soon as I suggest that at this point in time the
entire relicensing movement will die in a never-ending debate. Lets
save that one for a later day.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] IndexableObjectWrapper

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On Mar 9, 2009, at 21:09 , Miles wrote:
 
  Can anyone tell me if it is possible to register an adapter to  
  provide a
  different IndexableObjectWrapper class from the stock CMF one?   
  There's
  some sort of framework code that hints that it ought to enable this,  
  but
  I can't see how!
 
  The code still seems to instantiate the wrapper directly using the
  class, rather than looking it up via the component architecture.
 
  Can anyone explain what's going on?  I've drawn a blank from googling
  for examples.
 
 You already noticed that the wrapper is instantiated directly, so  
 that's what's going on. No magic, no component architecture.
 
 Whether that is good or bad or should be changed is a different issue.

Martin Aspeli implemented an adapter based index wrapper for Plone 3.3.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] GenericSetup Zope support

[Wichert Akkerman]

Currently GenericSetup trunk no longer runs on Zope 2.10. If I try to
run the tests I get this:

  File /src/Products.GenericSetup/Products/GenericSetup/registry.py, line 23, 
in ?
from App.class_init import InitializeClass
ImportError: cannot import name InitializeClass

I can see two solutions:

- add a BBB import to import from Globals
- from App.class_init import default__class_init__ as InitializeClass

Does anyone have preferences?

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup Zope support

[Wichert Akkerman]

Previously yuppie wrote:
 Wichert Akkerman wrote:
  Currently GenericSetup trunk no longer runs on Zope 2.10. If I try to
  run the tests I get this:
  
File /src/Products.GenericSetup/Products/GenericSetup/registry.py, line 
  23, in ?
  from App.class_init import InitializeClass
  ImportError: cannot import name InitializeClass
  
  I can see two solutions:
  
  - add a BBB import to import from Globals
  - from App.class_init import default__class_init__ as InitializeClass
  
  Does anyone have preferences?
 
 Well. The third solution is making the next releases of Zope 2.10 and 
 Zope 2.11 required for GenericSetup 1.5.
 
 Importing directly from App.class_init exposed a circular import issue 
 in Zope, see: 
 http://mail.zope.org/pipermail/zope-cmf/2008-December/028003.html
 
 I fixed that issue on Zope 2.10 and Zope 2.11 trunk and added 
 InitializeClass as alias for default__class_init__.
 
 If you really need to run GenericSetup on older versions I'd prefer your 
 first solution (BBB import from Globals) because it makes sure modules 
 are imported in the right order.

I see no good reasons not to support existing Zope 2.10 (and older)
releases, and it would make it possible to use GenericSetup 1.5 with
Plone, which is exactly what I want to do.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup 1.5

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
 Previously Tres Seaver wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  I would like to get a 1.5 release of GenericSetup out over the holidays.
   Here is what I have on the roadmap:
  
   - Clean up the sphinx docs for the package, incorporating / updating
 Rob Miller's excellent tutorial on GS (Rob has already blessed the
 notion).
  
   - Make *much* clearer the idea that content export / import should
 not be treated as part of any normal profile, including adding
 some extra support for doing that task at the application level.
  
   - Tidy up any deprecations when running under Python 2.5 (and maybe
 even 2.6).
  
  Anyone have other stuff they would like to see in the mix (and can help
  land)?
 
 I want to extend the upgrade step logic a bit to allow you to call
 single steps from other profiles. Should be a simple change.

I have commited this. Once the BBB problems with Zope 2.10 are fixed I
have no objections (and would in fact be in favour) of an 1.5 release.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup 1.5

[Wichert Akkerman]

Previously Tres Seaver wrote:
 Are there open bug reports on such problems?  Also, we might not even
 support running on Zope 2.10.x with this release, if it is too painful
 to resolve.

I posted to this list earlier today. It is just a matter of changing a
few imports, so not painful at all.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup Zope support

[Wichert Akkerman]

Previously yuppie wrote:
 Wichert Akkerman wrote:
  Previously yuppie wrote:
  If you really need to run GenericSetup on older versions I'd prefer your 
  first solution (BBB import from Globals) because it makes sure modules 
  are imported in the right order.
  
  I see no good reasons not to support existing Zope 2.10 (and older)
  releases, and it would make it possible to use GenericSetup 1.5 with
  Plone, which is exactly what I want to do.
 
 In case you are waiting for a go-ahead:
 
 I didn't remember the GenericSetup 1.5 release is scheduled before the 
 next Zope 2.10 release. In that case the BBB import from Globals is 
 obviously the right solution.

Done. All tests run on both Zope 2.10 and Zope 2.12 now.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup 1.5

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
  Previously Tres Seaver wrote:
  Are there open bug reports on such problems?  Also, we might not even
  support running on Zope 2.10.x with this release, if it is too painful
  to resolve.
  
  I posted to this list earlier today. It is just a matter of changing a
  few imports, so not painful at all.
 
 I'm a little puzzled:  you expect to be able to upgrade to a new major
 release of GenericSetup (1.4.x - 1.5.0), but not to pick up a minor
 update to Zope (2.10.x - 2.10.latest)?  Doesn't make much sense to me:
  if stability matters that much, then don't figure on upgrading products
 to new, possibly incompatible versions.

There is no minor Zope 2.10 release which has these changes.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] CMF 2.2 plans?

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 02.03.2009 um 19:46 schrieb Hanno Schlichting:
 
  This can happen in two ways, though. Either move the example- 
  application
  bits into a different package or move the reusable bits into one. If  
  you
  are really interested in doing this work, I'd be happy to figure out
  what parts of CMFDefault Plone is actually using.
 
 
 I think this is essential. While I maintain the CMFDefault is an  
 excellent start for many websites, Plone should not be *directly*  
 dependent upon it - there are just too many conceptional differences  
 and by now also too many stylistic ones as well.

+1

This goes in two ways: some bits of CMFCore should probably be in
CMFDefault as well.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated

[Wichert Akkerman]

Previously Raphael Ritz wrote:
 Charlie Clark wrote:
  Am 18.02.2009 um 21:51 schrieb Wichert Akkerman:
  
  In my opinion a copy should produce a full copy, including all state  
  and
  history.
 
 Not sure I would  agree here.
 For a move (cutpaste) yes but for a copy I think
 there are too many different use cases to justify
 your claim above.

There are many use cases for both options. One aspect is that it is
extremely hard to not get the current behaviour. We had to hire Philipp
to write z3c.unconfigure for us just to be able to create a system
to prevent CMF from making changes on copies.

Wichert

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 25.02.2009 um 14:18 schrieb Wichert Akkerman:
 
  There are many use cases for both options. One aspect is that it is
  extremely hard to not get the current behaviour. We had to hire  
  Philipp
  to write z3c.unconfigure for us just to be able to create a system
  to prevent CMF from making changes on copies.
 
 
 First of all I'm not sure if that's such a bad thing! ;-)
 
 But the solution would probably be making this behaviour configurable  
 somewhere in the workflow tool.

The workflow tool is not a factor at all here. The problem is that CMF
registers some event handlers that do things like clear workflow status
and local roles when you create a copy.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
  Previously Charlie Clark wrote:
  Am 25.02.2009 um 16:10 schrieb Wichert Akkerman:
  The workflow tool is not a factor at all here. The problem is that CMF
  registers some event handlers that do things like clear workflow  
  status
  and local roles when you create a copy.
  I realise that but surely the handlers can have a default behaviour  
  that can be changed depending on the configuration?
  
  In my opinion they should not be globally registered at all, but
  available for registration in a local site manager. CMFDefault could
  then do that registration for its needs.
 
 You are in the cleft stick created by the paradox of reusable
 configuration (an oxymoron, even).  The other alternative is to *not*
 include/ the configuration from CMFDefault, but copy and tweak it for
 your own app.

Not including CMFDefault is entirely reasonable. There are two problems
though:

- CMFDefault is in the Products namespace, so five will load its zcml
  automatically.

- some of these are in CMFCore (handleDynamicTypeCopiedEvent for
  example, which zaps local roles from copies). Asking people to
  copy CMFCore configuration for a reasonably common use case is
  not desirable imho.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated

[Wichert Akkerman]

Previously yuppie wrote:
 Tres Seaver wrote:
  yuppie wrote:
  Moving the notifyWorkflowCreated call from _finishConstruction to the 
  IObjectAddedEvent subscriber changed the behavior of .zexp imports: The 
  workflow state is now always reset to the initial state. AFAICT that's 
  no useful behavior for imports.
 
  This is caused by the fact that the notifyCreated method of WorkflowTool 
  always resets the workflow states.
 
  Is that a feature or a bug of notifyCreated? Is anybody using 
  notifyCreated for resetting workflow states?
 
 It turned out that CMF itself uses notifyCreated for resetting workflow 
 states :(
 
 That's how copy and paste resets the workflow state.

Which is argueably a mis-feature: it means you are not just doing a copy
and paste, but a copy, paste and modify.

  Where is the best place to fix this? Should IObjectAddedEvent be 
  triggered on imports? Should the subscriber call notifyWorkflowCreated 
  if the object already has a workflow history? Should 
  notifyWorkflowCreated call WorkflowTool.notifyCreated if the object 
  already has a workflow history? Should WorkflowTool.notifyCreated call 
  notifyCreated of workflows that already have a state? Should 
  notifyCreated of workflows keep existing states untouched?
 
 
  AFAICS the easiest way to fix this is changing 
  WorkflowTool.notifyCreated, making sure it only calls notifyCreated for 
  workflows without a state in the workflow history.
  
  +1.
 
 This alone will not work.
 
 Does it make sense to keep old workflow history records after copy and 
 paste? Or can we just remove the complete workflow_history attribute 
 before notifyCreated is called?

In my opinion a copy should produce a full copy, including all state and
history.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] GenericSetup 1.5

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I would like to get a 1.5 release of GenericSetup out over the holidays.
  Here is what I have on the roadmap:
 
  - Clean up the sphinx docs for the package, incorporating / updating
Rob Miller's excellent tutorial on GS (Rob has already blessed the
notion).
 
  - Make *much* clearer the idea that content export / import should
not be treated as part of any normal profile, including adding
some extra support for doing that task at the application level.
 
  - Tidy up any deprecations when running under Python 2.5 (and maybe
even 2.6).
 
 Anyone have other stuff they would like to see in the mix (and can help
 land)?

I want to extend the upgrade step logic a bit to allow you to call
single steps from other profiles. Should be a simple change.

Wichert.

-- 
Wichert Akkerman wich...@wiggy.netIt is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?

[Wichert Akkerman]

Previously yuppie wrote:
 I'm not sure if the import/export steps used by CMF are clean or if 
 nobody recognized the issue because nobody runs import/export steps from 
 a portal_setup tool that was looked up as utility. Maybe the issue just 
 shows up in combination with portal_quickinstall?
 
 I don't like to remove CMF's portal_setup registration *if* CMF itself 
 is not affected by this issue.

Imho registering portal_setup as a utility as long as any CMF tool uses
self.REQUEST is problematic since it makes it impossible for
import/export steps to use such tools.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 On Nov 16, 2008, at 22:30 , Wichert Akkerman wrote:
  Previously yuppie wrote:
  I don't like to remove CMF's portal_setup registration *if* CMF  
  itself
  is not affected by this issue.
 
  Imho registering portal_setup as a utility as long as any CMF tool  
  uses
  self.REQUEST is problematic since it makes it impossible for
  import/export steps to use such tools.
 
 
 I suggest we *look* at the current CMF situation before acting on the  
 assumption that non-utility tools are used in (and break) CMF import/ 
 export steps. It's been working fine so far.

I'm sure CMF import/export steps are fine. The CMF tools are not, and
third party products use those in their steps. That is exactly the
problem we where seeing in Plone, and which is why I removed the utility
registration.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?

[Wichert Akkerman]

Previously Raphael Ritz wrote:
 Currently, CMF(Default - and Plone for that matter) does not support
 this OOTB because CMFDefault's MembershipTool uses a simple getattr
 call for the 'membersfolder_id' on the site object.
 Changing this to use 'unrestrictedTraverse' instead resolves
 the problem including the possibility to specify the path (or
 relative content URL) to the folder in ZMI.

Shouldn't it use restrictedTraverse? Is there a special reason you want
to bypass security?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] genericsetup:upgradeDepends

[Wichert Akkerman]

Previously Rob Miller wrote:
 hi all,
 
 i've got a GenericSetup branch called 'ra-depends-tag' with a working 
 implementation of a genericsetup:upgradeDepends ZCML tag.  this tag can 
 be used anywhere that you could use a genericsetup:upgradeStep tag (i.e. 
 either standalone, or nested within a genericsetup:upgradeSteps).  in 
 fact, upgradeDepends is simply a special case of upgradeStep that allows 
 you to specify a set of profile import steps to be re-applied to the site, 
 rather than calling a generic python handler.
 
 here's an example of how it looks:
 
 genericsetup:upgradeDepends
 profile=Products.Something:default
 source=1.0
 destination=1.1
 sortkey=10
 title=Re-run 'foo' import step
 import_steps=foo
 purge=True
 run_deps=False
 /

I would like to see a simple extension: the ability to run one or more
steps from another profile. This can be very useful when you run
upgrades for a base profile which load (steps from a) profile from an
add-on package.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] genericsetup:upgradeDepends

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
 Previously Rob Miller wrote:
  hi all,
  
  i've got a GenericSetup branch called 'ra-depends-tag' with a working 
  implementation of a genericsetup:upgradeDepends ZCML tag.  this tag can 
  be used anywhere that you could use a genericsetup:upgradeStep tag (i.e. 
  either standalone, or nested within a genericsetup:upgradeSteps).  in 
  fact, upgradeDepends is simply a special case of upgradeStep that allows 
  you to specify a set of profile import steps to be re-applied to the site, 
  rather than calling a generic python handler.
  
  here's an example of how it looks:
  
  genericsetup:upgradeDepends
  profile=Products.Something:default
  source=1.0
  destination=1.1
  sortkey=10
  title=Re-run 'foo' import step
  import_steps=foo
  purge=True
  run_deps=False
  /
 
 I would like to see a simple extension: the ability to run one or more
 steps from another profile. This can be very useful when you run
 upgrades for a base profile which load (steps from a) profile from an
 add-on package.

.. and support upgrade-profiles similar to what we have been using for
Plone releases for a while now. Extremely useful stuff.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] using zope.dublincore in CMFCore

[Wichert Akkerman]

Currently CMFCore and zope.dublincore duplicate some of the DC
interfaces. zope.dublincore even has an ICMFDublinCore interface
explicitly dublicing CMFCore's version.

Are there any objections to making the CMFCore interfaces derived
classes from zope.dublincore, or possibly even using those directly
where possible?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] using zope.dublincore in CMFCore

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 On Sep 23, 2008, at 17:01 , Wichert Akkerman wrote:
 
  Currently CMFCore and zope.dublincore duplicate some of the DC
  interfaces. zope.dublincore even has an ICMFDublinCore interface
  explicitly dublicing CMFCore's version.
 
  Are there any objections to making the CMFCore interfaces derived
  classes from zope.dublincore, or possibly even using those directly
  where possible?
 
 Do you see any specific benefit, more than just replace our code with  
 other code to shift the maintenance burden?

I found myself writing some code which needs to get dublin core data from
content and should work for both zope3 and zope2 applications, except
for the difference in interfaces.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] 'add' actions and views - a proposal

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 Wichert Akkerman wrote:
  Previously Martin Aspeli wrote:
  Hi Yuppie,
 
  1.) CMF add views adapt not only container and request, but also the 
  type info object. This way the views can't be accessed directly and 
  have 
  self.fti available.
  This is quite interesting, and possibly necessary. However, it means 
  that CMF add views are not just views and will need to be registered 
  differently to other views (i.e. you can't just use browser:page / 
  which also means that you won't get the Five security treatment etc).
  Yes. This causes more problems than it solves. I think I found a much 
  better solution:
 
  CMF add views are registered for a special layer called IAddViewLayer. 
  Like any other layer, IAddViewLayer extends IBrowserRequest. And it 
  defines an additional 'ti' attribute for the request.
 
  Like before views can't be accessed directly and have self.ti available. 
  (I now use 'ti' instead of 'fti' because we have other type info 
  implementations than FactoryTypeInformation.)
  I'm not sure I like this much more. It involves adding a marker 
  interface to the request conditionally during traversal. You'll possibly 
  run into funny sequence dependent conditions if you want to customise 
  the add view for a particular theme browser layer.
 
  My preference would be:
 
- Define an interface IFTIAwareView that has an 'fti' property
- Define a traversal view (@@add) that does this kind of thing on 
  traversal:
  
  Why not a ++add++ traverser? Aren't traversed supposed to be used for
  that kind of thing? Or does a view gives us something here that a
  traverser doesn't?
 
 Namespace traversal adapters are similar to IPublishTraverse solutions. 
 The difference is that the namespace traversal adapter normally returns 
 something containerish from which traversal continues. I think it's 
 intended mostly as a redirect to a different traversal namespace, e.g. 
 in the way that plone.app.portlets has namespaces for portlet managers.

The containerish thing is just a lookup-mechanism, which could be a very
simple thing to figure out the right add view, which shouldn't be
more than half a dozen lines of code. It feels like a perfect fit to
me. 

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] 'add' actions and views - a proposal

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 Wichert Akkerman wrote:
  Previously Martin Aspeli wrote:
  Wichert Akkerman wrote:
  Previously Martin Aspeli wrote:
  Hi Yuppie,
 
  1.) CMF add views adapt not only container and request, but also the 
  type info object. This way the views can't be accessed directly and 
  have 
  self.fti available.
  This is quite interesting, and possibly necessary. However, it means 
  that CMF add views are not just views and will need to be registered 
  differently to other views (i.e. you can't just use browser:page / 
  which also means that you won't get the Five security treatment etc).
  Yes. This causes more problems than it solves. I think I found a much 
  better solution:
 
  CMF add views are registered for a special layer called IAddViewLayer. 
  Like any other layer, IAddViewLayer extends IBrowserRequest. And it 
  defines an additional 'ti' attribute for the request.
 
  Like before views can't be accessed directly and have self.ti 
  available. 
  (I now use 'ti' instead of 'fti' because we have other type info 
  implementations than FactoryTypeInformation.)
  I'm not sure I like this much more. It involves adding a marker 
  interface to the request conditionally during traversal. You'll possibly 
  run into funny sequence dependent conditions if you want to customise 
  the add view for a particular theme browser layer.
 
  My preference would be:
 
- Define an interface IFTIAwareView that has an 'fti' property
- Define a traversal view (@@add) that does this kind of thing on 
  traversal:
  Why not a ++add++ traverser? Aren't traversed supposed to be used for
  that kind of thing? Or does a view gives us something here that a
  traverser doesn't?
  Namespace traversal adapters are similar to IPublishTraverse solutions. 
  The difference is that the namespace traversal adapter normally returns 
  something containerish from which traversal continues. I think it's 
  intended mostly as a redirect to a different traversal namespace, e.g. 
  in the way that plone.app.portlets has namespaces for portlet managers.
  
  The containerish thing is just a lookup-mechanism, which could be a very
  simple thing to figure out the right add view, which shouldn't be
  more than half a dozen lines of code. It feels like a perfect fit to
  me. 
 
 I don't feel particularly strongly either way, so long as there's an 
 actual namespace rather than a naming convention and we avoid an 
 IPublishTraverse adapter for all IFolderish.
 
 ++add++PortalType is a bit uglier than /@@add/PortalType IMHO, but it's 
 a transient URL so it doesn't really matter.

It makes it more explicit that there is no real @@add 'thing' that
is traversed over.

 I think it's worth finding out why we have +/IAdding being a view and 
 not a namespace traversal adapter, though. It feels that things like 
 ++skin++ or ++vh++ are a bit different to ++add++, though perhaps not.

The + naming for IAdding has always been a mystery to me. It feels very
out of place considering that it is just about traversing into a
add-view namespace.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFActionIcons vs. new-style actions

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On Sep 18, 2008, at 09:56 , Wichert Akkerman wrote:
  I'm not the greatest artist in the world, if anyone dislikes a
  particular icon please feel free to replace it with something that
  makes sense to a normal user. Just make sure it has a transparent
  background.
 
  Are they png images? If not, can we please make them png so we can
  easily customize them using alpha channels?
 
 Of course they are. I thought you were on the checkins list ;-)

I am, but I don't memorize all mails sent over it :)

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFActionIcons vs. new-style actions

[Wichert Akkerman]

Previously yuppie wrote:
 I personally prefer to move all type info Actions to the actions tool. I 
 can't see a need to specify separate 'view', 'edit' or 'metadata' 
 Actions for each content type. That just makes it necessary to maintain 
 a lot of redundant configuration data. In how many places did you have 
 to set string:${portal_url}/edit_icon.png?

Per-type edit and view actions are a very important customization point.
We should not make it harder for people to do that. Per-type actions are
very common in Plone, I'ld hate to loose them.

A good alternative might be to have a concept of action-overrides: a
set of actions that override or extend the global list of actions for
a specific context. That is something that I've wanted a few times and
could replace per-type actions.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFActionIcons vs. new-style actions

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 Jens Vagelpohl wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Today I was looking at the CMFActionIcons product and wondered about a  
  few things. First of all, there's no obvious way to enable the actions  
  and include the template snippets that pull them in. Editing the  
  main_template is needed. Secondly, the new-style actions already  
  define a property to store an expression for generating a icon path,  
  but it doesn't appear to be used anywhere yet.
  
  Question: Wouldn't it make sense to enable the new action icons  
  functionality in the various templates to show icons if an expression  
  for an icon is provided, and completely retire the CMFActionIcons  
  product?
 
 +1 - CMFActionIcons is a bit of a nuisance these days. I never 
 understood why you'd need to separate the definition of the action (in 
 the ZMI or GS) from its icon.

Easier customization - no need to let people touch the action itself?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Currently this buildout (cmf-21 at least) pulls in
 Products.GenericSetup 1.4.1 from the cheese shop.  I am curious: why
 is it not in the src/ here?

Why should it? GenericSetup is not a real part of CMF and has its own
releases.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 By the way, DCWorkflow needed a similar change to make that same  
 traceback disappear, which means Wichert was testing CMFCore in  
 isolation. If possible, could we make sure to test all CMF packages  
 together when making changes? I'm using a simple buildout that pulls  
 them all in:
 
 http://svn.dataflake.org/svn/sandboxes/cmf-21/
 
 http://svn.dataflake.org/svn/sandboxes/cmf-trunk/

Can you move/copy those to svn.zope.org?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On Sep 10, 2008, at 07:53 , Wichert Akkerman wrote:
 
  Previously Wichert Akkerman wrote:
  Ah, I complained about that to Jens: he pinned the CMF eggs to an  
  exact
  version of GenericSetup, which makes them impossible to use for Plone
  which requires a later version.
 
  Can these please be changed to a minimum version requirement  
  instead of
  an exact pin?
 
  I've loosened the version restriction in CMF 2.1 to only use a minimum
  version requirement for GenericSetup, which makes it possible to use  
  CMF
  with Plone 3.2 and later again.
 
  Jens, can you please cut a new beta egg so we can move forward with
  Plone 3.2?
 
 There is a reason why originally I pinned the egg at 1.33, and later  
 relaxed the pin to allow anything 1.3.x: I see test failures with the  
 1.4.1 egg. Please run the tests with the GS 1.4.1 egg and let me know  
 what you see. I am seeing errors like this:

Is there a conveient buildout I can checkout for this? The cmfout on
plone.org appears to be broken and my current location has incredibly
crappy bandwidth, making every svn access insanely slow, so it's a bit
hard to checkout everything by hand.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Jens Vagelpohl, on 2008-09-10:
  There is a reason why originally I pinned the egg at 1.33, and later  
  relaxed the pin to allow anything 1.3.x: I see test failures with the  
  1.4.1 egg. Please run the tests with the GS 1.4.1 egg and let me know  
  what you see. I am seeing errors like this:
 
 
 snip
   raise ConfigurationError(Unknown directive, ns, n)
  zope.configuration.xmlconfig.ZopeXMLConfigurationError: File /usr/ 
  local/zope/cmf-21/eggs/Products.GenericSetup-1.4.1-py2.4.egg/Products/ 
  GenericSetup/configure.zcml, line 62.2
   ConfigurationError: ('Unknown directive', 
  u'http://namespaces.zope.org/genericsetup' 
  , u'exportStep')
 /snip
 
 I see the same.  I suspect that this is only some test setup that is
 missing, or a missed loading of the meta.zcml of GenericSetup, but my
 testing Fu fails to point me in the right direction here.
 
 GS introduces new features, but I am not aware of any backwards
 incompatible changes.  Am I correct in that?

GS trunk drops some long-deprecated bits which CMF isn't using anyway,
but 1.4 should be fully backwards compatible with 1.3.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 There is a reason why originally I pinned the egg at 1.33, and later  
 relaxed the pin to allow anything 1.3.x: I see test failures with the  
 1.4.1 egg. Please run the tests with the GS 1.4.1 egg and let me know  
 what you see. I am seeing errors like this:
 
 
 snip
  raise ConfigurationError(Unknown directive, ns, n)
 zope.configuration.xmlconfig.ZopeXMLConfigurationError: File /usr/ 
 local/zope/cmf-21/eggs/Products.GenericSetup-1.4.1-py2.4.egg/Products/ 
 GenericSetup/configure.zcml, line 62.2
  ConfigurationError: ('Unknown directive', 
 u'http://namespaces.zope.org/genericsetup' 
 , u'exportStep')
 /snip

It was probably pure luck that that used to work before: CMFCore's
testing.py forgot to load meta.zcml from GenericSetup. I've fixed that
and the tests run fine now.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Wichert Akkerman, on 2008-09-08:
  While working on plonenext I get an error when trying to install
  the Products.CMFDefault egg. This is the buildout -vv output:
 (...)
  While:
Installing instance.
Getting distribution for 'Products.CMFDefault'.
  Error: Couldn't install: Products.CMFDefault 2.1.2-beta
 
 
  Which is not very informative. Does anyone know what might cause this?
 
 Not very informative indeed.  bin/buildout -Nv in plonenext gives me
 this more informative output instead:
 
 While:
   Installing instance.
 Error: There is a version conflict.
 We already have: Products.GenericSetup 1.4.1
 but Products.CMFActionIcons 2.1.2-beta requires 
 'Products.GenericSetup==1.3.3'.
 but Products.CMFCalendar 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
 but Products.CMFCore 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
 but Products.CMFDefault 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
 but Products.CMFTopic 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
 but Products.CMFUid 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
 but Products.DCWorkflow 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
 
 So the question is: why are those products depending on GS 1.3.3?  GS
 1.4 has been out for a while.

Ah, I complained about that to Jens: he pinned the CMF eggs to an exact
version of GenericSetup, which makes them impossible to use for Plone
which requires a later version.

Can these please be changed to a minimum version requirement instead of
an exact pin?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
 Previously Maurits van Rees wrote:
  Wichert Akkerman, on 2008-09-08:
   While working on plonenext I get an error when trying to install
   the Products.CMFDefault egg. This is the buildout -vv output:
  (...)
   While:
 Installing instance.
 Getting distribution for 'Products.CMFDefault'.
   Error: Couldn't install: Products.CMFDefault 2.1.2-beta
  
  
   Which is not very informative. Does anyone know what might cause this?
  
  Not very informative indeed.  bin/buildout -Nv in plonenext gives me
  this more informative output instead:
  
  While:
Installing instance.
  Error: There is a version conflict.
  We already have: Products.GenericSetup 1.4.1
  but Products.CMFActionIcons 2.1.2-beta requires 
  'Products.GenericSetup==1.3.3'.
  but Products.CMFCalendar 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
  but Products.CMFCore 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
  but Products.CMFDefault 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
  but Products.CMFTopic 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
  but Products.CMFUid 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
  but Products.DCWorkflow 2.1.2-beta requires 'Products.GenericSetup==1.3.3'.
  
  So the question is: why are those products depending on GS 1.3.3?  GS
  1.4 has been out for a while.
 
 Ah, I complained about that to Jens: he pinned the CMF eggs to an exact
 version of GenericSetup, which makes them impossible to use for Plone
 which requires a later version.
 
 Can these please be changed to a minimum version requirement instead of
 an exact pin?

I've loosened the version restriction in CMF 2.1 to only use a minimum
version requirement for GenericSetup, which makes it possible to use CMF
with Plone 3.2 and later again.

Jens, can you please cut a new beta egg so we can move forward with
Plone 3.2?

Wichert.
 
-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] CMFDefault 2.1.2-beta egg does not install

[Wichert Akkerman]

While working on plonenext I get an error when trying to install
the Products.CMFDefault egg. This is the buildout -vv output:

Getting required 'Products.CMFDefault'
  required by Products.CMFDiffTool 0.4dev.
  required by Products.CMFTopic 2.1.2-beta.
  required by Products.CMFPlone 3.1.5dev.
Getting distribution for 'Products.CMFDefault'.
We have the best distribution that satisfies 'setuptools'.
Picked: setuptools = 0.6c8
Running easy_install:
/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python
 -c from setuptools.command.easy_install import main; main() -mUNxd 
/Users/wichert/Development/instances/plonenext/eggs/tmpC1v2O- 
/Users/wichert/Development/instances/plonenext/download/dist/Products.CMFDefault-2.1.2-beta.tar.gz
path=/Users/wichert/Library/eggs/setuptools-0.6c8-py2.4.egg

Processing Products.CMFDefault-2.1.2-beta.tar.gz
error: None
An error occured when trying to install Products.CMFDefault 2.1.2-beta.Look 
above this message for any errors thatwere output by easy_install.
While:
  Installing instance.
  Getting distribution for 'Products.CMFDefault'.
Error: Couldn't install: Products.CMFDefault 2.1.2-beta


Which is not very informative. Does anyone know what might cause this?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Eggified CMF 2.1.1 now available

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 
 On Aug 3, 2008, at 18:19 , Tres Seaver wrote:
 
  I created satellite versions of the 2.1.1 eggs for the remaining CMF
  products this morning:
 
  - CMFDefault
  - CMFTopic
  - CMFActionIcons
  - CMFCalendar
  - CMFUid
  - DCWorkflow
 
  Source distributions for the 2.1.1 versions are now available on PyPI.
 
 With there being no clear roadmap for 2.2 releases yet, would there be  
 any desire to move the 2.1 branch over to new style separate  
 products which would make it easier to release them as eggs? I would  
 have time to do this during a sprint later this month.

+1

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Generic Setup metadata.xml

[Wichert Akkerman]

Previously Robert Niederreiter wrote:
 When providing a metadata.xml file, GenericSetup's registerProfile
 directive crashes if dependencies/dependencies is provided as empty
 tag with a key error (GS v 1.4.1)

Can you submit a bugreport to launchpad?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: Add forms and menus

[Wichert Akkerman]

Previously Martin Aspeli wrote:
 
  it's not that big architectual change. everything else discussed is
  possible anyway. i would rather call it a feature than a design change
  (since the change happens anyway).
 
 I think it's a fairly big shift to assume that the FTI has knowledge of the
 schema of the type. It's not necessarily a *bad* idea (at least I don't think
 so, since this is basically how Dexterity works :-), but right now,
 FTI doesn't have any notion of a schema. With this change, you're
 effectively dictating (or strongly suggesting) that all CMF types have
 a schema and that this is the basis for forms, and suggesting that
 forms aren't registered as independent views but rather inferred from
 this schema.

Possibly related: I have often had a desire to be able to annotate or
extend the FTI. In Plone (and to a lesser degree CMF) we have lots of
settings that change a portal type's behaviour that are stored in
various places: versioning settings, markup configuration, workflow
chains, etc.

I suppose there is no reason not to use annotations on the FTI right
now; perhaps we should investigate migrating some things in that
direction.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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 Tests: 6 OK, 3 Failed

[Wichert Akkerman]

Previously CMF Tests Summarizer wrote:
 Test failures
 -
 
 Subject: FAILED (errors=2) : CMF-trunk Zope-2.10 Python-2.4.4 : Linux
 From: CMF Tests
 Date: Wed Jul  9 21:45:13 EDT 2008
 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009278.html
 
 Subject: FAILED (errors=2) : CMF-trunk Zope-2.11 Python-2.4.4 : Linux
 From: CMF Tests
 Date: Wed Jul  9 21:46:43 EDT 2008
 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009279.html
 
 Subject: FAILED (errors=2) : CMF-trunk Zope-trunk Python-2.4.4 : Linux
 From: CMF Tests
 Date: Wed Jul  9 21:48:13 EDT 2008
 URL: http://mail.zope.org/pipermail/cmf-tests/2008-July/009280.html

These are my fault; I'll look at them tonight.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Inconstancy with CA traversal

[Wichert Akkerman]

Previously Dylan Jay wrote:
 I've observed an unexpected effect that you can override a skin based 
 template or python script with a browser view in a sub folder but not at 
 the portal root.
 I'm trying to get my head round all the various traversal code in 
 zope/five and would appreciate any tips from someone who knows this code 
 well.

For some unknown reason CMF explicitly encoded that behaviour in
__bobo_traverse__. It's bitten Plone as well.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: Problem with Registering Local Utilities on reinstall of product

[Wichert Akkerman]

Previously Hanno Schlichting wrote:
 The code here does seem indeed to be wrong. There's two modes for GS 
 import handlers, one being with purge and one without. The code in 
 question does not support that correctly. It does work in some cases, as 
 the underlying registerUtility function first checks if the component 
 was already registered. It does so effectively by checking the newly 
 registered object and the one that is already registered for equality. 
 This check obviously fails in case of creating a new utility via a factory.

This is due to an underlying problem in the ZCA that hurts GenericSetup
in several places: it is impossible to determine if a factory or an object
was registered. Without knowing that information it is also impossible
to reliably do an export. Once that has been corrected in zope.component
GenericSetup can be adjusted.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Packaging for Products.GenericSetup and others

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 
 On Jun 11, 2008, at 14:31 , Wichert Akkerman wrote:
 
 Previously Jens Vagelpohl wrote:
 Hi guys,
 
 I'm wondering about the need to provide tarballs for GenericSetup
 through zope.org alongside the tarball on PyPI. It's extra work and
 the GenericSetup pages on zope.org don't offer any added value over
 its PyPI page.
 
 We'll keep using tarballs for Plone 3.1.x maintenance releases. We may
 switch to the egg variant for Plone 3.2, but not before.
 
 For the current release branch I would not have a problem making the  
 tarball manually alongside the PyPI releases if you need them and give  
 me a heads-up about what you need.

That certainly works for us. Thanks.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Packaging for Products.GenericSetup and others

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 Hi guys,
 
 I'm wondering about the need to provide tarballs for GenericSetup  
 through zope.org alongside the tarball on PyPI. It's extra work and  
 the GenericSetup pages on zope.org don't offer any added value over  
 its PyPI page.

We'll keep using tarballs for Plone 3.1.x maintenance releases. We may
switch to the egg variant for Plone 3.2, but not before.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: License file question

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Wichert Akkerman, on 2008-05-29:
  Previously Philipp von Weitershausen wrote:
  But personally I like having it inside the main
  folder, so in your example above it would be
  incf.applications/incf/applications/HISTORY.txt 
  
  There's some benefit to that because it'll be part of the egg.
 
  You probably want to use a MANIFEST.in anyway and that can easily be
  used to include everything in doc/ or other places.
 
 A 'python setup.py sdist' will include the docs directory, as long as
 it is in subversion (and has at least one file in it).

And when someone installs from that sdist and there is no MANIFEST.in
you suddenly end up with installs which are missing data files, zcml
files or other things. 

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: License file question

[Wichert Akkerman]

Previously Philipp von Weitershausen wrote:
 But personally I like having it inside the main
 folder, so in your example above it would be
 incf.applications/incf/applications/HISTORY.txt 
 
 There's some benefit to that because it'll be part of the egg.

You probably want to use a MANIFEST.in anyway and that can easily be
used to include everything in doc/ or other places.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: License file question

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Wichert Akkerman, on 2008-05-29:
  Previously Maurits van Rees wrote:
  Wichert Akkerman, on 2008-05-29:
   Previously Philipp von Weitershausen wrote:
   But personally I like having it inside the main
   folder, so in your example above it would be
   incf.applications/incf/applications/HISTORY.txt 
   
   There's some benefit to that because it'll be part of the egg.
  
   You probably want to use a MANIFEST.in anyway and that can easily be
   used to include everything in doc/ or other places.
  
  A 'python setup.py sdist' will include the docs directory, as long as
  it is in subversion (and has at least one file in it).
 
  And when someone installs from that sdist and there is no MANIFEST.in
  you suddenly end up with installs which are missing data files, zcml
  files or other things. 
 
 Is there a difference in that regard between easy installing an sdist
 or a bdist_egg?  I would think/hope that the end result is the same.

Yes. If you make the bdist_egg from a svn checkout it includes all files
that are in subversion. If you make an egg from something else like a
sdist or a svn export that does not happen (since the svn information is
not available).

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: License file question

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Wichert Akkerman, on 2008-05-29:
  Previously Maurits van Rees wrote:
  Wichert Akkerman, on 2008-05-29:
   Previously Maurits van Rees wrote:
   Wichert Akkerman, on 2008-05-29:
Previously Philipp von Weitershausen wrote:
But personally I like having it inside the main
folder, so in your example above it would be
incf.applications/incf/applications/HISTORY.txt 

There's some benefit to that because it'll be part of the egg.
   
You probably want to use a MANIFEST.in anyway and that can easily be
used to include everything in doc/ or other places.
   
   A 'python setup.py sdist' will include the docs directory, as long as
   it is in subversion (and has at least one file in it).
  
   And when someone installs from that sdist and there is no MANIFEST.in
   you suddenly end up with installs which are missing data files, zcml
   files or other things. 
  
  Is there a difference in that regard between easy installing an sdist
  or a bdist_egg?  I would think/hope that the end result is the same.
 
  Yes. If you make the bdist_egg from a svn checkout it includes all files
  that are in subversion. If you make an egg from something else like a
  sdist or a svn export that does not happen (since the svn information is
  not available).
 
 Without a MANIFEST.in, the egg resulting from an sdist that is
 easy_installed is the same as a bdist_egg, right?  Indeed when I try
 that for plone.portlet.static this is the case.  So having a
 MANIFEST.in makes no real difference in that regard.

I'm not sure what you mean. The basic algorihm is:

- MANIFEST is used to determine what is installed, or
- subversion workingcopy information is used to determine what is installed, or
- a default ruleset is used

This algorithm is used at the moment a 'binary installation' is made,
which is either when you build an egg using setup.py bdist_egg or when
you install an egg from source (ie from a sdist or an unpacked tree).

You can find full documentation on
http://peak.telecommunity.com/DevCenter/setuptools

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: License file question

[Wichert Akkerman]

Previously Maurits van Rees wrote:
 Jens Vagelpohl, on 2008-05-29:
 
  On May 29, 2008, at 04:19 , Philipp von Weitershausen wrote:
  [1] 
  http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt
 
  Ah, good resource, thanks for pointing that out.
 
  Thanks to everyone for the input. I'll go with putting the license  
  file right with the software instead of into a docs folder at the top  
  where setup.py resides. I find it more intuitive to have all  
  documentation where the software is, and leave the egg scaffolding  
  in a state where you don't have to touch anything up high once it's  
  working.
 
 Suits me fine.  Anyone in favour of updating the ZopeSkel templates to
 fit that pattern?  (Sorry, bit out of topic here on the cmf list as
 there are no cmf skeletons there.  Care to add one? :-))

-1

I want all documentation to be the first thing I see when I unpack
something. I don't want to be forced to delve into 3 or 4
subdirectories.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] newstyle content creation

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 23.04.2008 um 11:12 schrieb yuppie:
 
 Charlie Clark wrote:
 Am 22.04.2008 um 17:24 schrieb yuppie:
 Yes. Missing is the integration in the CMFDefault add menu. For  
 now the new 'add_file' action is used for showing the link to  
 'addFile.html'.
 I hope to have some time for this (and a new table-free version of  
 main_template.pt) on Friday. Where exactly is the CMFDefault add  
 menu? Sorry, if the question is stupid but I didn't think we could  
 use zope3 menu directives?
 
 Sorry for using misleading terms. I was referring to  
 'folder_factories'.
 
 
 ah, so clicking on add brings up the tried and trusty page for adding  
 objects to folders? Only then do we get to the appropriate add_view?  
 Would it be a good idea to move this to a menu item like  
 object_actions? Got the code for this.
 
 BTW. regarding formlib I've been bashing my head (checkout those  
 bruises!) for weeks on how to add a thumbnail of an existing image to  
 an edit form. Do I need to develop a special widget which will call  
 the appropriate method?

Perhaps collective.namedfile has a suitable widget.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] [dev] GenericSetup and CMF dependencies

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 21.04.2008 um 08:59 schrieb Wichert Akkerman:
 
 The eggified CMF already required setuptools to make sure the Products
 namespace is setup correctly. Considering that entire python community
 appears to be moving to egg, Zope2 is going to be distributed in egg
 form (at least there is a strong move in that direction) I think a
 dependency on setuptools is not problematic.
 
 
 -1
 
 Lemmings and cliff spring to mind when you mention inevitability. I  
 think there is a significant difference between supporting eggs and  
 requiring them.

I never said 'require eggs'. I said 'requiring setuptools is not
problematic'.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] [dev] GenericSetup and CMF dependencies

[Wichert Akkerman]

Previously yuppie wrote:
 Until recently, the Products themselves didn't use setuptools. Revision 
 85287 (http://svn.zope.org/?rev=85287view=rev) changed that. It is no 
 longer possible to run CMF without setuptools installed.
 
 Was that intended when setuptools was added to install_requires? We 
 always tried hard to keep CMF dependencies to a minimum. Will we only 
 support egg releases for CMF 2.2 and later, making setuptools required 
 anyway?

The eggified CMF already required setuptools to make sure the Products
namespace is setup correctly. Considering that entire python community
appears to be moving to egg, Zope2 is going to be distributed in egg
form (at least there is a strong move in that direction) I think a
dependency on setuptools is not problematic.

From a Plone perspective CMF 2.1 will be the last CMF version we use as
products. Starting with Plone 4 we will be using the eggified version.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] GenericSetup and CMF dependencies

[Wichert Akkerman]

Previously yuppie wrote:
 Wichert Akkerman wrote:
 Previously yuppie wrote:
 Until recently, the Products themselves didn't use setuptools. Revision 
 85287 (http://svn.zope.org/?rev=85287view=rev) changed that. It is no 
 longer possible to run CMF without setuptools installed.
 
 Was that intended when setuptools was added to install_requires? We 
 always tried hard to keep CMF dependencies to a minimum. Will we only 
 support egg releases for CMF 2.2 and later, making setuptools required 
 anyway?
 
 The eggified CMF already required setuptools to make sure the Products
 namespace is setup correctly.
 
 'declare_namespace' is used with a fallback, so setuptools was not 
 strictly required:
 
 try:
 __import__('pkg_resources').declare_namespace(__name__)
 except ImportError:
 from pkgutil import extend_path
 __path__ = extend_path(__path__, __name__)

However without that code the Products.* namespace would probably be
broken and CMF wouldn't work. 

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] GS 1.4 release

[Wichert Akkerman]

Plone 3.1rc1 is scheduled for release this Wednesday. I would like to
include a new GenericSetup release to get r84623 in. Would it be
possible for someone (Jens or Tres I assume) to make a new release?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup 1.4 release

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
  The improvements GenericSetup 1.4/trunk has over the 1.3 series are a
  big part of Plone 3.1. With that moving towards it first alpha release
  this Friday it would be practical if there was a GenericSetup 1.4 beta
  release by then as well. For what it's worth I have been using it in
  several projects recently and it looks solid to me.
 
 +1 to creating a beta (including making a 1.4 branch and a 1.4.0b1 tag).

I'm happy to see there are no objections. Who is going to make that
release? Jens hasn't responded so perhaps someone else will need to do
that. Tres, can you take care of this?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup 1.4 release

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 On Mar 7, 2008, at 09:37 , Wichert Akkerman wrote:
 
 Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
 The improvements GenericSetup 1.4/trunk has over the 1.3 series  
 are a
 big part of Plone 3.1. With that moving towards it first alpha  
 release
 this Friday it would be practical if there was a GenericSetup 1.4  
 beta
 release by then as well. For what it's worth I have been using it in
 several projects recently and it looks solid to me.
 
 +1 to creating a beta (including making a 1.4 branch and a 1.4.0b1  
 tag).
 
 I'm happy to see there are no objections. Who is going to make that
 release? Jens hasn't responded so perhaps someone else will need to do
 that. Tres, can you take care of this?
 
 I haven't had any time this week. I may be able to do it some time  
 today.

Thanks Jens, that would be much appreciated. FYI I've pushed back the
Plone 3.1 release to Sunday noon CET, so I no longer need this release
today; tomorrow will be fine as well.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] What is the status of GS wiping catalog indexes on catalog.xml import?

[Wichert Akkerman]

Previously greenman wrote:
 The bug/feature referenced here 
 https://bugs.launchpad.net/zope-cmf/+bug/161682
 relates to the wiping of indexes in the ZCatalog when a GS step for
 the catalog is run.
 
 I was wondering if there is a targeted release for this fix(feature).
 It has a huge impact on site migrations that require reloading of
 profiles to update configuration states.

As documented in that issue until the catalog index API is changed and
all indexes have been updated to support the new API that bug is
impossible to fix. So far there do not seem to be any volunteers to do
that.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] GenericSetup trunk: failing tests

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I get the follwing failures:
 
 
 Error in test test_createSnapshot_default
 (Products.GenericSetup.tests.test_tool.SetupToolTests)
 Traceback (most recent call last):
   File
 /home/tseaver/projects/Zope-CVS/Zope-2.10-branch/lib/python/Testing/ZopeTestCase/profiler.py,
 line 98, in __call__
 testMethod()
   File
 /home/tseaver/projects/Zope-CVS/pastest/Products/GenericSetup/tests/test_tool.py,
 line 697, in test_createSnapshot_default
 result = tool.createSnapshot( 'default' )
   File
 /home/tseaver/projects/Zope-CVS/pastest/Products/GenericSetup/tool.py,
 line 443, in createSnapshot
 messages[step_id] = handler(context)
   File
 /home/tseaver/projects/Zope-CVS/pastest/Products/GenericSetup/components.py,
 line 257, in exportComponentRegistry
 sm = getSiteManager(context.getSite())
   File
 /home/tseaver/projects/Zope-CVS/Zope-2.10-branch/lib/python/zope/component/_api.py,
 line 48, in getSiteManager
 raise ComponentLookupError(*error.args)
 ComponentLookupError: ('Could not adapt', Folder at /site,
 InterfaceClass zope.component.interfaces.IComponentLookup)
 
 
 and 11 more just like it.  Does anybody have a clue what is wrong?  This
 is with a fresh checkout, in an instance which has no other products
 installed.

Seems to work for me using Zope 2.10.4:

[snow;..l/instances/cmfout]-143 bin/instance test -s Products.GenericSetup
Running tests at level 1
Installing GenericSetup ... done (0.011s)
Running unit tests:
  Running:
.
  Ran 193 tests with 0 failures and 0 errors in 0.979 seconds.
Running Products.GenericSetup.testing.ExportImportZCMLLayer tests:
  Set up Products.GenericSetup.testing.ExportImportZCMLLayer in 0.932 seconds.
  Running:
..
  Ran 186 tests with 0 failures and 0 errors in 1.505 seconds.
Tearing down left over layers:
  Tear down Products.GenericSetup.testing.ExportImportZCMLLayer in 0.001 
seconds.
Total: 379 tests, 0 failures, 0 errors

Did something change in the Zope 2.10 branch?

Wichert.


-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup trunk: failing tests

[Wichert Akkerman]

Previously Tres Seaver wrote:
 This is same set of failurs as in my normal sandbox using the head of
 the 2.10 branch.  What other stuff is installed in the environment where
 your tests were running?

CMF trunk. To be exact I'm using this buildout:
http://svn.plone.org/svn/plone/cmfout/trunk

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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 2.1.1 release

[Wichert Akkerman]

Hi,

Previously Jens Vagelpohl wrote:
 The CMF 2.1 branch has seen enough fixes since CMF 2.1.0 to make a  
 meaningful bugfix release. If there are no objections I would cut CMF  
 2.1.1-beta tomorrow (Friday 12/28) and a final a week later. I'm out  
 of town from tomorrow night until 1/1, that's why I would have to do  
 the beta either tomorrow or after 1/1.

I see 2.1.1 final isn't out yet. Can you do that today or tomorrow? That
and a i18n test failure are the the only blockers for Plone 3.0.5 at the
moment.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup rolemap importer does not register new permissions

[Wichert Akkerman]

Previously Damien Baty (ML) wrote:
   Hello,
 
 Le 27/12/07 9:49, Wichert Akkerman a écrit :
 Previously Damien Baty (ML) wrote:
 [...]
 
 For the record, I have proposed a patch that let us automatically 
 register a permission if the profile explicitly asks for it, with 
 something like:
 
 ...
 permission name=My new permission
   register=True
   role name=Manager/
   ...
 
   https://bugs.launchpad.net/zope-cmf/+bug/178810
 
 -1
 
 I think it's the wrong place to register permissions. Permissions are
 something both code and application configuration (ie zcml) relies
 on. That suggests that registering permissions in a GS profile is too
 late in the game.
 
 To me it makes a lot more sense to register permissions and their 
 default roles in zcml.
 
   Good point. But... how do you do that, then? :) There is a 'grant' 
 directive in Zope 3 defined in 'zope.app.securitypolicy', but this 
 package is not part of Zope 2.10 (nor Zope 2.11). Is there something 
 else I can use in Zope 2 to define permission/roles mappings?

You'll have to make something. I suggest writing a proposal and bringing
it up on the zope-dev list.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup rolemap importer does not register new permissions

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Damien Baty (ML) wrote:
  Hello,
  
  Le 27/12/07 9:49, Wichert Akkerman a écrit :
  Previously Damien Baty (ML) wrote:
  [...]
 
  For the record, I have proposed a patch that let us automatically 
  register a permission if the profile explicitly asks for it, with 
  something like:
 
  ...
  permission name=My new permission
register=True
role name=Manager/
...
 
https://bugs.launchpad.net/zope-cmf/+bug/178810
  -1
 
  I think it's the wrong place to register permissions. Permissions are
  something both code and application configuration (ie zcml) relies
  on. That suggests that registering permissions in a GS profile is too
  late in the game.
 
  To me it makes a lot more sense to register permissions and their 
  default roles in zcml.
  
 Good point. But... how do you do that, then? :) There is a 'grant' 
  directive in Zope 3 defined in 'zope.app.securitypolicy', but this 
  package is not part of Zope 2.10 (nor Zope 2.11). Is there something 
  else I can use in Zope 2 to define permission/roles mappings?
 
 The application is responsible for defining permissions and using them
 to protect objects / methods.  Five enables using the stock
 zope.security stuff to define permissions in ZCML, and to associate them
 with interfaces / attributes.  See:
 
  - $ZOPE_HOME/lib/python/Products/Five/permissions.zcml
 
  - $ZOPE_HOME/lib/python/zope/security/meta.zcml
 
  - $ZOPE_HOME/lib/python/zope/app/security/meta.zcml
 
 GenericSetup is responsible for capturing the placeful mapping of
 permissions to roles (as set on the ZMI security tab).

As far as I know that only maps existing Z2 permissions to Z3
permissions. It does not allow you to register new Z2 permissions.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] GenericSetup: using global steps

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
 Previously yuppie wrote:
  But I agree there should be a way to remove obsolete and broken local 
  steps. A method that removes local duplicates of global steps and a 
  method that removes broken steps would be useful. Not sure if they 
  should be run automatically or if there should be a cleanup button in 
  the UI.
 
 I would prefer manually: otherwise we risk breaking things if someone
 tries a newer version of a product and then downgrades and suddenly
 looses the step registrations. I will see if I can make a ZMI page for
 that over the next week.

I just commited that to trunk.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup rolemap importer does not register new permissions

[Wichert Akkerman]

Previously Damien Baty (ML) wrote:
   Hello,
 
 Le 10/12/07 14:11, Laurence Rowe a écrit :
 Damien Baty (ML) wrote:
 Hello,
 
 I am trying to use GenericSetup to define permissions/roles
 mappings for a product. As far as I can see, the current version of
  GenericSetup does not register the permission if it does not
 exist. It supposes that the permission exists and calls
 'manage_permission()'. Naturally, it breaks with new (unregistered)
 permissions.
 [...]
 
 Can you not simply define the permission itself in zcml:
 
   permission
 id=my.package.SomePermission
 title=My Package: Some permission
 /
 
 I _think_ that should then let you then import a rolemap for it.
 
   As Wichert noted, this does not work.
 
 (IMO it's a good thing that importing a rolemap for an unregistered 
 raises an error - imagine chasing an error because you have put 'List
 Folder Contents' instead of 'List folder contents' in your
 rolemap.xml)
 
   Good point. I can imagine that very well, indeed. :)
 
   For the record, I have proposed a patch that let us automatically 
 register a permission if the profile explicitly asks for it, with 
 something like:
 
 ...
 permission name=My new permission
   register=True
   role name=Manager/
   ...
 
   https://bugs.launchpad.net/zope-cmf/+bug/178810

-1

I think it's the wrong place to register permissions. Permissions are
something both code and application configuration (ie zcml) relies on.
That suggests that registering permissions in a GS profile is too late
in the game.

To me it makes a lot more sense to register permissions and their
default roles in zcml.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] GenericSetup: using global steps

[Wichert Akkerman]

Previously yuppie wrote:
 Hi!
 
 
 Wichert Akkerman wrote:
 Previously yuppie wrote:
 GenericSetup trunk has global step registries. I propose to use the new 
 ZCML directive for registering all GenericSetup and CMF import and 
 export steps globally. And to remove the import_steps.xml and 
 export_steps.xml files from the profiles shipped with CMF.
 
 This also requires to add a flag file for the 'various' step.
 
 I already started implementing this. If there are no objections, I'll 
 soon check in my changes.
 
 +1
 
 there is one thing missing at the moment: unregistering the old
 profile-registered steps. I'm not sure what the right way to do that is.
 
 listExportSteps() and getSortedImportSteps() now have unit tests and no 
 longer return duplicates. AFAICS we now have a clean override behavior 
 and nothing breaks if the same step is registered locally *and* globally.

Great, thanks for doing that.

 But I agree there should be a way to remove obsolete and broken local 
 steps. A method that removes local duplicates of global steps and a 
 method that removes broken steps would be useful. Not sure if they 
 should be run automatically or if there should be a cleanup button in 
 the UI.

I would prefer manually: otherwise we risk breaking things if someone
tries a newer version of a product and then downgrades and suddenly
looses the step registrations. I will see if I can make a ZMI page for
that over the next week.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] [dev] GenericSetup: using global steps

[Wichert Akkerman]

Previously yuppie wrote:
 GenericSetup trunk has global step registries. I propose to use the new 
 ZCML directive for registering all GenericSetup and CMF import and 
 export steps globally. And to remove the import_steps.xml and 
 export_steps.xml files from the profiles shipped with CMF.
 
 This also requires to add a flag file for the 'various' step.
 
 I already started implementing this. If there are no objections, I'll 
 soon check in my changes.

+1

there is one thing missing at the moment: unregistering the old
profile-registered steps. I'm not sure what the right way to do that is.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Why does GenericSetup remove indexes before adding them again?

[Wichert Akkerman]

Previously Damien Baty (ML) wrote:
   Hello,
 
   If I define a catalog index with GenericSetup, GS kindly removes the 
 index of the same name if it exists, and then add it again. This is 
 probably a good intention. However, when I reinstall a product (in this 
 case, a Plone product), removing and adding back the index causes the 
 indexed values to be lost. If the index definition has not changed, 
 there is no real need to remove it and add it back.
 
   I wonder what is the reason why GS remove all indexes, instead of 
 comparing existing indexes with the ones listed in the import step, and 
 adding new ones and removing and adding back only those that have changed.

See https://bugs.launchpad.net/zope-cmf/+bug/161682

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup rolemap importer does not register new permissions

[Wichert Akkerman]

Previously Laurence Rowe wrote:
 Damien Baty (ML) wrote:
 Hello,
 
   I am trying to use GenericSetup to define permissions/roles mappings 
 for a product. As far as I can see, the current version of GenericSetup 
 does not register the permission if it does not exist. It supposes that 
 the permission exists and calls 'manage_permission()'. Naturally, it 
 breaks with new (unregistered) permissions.
 
   All I need to do is to register this new permission, e.g. with 
 'CMFCore.permissions.setDefaultRoles()'. Is there any reason why this is 
 not done by the 'rolemap' importer? If not, I would be willing to 
 propose a patch.
 
   (I am not totally sure that this is the right place to ask about 
 GenericSetup. If it is not, feel free to redirect me to the proper 
 mailing-list.)
 
 Regards,
 
 
 Can you not simply define the permission itself in zcml:
 
   permission
 id=my.package.SomePermission
 title=My Package: Some permission
 /
 
 I _think_ that should then let you then import a rolemap for it.

That only creates a bridge between Z2 and Z3 permissions.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] [dev] GenericSetup: profile version and metadata.xml

[Wichert Akkerman]

Previously yuppie wrote:
 Hi!
 
 
 Running the trunk unit tests triggers warnings like this one:
 UserWarning: Version for profile Products.GenericSetup:default taken 
 from version.txt. This is deprecated behaviour: please specify the 
 version in metadata.xml.
 
 I like the fact that using version.txt for the profile version is 
 deprecated. But you now get always a deprecation warning if no 
 metadata.xml exists in the profile. Is that intended? Is specifying a 
 version now required?

It isn't required - it is fine if a profile has no version. What I did
is add a deprecation warning when the profile metadata did not specify
a version and the version was read from a version.txt file. If you have
no version.txt you will not see the deprecation warning.

I agree the deprecation warnings are annoying in the tests, but I could
not come up with a proper alternative.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup dependency support

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
  I did some work on a wichert-dependencies branch for GenericSetup today.
  It works quite simple: runAllImportStepsFromProfile will now look for
  required contexts in the profile metadata. Any found dependencies will
  be imported before the current code is imported. There is a new option
  ignore_dependencies which can be used to disable this behaviour.
  
  I would appreciate some more eyes on these changes before merging this.
 
 The changes look good to me, although I'm not sure I understand the use
 case.

Mostly it solves a maintenance problem: it is quite common for a product
to require one or more other products. You can merge the necessary
GS profile for those into your product but that means you have to
duplicate and maintain that information in multiple places, and likely
across multiple developers as well. 

I made a branch of CMFQuickInstaller which makes this particularly nice:
it listens to the new events fired by GenericSetup to mark products as
installed when their profile is fully loaded. Combining these two allows
users to install a product and automatically have all its dependencies
installed in the site as well.

Wichert.


-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: GenericSetup dependency support

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Wichert Akkerman wrote:
  I did some work on a wichert-dependencies branch for GenericSetup today.
  It works quite simple: runAllImportStepsFromProfile will now look for
  required contexts in the profile metadata. Any found dependencies will
  be imported before the current code is imported. There is a new option
  ignore_dependencies which can be used to disable this behaviour.
  
  I would appreciate some more eyes on these changes before merging this.
 
 The changes look good to me, although I'm not sure I understand the use
 case.
 
 BTW, why does Plone 3 still not display alternate BASE profiles
 registered for IPloneSite:  it shows EXTENSION profiles just fine.

Channeling Hanno:

  it should. That's a bug.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] eggification status?

[Wichert Akkerman]

A related question is: how do we want to eggify CMF? It seems to make
sense to create one egg for the whole of CMF and a second egg for
GenericSetup. At the moment CMFCore is its own egg though.

Wichert.

Previously yuppie wrote:
 Hi!
 
 
 Right now there are two versions of CMFCore and GenericSetup:
 
 Products.GenericSetup and GenericSetup
 Products.CMFCore and CMFCore
 
 wichert is currently working on GenericSetup/trunk, tseaver stitched 
 today the 6 weeks old Products.GenericSetup/trunk/Products/GenericSetup 
 into CMF/trunk/ and 
 Products.GenericSetup/tags/1.3.2/Products/GenericSetup into 
 CMF/branches/2.1/
 
 Products.CMFCore seems not to be used - changes still go into CMF/*/CMFCore
 
 Can we please have *one* location for each product?
 
 
 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

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] [dev] GenericSetup: import step version

[Wichert Akkerman]

Previously yuppie wrote:
 Hi!
 
 
 Can we please deprecate the 'version' argument of registerStep?
 
 This is the interface description:
 
 quote
 o 'version' is a string for comparing versions, it is preferred to
   be a /mm/dd-ii formatted string (date plus two-digit
   ordinal).  when comparing two version strings, the version with
   the lower sort order is considered the older version.
 
   - Newer versions of a step supplant older ones.
 
   - Attempting to register an older one after a newer one results
 in a KeyError.
 /quote
 
 AFAICT this feature was never used, became inoperable after adding 
 extension profiles and makes absolutely no sense in a global step 
 registry. Originally steps were linked to specific files in the profile, 
 the 'version' described the version of the XML files.
 
 A profile version can now be set in metadata.xml. AFAICS this supersedes 
 the import step version approach.

+1

I want to suggest also deprecating the metadata logic that uses
version.txt profile version number if there is no metadata.xml which
defines one.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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: eggification status?

[Wichert Akkerman]

Previously Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 yuppie wrote:
  Hi!
  
  
  Right now there are two versions of CMFCore and GenericSetup:
  
  Products.GenericSetup and GenericSetup
  Products.CMFCore and CMFCore
  
  wichert is currently working on GenericSetup/trunk, tseaver stitched 
  today the 6 weeks old Products.GenericSetup/trunk/Products/GenericSetup 
  into CMF/trunk/ and 
  Products.GenericSetup/tags/1.3.2/Products/GenericSetup into 
  CMF/branches/2.1/
  
  Products.CMFCore seems not to be used - changes still go into CMF/*/CMFCore
  
  Can we please have *one* location for each product?
 
 Ouch, sorry about that.  I forgot I hadn't merged the change to use
 'Products.GenericSetup' already.  I'd rather that we moved to use
 'Products.GenericSetup' and 'Products.CMFCore' everywhere, and leave the
 older stuff just pulling in from externals.

+1, especially if you can merge the changes from GS trunk into
Products.GenericSetup and put a clear warning in the old location.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] First steps with tools

[Wichert Akkerman]

Previously Charlie Clark wrote:
 thanks again to everyone who helped me yesterday. I feel understand  
 things a lot better now. However, there are still a lot of things I  
 need to learn.

There are a million example out there you can use. I suggest that you
take a look at how those work. The plone collective may be especially
helpful. Don't be scared of by the fact that that is a Plone repository:
all the general concepts apply just as well to pure CMF.

If you want to see an example of a subscription/newsletter type of
product (which appears to be your use case) using only Z3 concepts look
at collective.revelation for example. 

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] ZCML import/export step registration

[Wichert Akkerman]

I completed implementation of zcml-based import and export step
registration on the wichert-zcml-steps branch. The syntax for import
steps is this:

 genericsetup:importStep
 name=name
 title=title
 description=description
 handler=Products.GenericSetup.tests.test_zcml.dummy_importstep_handler
 version=version
depends name=something.else/
  /genericsetup:importStep

and for export steps:
 
 genericsetup:exportStep
 name=name
 title=title
 description=description
 handler=Products.GenericSetup.tests.test_zcml.dummy_exportstep_handler
 /
 
steps registered using zcml are stored in a new registry. I added some
utility methods to the setup tool that look in both this registry and
the in-tool registry so all the standard machinery and ZMI interfaces
see all steps.

Exporting only exports steps from the in-tool registries.

There are several advantages to managing steps in this method:

- if a product is removed its steps no longer stick in the system, which
  could lead to errors (it was breaking sites badly until we changed GS
  to ignore steps with invalid handlers) and adds a lot of unremoveable
  entries in its ZMI pages.

- even though steps are only loaded into the registry when a profile was
  selected the way we have managed the step registration in the user
  interface and API so far this has always been a silent and trivial to
  trigger action. This lead to confusing behaviour: steps would appear
  to be registered randomly depending on which profiles a user happened
  to have accessed. With zcml registration the behaviour is simple and
  predictable: if you install a product and load its zcml its
  functionality becomes available. Since import steps have always needed
  to check for presence of XML or marker files this is harmless.
  Exporting should always be a safe operation.

- If we deprecate profile-based registration and eventually remove it
  we can simplify a lot of code.

I intend to merge this branch into trunk next week.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Accessing the context

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 30.10.2007 um 16:19 schrieb robert rottermann:
 
 
 da = getattr('my_da_or_what_ever', context, None)

getattr(context, 'my_da_or_what_ever', None) works a bit better.

 Doesn't that only work within a PythonScript? I need access from  
 within a content type, ie. real Python code?

It's called acquisition and it works everywhere. Try it.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Accessing the context

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 30.10.2007 um 17:04 schrieb Andrew Sawyers:
 
 If it's in a content type's class, why not:
 id = getattr(self, 'da_id', None)
 Just using self as the context should be fine.
 -- that of course presumes that the type is wrapped properly when  
 you call that within your method.
 
 mm, currently getting None back so I guess I'm not wrapping things  
 properly.
 
 This is a skeleton bit of code:
 
 class ContentType(PortalContent):
 A content type with access to an external database
 
 def __init__(self, id):
   self.id = id
 DA = getattr(self, 'MyDA', None)
   #self.conn = DA() # not working at the moment because DA is None
 
 Is it wrong to try and do this in my __init__ ? Regarding your other  
 suggestion: yes, I probably will factor this out into a utility once  
 I've worked out how to access the DA!!!

__init__ is indeed the wrong place: when the instance is created it is
not placed in an acquisition context yet.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Accessing the context

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 30.10.2007 um 17:40 schrieb Wichert Akkerman:
 
 __init__ is indeed the wrong place: when the instance is created it is
 not placed in an acquisition context yet.
 
 That would indeed explain things!!! Is it okay to call a method which  
 does this from __init__ ?

No, since the acquisition context is only created when the object is
insert into the hierarchy somewhere (sloppy terminology here, I know).
And that can only happen after the instance has been fully created.

As an example:

   obj = Object()
   # obj has no acquisition context
   folder.obj = obj
   # folder.obj will have an acquisition context

In other words: in __init__ and everything you call from __init__ the
instance will not have an aq context. The context does not magically
appear.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Move CMF collector to Launchpad (redux)

[Wichert Akkerman]

Previously Charlie Clark wrote:
 Am 27.10.2007 um 00:02 schrieb Charlie Clark:
 In conclusion: I'm still abstaining because, although the arguments  
 for the automated migration are strong, we are under no time  
 pressure and might like to see some features added before any  
 migration.
 
 It seems that the Launchpad database is not separated by product. I  
 was just checking the bugs fixed in the latest relase of Zope and  
 #2339 refers to something completely different related to Ubuntu. I  
 would have expected bugs from unrelated projects to kept separate.

The fact that they are not is useful: it allows you to move a bugreport
from one product to another.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Move CMF collector to Launchpad (redux)

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 On 25 Oct 2007, at 12:40, Wichert Akkerman wrote:
 I remember one of the popular objections was that the launchpad mails
 did not contain as much context as the current collector emails. Has
 that changed?
 
 I've been going back and forth with Steve about that yesterday.  
 Apparently it's *not* available right now, and they don't want a  
 naive implementation that sends out the whole history, like the  
 current collector does, because many of their instances have bug  
 histories a lot longer than those we are used to. Right now the  
 discussion is stalled at my suggestion to make the full-context email  
 a configurable item.

I agree that sending the full history is not very useful and can be very
painful. The minimum context I would like to have is the description of
the bugreport. If that's included I'm +1 on moving.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Move CMF collector to Launchpad (redux)

[Wichert Akkerman]

Previously Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi guys,
 
 Now that the Zope and Zope3 collectors have been migrated  
 successfully onto Launchpad, and there seems to be a good routine in  
 place to preserve history and ensure automatic redirects, I wanted to  
 bring up the question again. Should we move the CMF collector to  
 Launchpad?
 
 I personally had one remaining issue, namely the fact that my main  
 browser (OmniWeb) could not display Launchpad at all due to a CSS bug  
 in OW itself. All that has been fixed, and the Launchpad team has  
 been very cooperative and responsive. So my own vote at this point is  
 +1:
 
  - one less thing to maintain ourselves
 
  - apparently there's a new zope.org push, and not having to deal  
 with collectors will make life easier for the people involved
 
  - it will be easier to create relationships between Zope and CMF  
 bug reports (I am making an assumption here, haven't tried it)
 
 Can we have a show of hands, so to speak?

I remember one of the popular objections was that the launchpad mails
did not contain as much context as the current collector emails. Has
that changed?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Controlling permissions for actions

[Wichert Akkerman]

Previously Charlie Clark wrote:
 
 Am 27.09.2007 um 12:40 schrieb Jens Vagelpohl:
 
 If you have a script somewhere in the skins or in your site it will  
 *always* be available for people who call it up directly by URL.  
 There is no builtin mechanism in Zope or the CMF to control that.  
 You could do some manual checking inside the script to make sure  
 the calling user has the right permissions or the script is not  
 called by direct URL traversal.
 
 Thanks, I thought as much. It's not difficult to check the user for  
 the correct role and return an index page otherwise but I guess I  
 need to start explicitly attaching such scripts to objects and their  
 methods but I'm still on that learning curve, which is probably not  
 helped by the fact I nearly always store data in an RDBMS and I don't  
 use O/R mappers.

You can use a browser view instead of a python script and protect that
with a permission.

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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