Mailing List Archive: Zope: CMF

CMF 2.2.0-beta reminder

Index | Next | Previous | View Threaded

jens at dataflake

Nov 30, 2009, 10:52 PM

Post #1 of 14 (1367 views)
Permalink

CMF 2.2.0-beta reminder

Reminder: After this week (probably this coming Sunday) I plan on doing the first CMF 2.2 beta, and creating the 2.2 release branch.

jens

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

charlie at begeistert

Dec 2, 2009, 6:31 AM

Post #2 of 14 (1316 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Am 01.12.2009, 07:52 Uhr, schrieb Jens Vagelpohl <jens [at] dataflake>:

> Reminder: After this week (probably this coming Sunday) I plan on doing
> the first CMF 2.2 beta, and creating the 2.2 release branch.

My CSS stuff won't make it into the beta. I would like to contribute some
documentation on Yuppie's new add views but also continue the discussion.

As things currently stand Yuppie has implemented some very flexible add
views that are almost entirely type definition-based. If a type definition
has something in the new add view URL field then it will automatically be
picked up for folder actions:

atool = getToolByName(self.context, 'portal_actions')
actions = atool.listFilteredActionsFor(self.context)
return actions.get("folder/add", {})

A really nice thing is support for schemaless, default add views that only
require this URL of the form

string:${folder_url}/++add++Document

This will get you a form with just a single field for the id.

Dedicated schema-based add views are trivial to add:

from zope.formlib import form
from Products.CMFDefault.formlib.form import ContentAddFormBase
from MyApp.interfaces import IMyContentType

class MyAddView(ContentAddFormBase):
form_fields = form.FormFields(IMyContentType)

May be all you need.

Otherwise there are examples for CMF Link and CMF Favourite.

We have a use case where we need the object creation without any kind of
fields (id's are automatically assigned) and this is easy to implement

def __call__(self):
self.createAndAdd({})

You need to remember to return a new view or a redirect from the call
which in this case is likely to be something other than an object's inital
view. For example, returning
self.request.response.redirect(self.request.HTTP_REFERER) lets you create
lots of objects in a folder one after the other.

Hooking everything together is, however, a bit clunky:

<adapter
name="myproduct.content_type_factory"
factory=".myproduct.MyAddView"
/>

<class class=".myproduct.MyAddView">
<require
permission="cmf.AddPortalContent"
interface="zope.formlib.interfaces.IPageForm"
/>
</class>

For the sake of clarity it would be nice to have a directive that ties
this together. Particularly the juxtaposition of the adapter name (which
has to be the same as the named content type factory utility) and the view
acting as a factory is a definite possible source of confusion. And, while
I much prefer the security declaration outside of the view class, the
combination is a bit unintuitive.

I would find something like:

<cmf:addView
factory="myproduct.content_type_factory"
class=".myproduct.MyAddView"
permission="cmf.AddPortalContent"
required-inteface="zope.formlib.interfaces.IPageForm"
/>

easier to work with.

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?

***

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!

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2009 at wcm-solutions

Dec 2, 2009, 11:51 AM

Post #3 of 14 (1322 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Hi Charlie!

Charlie Clark wrote:
> Hooking everything together is, however, a bit clunky:
>
> <adapter
> name="myproduct.content_type_factory"
> factory=".myproduct.MyAddView"
> />
>
> <class class=".myproduct.MyAddView">
> <require
> permission="cmf.AddPortalContent"
> interface="zope.formlib.interfaces.IPageForm"
> />
> </class>
>
> For the sake of clarity it would be nice to have a directive that ties
> this together. Particularly the juxtaposition of the adapter name (which
> has to be the same as the named content type factory utility) and the view
> acting as a factory is a definite possible source of confusion. And, while
> I much prefer the security declaration outside of the view class, the
> combination is a bit unintuitive.
>
> I would find something like:
>
> <cmf:addView
> factory="myproduct.content_type_factory"
> class=".myproduct.MyAddView"
> permission="cmf.AddPortalContent"
> required-inteface="zope.formlib.interfaces.IPageForm"
> />
>
> easier to work with.

-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'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 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.

If you have a better idea, please let me know.

> 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!

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

charlie at begeistert

Dec 2, 2009, 12:04 PM

Post #4 of 14 (1326 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Am 02.12.2009, 20:51 Uhr, schrieb yuppie <y.2009 [at] wcm-solutions>:

> -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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2009 at wcm-solutions

Dec 3, 2009, 3:14 AM

Post #5 of 14 (1308 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Hi Charlie!

Charlie Clark wrote:
> Am 02.12.2009, 20:51 Uhr, schrieb yuppie <y.2009 [at] wcm-solutions>:
>
>> -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_expr">string:${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 [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2009 at wcm-solutions

Dec 4, 2009, 2:16 AM

Post #6 of 14 (1311 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Hi Charlie!

yuppie wrote:
> Charlie Clark wrote:
>> Am 02.12.2009, 20:51 Uhr, schrieb yuppie <y.2009-E2EsyBC0hj3+aS/vkh9bjw [at] public>:
>>> 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.

This change is now checked in: http://svn.zope.org/?rev=106203&view=rev

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

jens at dataflake

Dec 6, 2009, 9:39 AM

Post #7 of 14 (1308 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

On Dec 1, 2009, at 07:52 , Jens Vagelpohl wrote:

> Reminder: After this week (probably this coming Sunday) I plan on doing the first CMF 2.2 beta, and creating the 2.2 release branch.

All done now:

- release branches for the 2.2 release series are cut

- the 2.2.0 beta release is tagged and published on PyPI

- the convenience buildout branch[1] now uses the new CMF 2.2 branch

The trunk (-> CMF 2.3) is free for new features.

Please test the beta and provide feedback through Launchpad[2] or here. I would suggest a final release, provided there are no serious issues, about a month from now.

jens

[1] http://svn.zope.org/CMF.buildout/branches/zope212-cmf22/
[2] https://bugs.launchpad.net/zope-cmf/+bugs

Attachments:

smime.p7s (4.70 KB)

charlie at begeistert

Dec 9, 2009, 5:55 AM

Post #8 of 14 (1304 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Am 06.12.2009, 18:39 Uhr, schrieb Jens Vagelpohl <jens [at] dataflake>:

> All done now:
> - release branches for the 2.2 release series are cut
> - the 2.2.0 beta release is tagged and published on PyPI
> - the convenience buildout branch[1] now uses the new CMF 2.2 branch
> The trunk (-> CMF 2.3) is free for new features.
> Please test the beta and provide feedback through Launchpad[2] or here.
> I would suggest a final release, provided there are no serious issues,
> about a month from now.

Hi Jens,

thanks for this. Is there an easy to way to setup a project buildout based
on CMF? I've tried various combinations of the following:

[buildout]
extends =
http://svn.zope.org/*checkout*/CMF.buildout/branches/zope212-cmf22/buildout.cfg
versions = versions
parts = parts
eggs = eggs

But there must be something in the URL that causes buildout to choke on an
IOError. Other URLs work fine so maybe it's just the
extends = src/Zope2/versions.cfg

For convenience for installing on Windows I'm looking for a way of adding
the PIL and PyWin32 download to the buildout manifest. I can't find a
directive for the download utility. I've tried the Hexaglot recipe but it
mangles the PyWin32 downloard URL to download as this is the last part of
URL. Going on Hanno's instructions for Plone 3.1 it seems there isn't a
convenience function for this yet.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

jens at dataflake

Dec 9, 2009, 6:10 AM

Post #9 of 14 (1306 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Hi Charlie,

> Is there an easy to way to setup a project buildout based
> on CMF? I've tried various combinations of the following:
>
> [buildout]
> extends =
> http://svn.zope.org/*checkout*/CMF.buildout/branches/zope212-cmf22/buildout.cfg
> versions = versions
> parts = parts
> eggs = eggs
>
> But there must be something in the URL that causes buildout to choke on an
> IOError. Other URLs work fine so maybe it's just the
> extends = src/Zope2/versions.cfg

For the "extends = src/Zope2/versions.cfg" line to work you must have a Zope 2 checkout in src/Zope2 *before* you attempt run the buildout. CMF.buildout does this using svn:externals, so you may not have those in your own buildout.

I would never extend those convenience buildouts for my own projects, there is no maintenance or correctness guarantee on them. They are just a developer convenience, not a blueprint for a production buildout. I would either just use it as inspiration for a buildout configuration done from scratch, or copy it and then adjust as necessary.

By the way, don't use URLs that use the ViewVC "checkout" magic. That's an unnecessary detour when you can use straight HTTP repository access. The URL above would translate to this direct URL:

http://svn.zope.org/repos/main/CMF.buildout/branches/zope212-cmf22/buildout.cfg

jens

Attachments:

smime.p7s (4.70 KB)

charlie at begeistert

Dec 9, 2009, 6:38 AM

Post #10 of 14 (1304 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Am 09.12.2009, 15:10 Uhr, schrieb Jens Vagelpohl <jens [at] dataflake>:

> For the "extends = src/Zope2/versions.cfg" line to work you must have a
> Zope 2 checkout in src/Zope2 *before* you attempt run the buildout.
> CMF.buildout does this using svn:externals, so you may not have those in
> your own buildout.

No, I was just trying a "CMF-based" project buildout and hoping to be able
to do without having Zope2 in src/

> I would never extend those convenience buildouts for my own projects,
> there is no maintenance or correctness guarantee on them. They are just
> a developer convenience, not a blueprint for a production buildout. I
> would either just use it as inspiration for a buildout configuration
> done from scratch, or copy it and then adjust as necessary.

Fair enough. I was just seeing how little I could get away with ;-) And
thinking ahead to a possible release. OTOH listing the eggs manually isn't
really a problem.

> By the way, don't use URLs that use the ViewVC "checkout" magic. That's
> an unnecessary detour when you can use straight HTTP repository access.
> The URL above would translate to this direct URL:
> http://svn.zope.org/repos/main/CMF.buildout/branches/zope212-cmf22/buildout.cfg

I'd initially tried that but got confused by the errors I was getting.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

charlie at begeistert

Dec 9, 2009, 7:32 AM

Post #11 of 14 (1302 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Am 02.12.2009, 21:04 Uhr, schrieb Charlie Clark <charlie [at] begeistert>:

> I think that we could work with a sensible default which might be
> overwritable in the aliases?

I can think of two solutions here.

1) Sensible default:

replace

if self.add_view_expr:
lazy_map['url'] = self.add_view_expr_object
lazy_keys.append('url')
else:
lazy_map['url'] = ''

with

if not self.add_view_expr:
url = "string:${folder_url}/++add++%s" % self.getId()
self._setPropValue('add_view_expr', url)
lazy_map['url'] = self.add_view_expr_object
lazy_keys.append('url')

This leaves add_view_expr as an editable property but will create it if
required and it can be edited afterwards. This means you don't need to
worry about typos when creating or copying new portal types, you just have
to make it an empty string.

2) Uneditable TypeInfo method

Apart from transparency I can't see any reason for making this value
editable so it could be implemented as a property doing much the same as
above.

Thoughts?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2009 at wcm-solutions

Dec 9, 2009, 10:22 AM

Post #12 of 14 (1300 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Hi!

Charlie Clark wrote:
> Am 02.12.2009, 21:04 Uhr, schrieb Charlie Clark <charlie [at] begeistert>:
>
>> I think that we could work with a sensible default which might be
>> overwritable in the aliases?
>
> I can think of two solutions here.
>
> 1) Sensible default:
>
> replace
>
> if self.add_view_expr:
> lazy_map['url'] = self.add_view_expr_object
> lazy_keys.append('url')
> else:
> lazy_map['url'] = ''
>
> with
>
> if not self.add_view_expr:
> url = "string:${folder_url}/++add++%s" % self.getId()
> self._setPropValue('add_view_expr', url)
> lazy_map['url'] = self.add_view_expr_object
> lazy_keys.append('url')
>
> This leaves add_view_expr as an editable property but will create it if
> required and it can be edited afterwards. This means you don't need to
> worry about typos when creating or copying new portal types, you just have
> to make it an empty string.

-1

I don't think a write-on-read solution is acceptable.

> 2) Uneditable TypeInfo method
>
> Apart from transparency I can't see any reason for making this value
> editable so it could be implemented as a property doing much the same as
> above.

-1

For several reasons I think this should be an expression:

- At the moment you can specify any kind of add view name and
implementation. E.g. you can use a skin method or set an alias.

- The traverser is configured in ZCML and its name can easily be
changed. I don't think it is a good idea to hardcode assumptions about
configuration in the type info code.

- Type infos are now also Action objects and should be configured in a
similar way as normal Actions.

> Thoughts?

I'm afraid any attempt to make this simpler also makes it less explicit
and less flexible.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

charlie at begeistert

Dec 12, 2009, 6:12 AM

Post #13 of 14 (1276 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Am 09.12.2009, 19:22 Uhr, schrieb yuppie <y.2009 [at] wcm-solutions>:

Hiya yuppie,

> -1
> I don't think a write-on-read solution is acceptable.

Okay. How about on creation?

>> 2) Uneditable TypeInfo method
>>
>> Apart from transparency I can't see any reason for making this value
>> editable so it could be implemented as a property doing much the same as
>> above.
> -1

> For several reasons I think this should be an expression:
> - At the moment you can specify any kind of add view name and
> implementation. E.g. you can use a skin method or set an alias.

> - The traverser is configured in ZCML and its name can easily be
> changed. I don't think it is a good idea to hardcode assumptions about
> configuration in the type info code.

> - Type infos are now also Action objects and should be configured in a
> similar way as normal Actions.

>> Thoughts?
> I'm afraid any attempt to make this simpler also makes it less explicit
> and less flexible.

I'm a big fan of "explicit is better than implicit" but only part of the
expression is flexible. The traverser and TypeInfo id are not but they are
also not interpolable when the expression is evaluated which goes against
the spirit of expressions, I think.

BTW. how do addViews cross the CMFCore CMFDefault divide? Shouldn't the
traverser be part of CMFDefault?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2009 at wcm-solutions

Dec 14, 2009, 3:55 AM

Post #14 of 14 (1276 views)
Permalink

Re: CMF 2.2.0-beta reminder [In reply to]

Hi!

Charlie Clark wrote:
> Am 09.12.2009, 19:22 Uhr, schrieb yuppie <y.2009 [at] wcm-solutions>:
>> -1
>> I don't think a write-on-read solution is acceptable.
>
> Okay. How about on creation?

There are different ways to create type infos. I don't think the class
constructor should contain any magic that sets computed defaults.

But I would be fine with some kind of wizard in the ZMI that helps to
create icon and add view URL expressions based on the type info id.

>> I'm afraid any attempt to make this simpler also makes it less explicit
>> and less flexible.
>
> I'm a big fan of "explicit is better than implicit" but only part of the
> expression is flexible. The traverser and TypeInfo id are not but they are
> also not interpolable when the expression is evaluated which goes against
> the spirit of expressions, I think.

The only part that is not flexible - at least in the use cases I'm aware
of - is the 'string:${folder_url}/' prefix. The traverser and TypeInfo
id can replaced by something different.

'string:${folder_url}/addDoc.html' works perfectly if you make sure
'addDoc.html' returns an add view for 'Document'.

The main reason to use expressions is to interpolate names that can only
be resolved on runtime, e.g. folder_url.

> BTW. how do addViews cross the CMFCore CMFDefault divide? Shouldn't the
> traverser be part of CMFDefault?

Type infos are part of CMFCore, so the general concept of add views is
part of CMFCore as well.

Skins and views are part of CMFDefault.

The traverser belongs somewhere in between. I can't see why it would be
better to have it in CMFDefault. If you really think it belongs into
CMFDefault: Why do you think CMFCore's type infos should create add view
URLs that are especially made for that specific traverser?

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads