Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi Charlie!
Charlie Clark wrote:
Am 02.12.2009, 20:51 Uhr, schrieb yuppie y.2...@wcm-solutions.de:
-1
The real issue here is the fact that the permission argument of the
adapter directive is not supported in Zope 2. Otherwise we could simply
use this:
adapter
name=myproduct.content_type_factory
factory=.myproduct.MyAddView
permission=cmf.AddPortalContent
/
Using the class directive instead is just a workaround for a generic
problem that needs a generic solution, not a new addView directive.
I have to agree with you on that. But the current solution remains clunky.
Having initially been against it I think it would be easier on the eye to
have the security declaration (I'm assuming this would work for subclasses
where it can be overwritten if needs be) in ContentAddFormBase until the
permissions directive is supported. It was only from working with the new
add form that I realised how little needs to be done to work with this.
+1
Actually it would make sense to get the permission checks in sync with
the _checkAllowed method used by add actions. And _checkAllowed has a
hardcoded check for AddPortalContent.
So it is indeed superfluous to configure the AddPortalContent permission
for each add view in ZCML. And the __call__ method of ContentAddFormBase
seems to be a good place for checking the AddPortalContent permission
*and* the isConstructionAllowed method.
I currently use method aliases defined for the container to customize
the names shown in the URL. But that's not perfect because you can't
define the aliases together with the portal type and you have to define
them for each container type used.
I'm not sure I understand what you mean by that - you have a situation
where string:${folder_url}/++add++${object_id} needs changing?
Here is an example:
object name=Document
property name=add_view_exprstring:${folder_url}/newDoc/property
/object
object name=Folder
alias from=newDoc to=++add++Document/
/object
If you have a better idea, please let me know.
I think that we could work with a sensible default which might be
overwritable in the aliases?
The problem is: The indirection has to be done on container level, but
it would be clearer to set the alias in the type info of the new object.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://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.2.0-beta reminder
Am 02.12.2009, 20:51 Uhr, schrieb yuppie y.2...@wcm-solutions.de:
-1
The real issue here is the fact that the permission argument of the
adapter directive is not supported in Zope 2. Otherwise we could simply
use this:
adapter
name=myproduct.content_type_factory
factory=.myproduct.MyAddView
permission=cmf.AddPortalContent
/
Using the class directive instead is just a workaround for a generic
problem that needs a generic solution, not a new addView directive.
I have to agree with you on that. But the current solution remains clunky.
Having initially been against it I think it would be easier on the eye to
have the security declaration (I'm assuming this would work for subclasses
where it can be overwritten if needs be) in ContentAddFormBase until the
permissions directive is supported. It was only from working with the new
add form that I realised how little needs to be done to work with this.
I'm also not sure if the add view URL couldn't be simpler because the
++add++ContentTypeId is a must, why this can't be interpolated either on
type registration or in the add_action look-up. Is there any reason why
this couldn't or shouldn't be the case?
We need a prefix to make sure there are no conflicts with existing names
and we need something in the name that specifies the portal type. The ++
around the prefix indicates that it is implemented as traverser.
I understand that.
I currently use method aliases defined for the container to customize
the names shown in the URL. But that's not perfect because you can't
define the aliases together with the portal type and you have to define
them for each container type used.
I'm not sure I understand what you mean by that - you have a situation
where string:${folder_url}/++add++${object_id} needs changing?
If you have a better idea, please let me know.
I think that we could work with a sensible default which might be
overwritable in the aliases?
Having finally taken the plunge into buildout I've been able to upgrade
one of our projects onto Zope 2.12 and CMF 2.2 with no real problems
just
the odd surprise. Thank you all very much for your help with Zope +
CMF!
Thanks for testing and feedback!
You are very welcome.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
