Mailing List Archive: Zope: CMF

CMF add views and <browser:page />

Index | Next | Previous | View Threaded

optilude at gmx

Dec 8, 2008, 7:00 AM

Post #1 of 14 (1019 views)
Permalink

CMF add views and <browser:page />

Hi,

Thanks to yuppie, trunk now allows us to use the ++add++<type>
traverser, which will look up an add view as an adapter on (context,
request, fti) with name equal to fti.factory.

This is good, but it does mean that those add views cannot be registered
with a <browser:page /> directive. Unfortunately, Five's browser:page
does quite a lot of stuff, from allowing a template to be specified, to
setting up class and attribute level security, to supplying a docstring
if required to allow publication.

In CMFDefault, we have some base classes (tied to formlib) and we do
manual security with a ClassSecurityInfo and InitializeClass(). This
feels like a step backwards to me, at least in Plone, where we encourage
people to use browser views with declarative (ZCML) security. It's
difficult to explain that add forms are "special" so that they need to
have manual security, explicit docstrings (for better or for worse), and
be registered as an <adapter />, not a <browser:page />.

Did we envisage a solution to this? How about a new <cmf:addview />
directive that mimics <browser:page />, but registers the
(context,request,fti) adapter? I could probably put that together if
people think it's a good idea.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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

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

y.2008 at wcm-solutions

Dec 8, 2008, 9:59 AM

Post #2 of 14 (989 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Hi Martin!

Martin Aspeli wrote:
> [...]
>
> In CMFDefault, we have some base classes (tied to formlib) and we do
> manual security with a ClassSecurityInfo and InitializeClass(). This
> feels like a step backwards to me, at least in Plone, where we encourage
> people to use browser views with declarative (ZCML) security. It's
> difficult to explain that add forms are "special" so that they need to
> have manual security, explicit docstrings (for better or for worse), and
> be registered as an <adapter />, not a <browser:page />.
>
> Did we envisage a solution to this?

No.

> How about a new <cmf:addview />
> directive that mimics <browser:page />, but registers the
> (context,request,fti) adapter? I could probably put that together if
> people think it's a good idea.

CMF add views are different because they are looked up by a special
traverser, using the additional type info object. You have to be aware
of that. No matter if you use <adapter /> or <cmf:addview />.

It is not obvious why you have to use explicit Zope 2 style security for
add views and declarative Zope 3 style security for other views. But I'd
rather like to see the 'permission' attribute of <adapter /> implemented
for Zope 2 instead of a new <cmf:addview /> directive.

Cheers,

Yuppie

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

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

optilude at gmx

Dec 8, 2008, 4:33 PM

Post #3 of 14 (989 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

yuppie wrote:
>> In CMFDefault, we have some base classes (tied to formlib) and we do
>> manual security with a ClassSecurityInfo and InitializeClass(). This
>> feels like a step backwards to me, at least in Plone, where we encourage
>> people to use browser views with declarative (ZCML) security. It's
>> difficult to explain that add forms are "special" so that they need to
>> have manual security, explicit docstrings (for better or for worse), and
>> be registered as an <adapter />, not a <browser:page />.
>>
>> Did we envisage a solution to this?
>
> No.
>
>> How about a new <cmf:addview />
>> directive that mimics <browser:page />, but registers the
>> (context,request,fti) adapter? I could probably put that together if
>> people think it's a good idea.
>
> CMF add views are different because they are looked up by a special
> traverser, using the additional type info object. You have to be aware
> of that. No matter if you use <adapter /> or <cmf:addview />.

Sure.

> It is not obvious why you have to use explicit Zope 2 style security for
> add views and declarative Zope 3 style security for other views. But I'd
> rather like to see the 'permission' attribute of <adapter /> implemented
> for Zope 2 instead of a new <cmf:addview /> directive.

Mmmm... I'm not sure most people would find it natural to think about
the add form as an adapter like this.

Also, Five's <browser:page /> does quite a lot of stuff that we now
can't have for CMF add views:

o It allows a template to be registered
o It allows an attribute other than __call__ to be used to render
the view
o It sets up security on attributes, by interface or explicit list
o It sets up security on the view class itself

I don't think the adapter permission attribute would be sufficient in
any case. In Zope 3, it's tied to a type of low-level security proxy
that doesn't really exist in Zope 2. The ClassSecurityInfo stuff only
affects restricted python/traversal, whereas Zope 3 security proxies are
applied everywhere.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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

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

y.2008 at wcm-solutions

Dec 9, 2008, 4:46 AM

Post #4 of 14 (978 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Hi Martin!

Martin Aspeli wrote:
> yuppie wrote:
>>> How about a new <cmf:addview />
>>> directive that mimics <browser:page />, but registers the
>>> (context,request,fti) adapter? I could probably put that together if
>>> people think it's a good idea.
>> CMF add views are different because they are looked up by a special
>> traverser, using the additional type info object. You have to be aware
>> of that. No matter if you use <adapter /> or <cmf:addview />.
>
> Sure.
>
>> It is not obvious why you have to use explicit Zope 2 style security for
>> add views and declarative Zope 3 style security for other views. But I'd
>> rather like to see the 'permission' attribute of <adapter /> implemented
>> for Zope 2 instead of a new <cmf:addview /> directive.
>
> Mmmm... I'm not sure most people would find it natural to think about
> the add form as an adapter like this.

Well. I find it natural to think about browser pages as a special kind
of adapters. And since add forms don't fulfill all the special criteria
for <browser:page />, we have to fall back to the more generic <adapter />.

> Also, Five's <browser:page /> does quite a lot of stuff that we now
> can't have for CMF add views:
>
> o It allows a template to be registered
> o It allows an attribute other than __call__ to be used to render
> the view
> o It sets up security on attributes, by interface or explicit list
> o It sets up security on the view class itself

Sure. The question is: Do we really need these features for add views?

> I don't think the adapter permission attribute would be sufficient in
> any case. In Zope 3, it's tied to a type of low-level security proxy
> that doesn't really exist in Zope 2. The ClassSecurityInfo stuff only
> affects restricted python/traversal, whereas Zope 3 security proxies are
> applied everywhere.

AFAICS I didn't register the add views correctly. Provided interface
should be IBrowserPage or IPageForm, not IBrowserView.

Given that, in the Zope 3 world <adapter />'s 'permission' attribute and
<browser:page />'s 'permission' attribute would do the same: Creating a
security checker that protects 'browserDefault', '__call__' and
'publishTraverse' by the specified permission. Or am I missing something?

Currently this is not true for Zope 2. While Five implements Zope 2
specific behavior for <browser:page />'s 'permission' attribute, the
same attribute of <adapter /> is useless in Zope 2.

I can't see a fundamental problem in using the generic adapter directive
for registering browser pages. I just see limited support for the
adapter directive in Zope 2. As long as these issues are not resolved, I
can live with Zope 2 security declarations in add views.

Cheers,

Yuppie

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

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

optilude at gmx

Dec 9, 2008, 5:31 AM

Post #5 of 14 (978 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Hi Yuppie,

>>> It is not obvious why you have to use explicit Zope 2 style security for
>>> add views and declarative Zope 3 style security for other views. But I'd
>>> rather like to see the 'permission' attribute of <adapter /> implemented
>>> for Zope 2 instead of a new <cmf:addview /> directive.
>> Mmmm... I'm not sure most people would find it natural to think about
>> the add form as an adapter like this.
>
> Well. I find it natural to think about browser pages as a special kind
> of adapters.

Having explained this to a lot of different people with different levels
of experience, I think "natural" is too strong a word for most people.
The fact that browser views are adapters is an implementation detail
that often give people an "aha!" type reaction when they really
understand it. However, a lot of people will use browser views for a
long time without really understanding adapters (if they ever do or care).

> And since add forms don't fulfill all the special criteria
> for <browser:page />, we have to fall back to the more generic <adapter />.

Right. But there's a reason why <browser:page /> is "special".
Logically, views and adapters are quite different things, and, of
course, <browser:page /> does a lot more than just register an adapter.

>> Also, Five's <browser:page /> does quite a lot of stuff that we now
>> can't have for CMF add views:
>>
>> o It allows a template to be registered
>> o It allows an attribute other than __call__ to be used to render
>> the view
>> o It sets up security on attributes, by interface or explicit list
>> o It sets up security on the view class itself
>
> Sure. The question is: Do we really need these features for add views?
>
>> I don't think the adapter permission attribute would be sufficient in
>> any case. In Zope 3, it's tied to a type of low-level security proxy
>> that doesn't really exist in Zope 2. The ClassSecurityInfo stuff only
>> affects restricted python/traversal, whereas Zope 3 security proxies are
>> applied everywhere.
>
> AFAICS I didn't register the add views correctly. Provided interface
> should be IBrowserPage or IPageForm, not IBrowserView.
>
> Given that, in the Zope 3 world <adapter />'s 'permission' attribute and
> <browser:page />'s 'permission' attribute would do the same: Creating a
> security checker that protects 'browserDefault', '__call__' and
> 'publishTraverse' by the specified permission. Or am I missing something?

I'm not sure. Zope 2 doesn't really have a concept of security outside
restricted python/traversal, so the translation form Zope 3 is always
going to be a bit odd.

> Currently this is not true for Zope 2. While Five implements Zope 2
> specific behavior for <browser:page />'s 'permission' attribute, the
> same attribute of <adapter /> is useless in Zope 2.

I wonder why this is, though. There's probably a reason why the Five
developers didn't want to extend the security stuff to the <adapter />
registration.

> I can't see a fundamental problem in using the generic adapter directive
> for registering browser pages. I just see limited support for the
> adapter directive in Zope 2. As long as these issues are not resolved, I
> can live with Zope 2 security declarations in add views.

FWIW, I think this'll work:

<adapter
for="Products.CMFCore.interfaces.IFolderish
zope.publisher.interfaces.browser.IBrowserRequest
..interfaces.IDexterityFTI"
provides="zope.publisher.interfaces.browser.IBrowserView"
factory=".add.DefaultAddView"
/>
<class class=".add.DefaultAddView">
<require
permission="cmf.AddPortalContent"
interface="zope.publisher.interfaces.browser.IBrowserView"
/>
</class>

I don't much like it, though. :-/

I'd wager this is a lot closer to what people would expect:

<cmf:addview
for="Products.CMFCore.interfaces.IFolderish"
fti="..interfaces.IDexterityFTI"
class=".add.DefaultAddView"
permission="cmf.AddPortalContent"
/>

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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

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

optilude at gmx

Dec 9, 2008, 5:34 AM

Post #6 of 14 (978 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Martin Aspeli wrote:
> Hi Yuppie,
>
>>>> It is not obvious why you have to use explicit Zope 2 style security for
>>>> add views and declarative Zope 3 style security for other views. But I'd
>>>> rather like to see the 'permission' attribute of <adapter /> implemented
>>>> for Zope 2 instead of a new <cmf:addview /> directive.
>>> Mmmm... I'm not sure most people would find it natural to think about
>>> the add form as an adapter like this.
>> Well. I find it natural to think about browser pages as a special kind
>> of adapters.
>
> Having explained this to a lot of different people with different levels
> of experience, I think "natural" is too strong a word for most people.
> The fact that browser views are adapters is an implementation detail
> that often give people an "aha!" type reaction when they really
> understand it. However, a lot of people will use browser views for a
> long time without really understanding adapters (if they ever do or care).
>
>> And since add forms don't fulfill all the special criteria
>> for <browser:page />, we have to fall back to the more generic <adapter />.
>
> Right. But there's a reason why <browser:page /> is "special".
> Logically, views and adapters are quite different things, and, of
> course, <browser:page /> does a lot more than just register an adapter.
>
>>> Also, Five's <browser:page /> does quite a lot of stuff that we now
>>> can't have for CMF add views:
>>>
>>> o It allows a template to be registered
>>> o It allows an attribute other than __call__ to be used to render
>>> the view
>>> o It sets up security on attributes, by interface or explicit list
>>> o It sets up security on the view class itself
>> Sure. The question is: Do we really need these features for add views?
>>
>>> I don't think the adapter permission attribute would be sufficient in
>>> any case. In Zope 3, it's tied to a type of low-level security proxy
>>> that doesn't really exist in Zope 2. The ClassSecurityInfo stuff only
>>> affects restricted python/traversal, whereas Zope 3 security proxies are
>>> applied everywhere.
>> AFAICS I didn't register the add views correctly. Provided interface
>> should be IBrowserPage or IPageForm, not IBrowserView.
>>
>> Given that, in the Zope 3 world <adapter />'s 'permission' attribute and
>> <browser:page />'s 'permission' attribute would do the same: Creating a
>> security checker that protects 'browserDefault', '__call__' and
>> 'publishTraverse' by the specified permission. Or am I missing something?
>
> I'm not sure. Zope 2 doesn't really have a concept of security outside
> restricted python/traversal, so the translation form Zope 3 is always
> going to be a bit odd.
>
>> Currently this is not true for Zope 2. While Five implements Zope 2
>> specific behavior for <browser:page />'s 'permission' attribute, the
>> same attribute of <adapter /> is useless in Zope 2.
>
> I wonder why this is, though. There's probably a reason why the Five
> developers didn't want to extend the security stuff to the <adapter />
> registration.
>
>> I can't see a fundamental problem in using the generic adapter directive
>> for registering browser pages. I just see limited support for the
>> adapter directive in Zope 2. As long as these issues are not resolved, I
>> can live with Zope 2 security declarations in add views.
>
> FWIW, I think this'll work:
>
> <adapter
> for="Products.CMFCore.interfaces.IFolderish
> zope.publisher.interfaces.browser.IBrowserRequest
> ..interfaces.IDexterityFTI"
> provides="zope.publisher.interfaces.browser.IBrowserView"
> factory=".add.DefaultAddView"
> />
> <class class=".add.DefaultAddView">
> <require
> permission="cmf.AddPortalContent"
> interface="zope.publisher.interfaces.browser.IBrowserView"
> />
> </class>
>
> I don't much like it, though. :-/
>
> I'd wager this is a lot closer to what people would expect:
>
> <cmf:addview
> for="Products.CMFCore.interfaces.IFolderish"
> fti="..interfaces.IDexterityFTI"
> class=".add.DefaultAddView"
> permission="cmf.AddPortalContent"
> />

Meh - of course, I meant:

<cmf:addview
name="my.type"
for="Products.CMFCore.interfaces.IFolderish"
fti="..interfaces.IDexterityFTI"
class=".add.DefaultAddView"
permission="cmf.AddPortalContent"
/>

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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

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

optilude at gmx

Dec 9, 2008, 5:34 AM

Post #7 of 14 (978 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

charlie at begeistert

Dec 10, 2008, 4:28 AM

Post #8 of 14 (979 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Am 09.12.2008 um 14:34 schrieb Martin Aspeli:

> Meh - of course, I meant:
>
> <cmf:addview
> name="my.type"
> for="Products.CMFCore.interfaces.IFolderish"
> fti="..interfaces.IDexterityFTI"
> class=".add.DefaultAddView"
> permission="cmf.AddPortalContent"
> />

Hiya,

I agree that many people do not understand immediately that Views are
Adapters. This is partly conceptual but also related to conventions in
ZCML and elsewhere: it's very natural in English to contract "view
adapters" to "views" and "subscriber adapters" to "subscribers", etc.
which is why we get ZCML-directives like "subscriber" and "browser". I
think it is correct to encourage developers to move to the ZCML
approach for configuring security and as the new add views are CMF
specific using a special CMF directive would make this clearer.

A separate but related issue might be how we deal with CMFDefault: you
seem to refer to it in much the same way I do as the basis for more
work as it provides so much useful functionality out of the box but
Jens, Tres and others never tire of pointing out that it is actually
only a demonstration of what's possible. Should we think of breaking
the formlib stuff out of CMFDefault? So that it can be used without
CMFDefault? I don't know whether it should move to its own package or
CMFCore.

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]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2008 at wcm-solutions

Dec 11, 2008, 1:40 PM

Post #9 of 14 (960 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Hi!

Martin Aspeli wrote:
> Martin Aspeli wrote:
>>>> Mmmm... I'm not sure most people would find it natural to think about
>>>> the add form as an adapter like this.
>>> Well. I find it natural to think about browser pages as a special kind
>>> of adapters.
>> Having explained this to a lot of different people with different levels
>> of experience, I think "natural" is too strong a word for most people.
>> The fact that browser views are adapters is an implementation detail
>> that often give people an "aha!" type reaction when they really
>> understand it. However, a lot of people will use browser views for a
>> long time without really understanding adapters (if they ever do or care).

Well. I guess it depends on your perspective. For Plone users adapters
might be implementation details, for others they are important tools for
solving many different problems.

>>> I can't see a fundamental problem in using the generic adapter directive
>>> for registering browser pages. I just see limited support for the
>>> adapter directive in Zope 2. As long as these issues are not resolved, I
>>> can live with Zope 2 security declarations in add views.
>> FWIW, I think this'll work:
>>
>> <adapter
>> for="Products.CMFCore.interfaces.IFolderish
>> zope.publisher.interfaces.browser.IBrowserRequest
>> ..interfaces.IDexterityFTI"
>> provides="zope.publisher.interfaces.browser.IBrowserView"
>> factory=".add.DefaultAddView"
>> />
>> <class class=".add.DefaultAddView">
>> <require
>> permission="cmf.AddPortalContent"
>> interface="zope.publisher.interfaces.browser.IBrowserView"

AFAICS this should be IBrowserPage or IPageForm, not IBrowserView.

>> />
>> </class>
>>
>> I don't much like it, though. :-/

I like it ;) This is not perfect. But better than using oldstyle Zope 2
security declarations. I'll change my checkins.

> Meh - of course, I meant:
>
> <cmf:addview
> name="my.type"
> for="Products.CMFCore.interfaces.IFolderish"
> fti="..interfaces.IDexterityFTI"
> class=".add.DefaultAddView"
> permission="cmf.AddPortalContent"
> />

Providing customized solutions for specific use cases makes it easier to
solve these use cases, but it also makes the framework more complex and
less framework-ish. I can't see a need for the directive you propose.
But if you also volunteer to maintain the additional code in the long
run, I can live with it.

Cheers,

Yuppie

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

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

optilude at gmx

Dec 11, 2008, 2:26 PM

Post #10 of 14 (963 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Hi Yuppie,

>>>>> Mmmm... I'm not sure most people would find it natural to think about
>>>>> the add form as an adapter like this.
>>>> Well. I find it natural to think about browser pages as a special kind
>>>> of adapters.
>>> Having explained this to a lot of different people with different levels
>>> of experience, I think "natural" is too strong a word for most people.
>>> The fact that browser views are adapters is an implementation detail
>>> that often give people an "aha!" type reaction when they really
>>> understand it. However, a lot of people will use browser views for a
>>> long time without really understanding adapters (if they ever do or care).
>
> Well. I guess it depends on your perspective. For Plone users adapters
> might be implementation details, for others they are important tools for
> solving many different problems.

Adapters are of course important tools. However, the fact that browser
pages are named multi-adapters that provide Interface and adapt the
context object and the request, normally via a marker interface called a
layer that's applied to the request during traversal, is an
implementation detail, and one that requires quite a lot of explanation
and even then doesn't make a whole lot of sense unless you are quite
familiar with Zope 3's brand of the adapter pattern. It took me 32 words
to state that as completely and concisely as I could, without even
explaining any of the concepts.

The concept of a named multi-adapter is an order of magnitude more
advanced than, say, page templates skin layers or the concept of having
a class/template that's registered in an XML file. People who are not
steeped in software design patterns can learn the latter quite quickly.
They struggle with the former, Plone user or not.

> Providing customized solutions for specific use cases makes it easier to
> solve these use cases, but it also makes the framework more complex and
> less framework-ish.

Then why do we have <browser:page />?

You could of course do:

<adapter
for=".interfaces.IMyType
Products.CMFDefault.interfaces.ICMFDefaultLayer"
provides="zope.interface.Interface"
name="myview"
factory=".myview.MyView"
/>
<class class=".myview.MyView">
<require
permission="zope2.View"

allowed_interface="zope.publisher.interfaces.browser.IBrowserPage"
/>
</class>

> I can't see a need for the directive you propose.
> But if you also volunteer to maintain the additional code in the long
> run, I can live with it.

I can probably do that, but I'd like to know if others agree. I actually
don't have an immediate need for it myself, since I've implemented the
same thing for my specific use case using a martian grokker, but I
suspect people would prefer an analogue to <browser:page /> rather than
having to register their add views manually.

If we want people to use add forms (in Plone we certainly do - premature
object creation sucks), then we need to make it easy to do so.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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

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

regebro at gmail

Dec 12, 2008, 2:35 AM

Post #11 of 14 (962 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

On Tue, Dec 9, 2008 at 14:31, Martin Aspeli <optilude[at]gmx.net> wrote:

> I'd wager this is a lot closer to what people would expect:
>
> <cmf:addview
> for="Products.CMFCore.interfaces.IFolderish"
> fti="..interfaces.IDexterityFTI"
> class=".add.DefaultAddView"
> permission="cmf.AddPortalContent"
> />

Yes, although I'd probably call it addform. There is a browser:addform
in Zope3, right?

--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

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

y.2008 at wcm-solutions

Dec 12, 2008, 4:37 AM

Post #12 of 14 (961 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Hi!

Martin Aspeli wrote:
>> Providing customized solutions for specific use cases makes it easier to
>> solve these use cases, but it also makes the framework more complex and
>> less framework-ish.
>
> Then why do we have <browser:page />?

I guess primarily for historical reasons. And because zope.app is in
some parts an application, not a framework. And because the 'template'
attribute is sometimes a convenient shortcut.

> You could of course do:
>
> <adapter
> for=".interfaces.IMyType
> Products.CMFDefault.interfaces.ICMFDefaultLayer"
> provides="zope.interface.Interface"
> name="myview"
> factory=".myview.MyView"
> />
> <class class=".myview.MyView">
> <require
> permission="zope2.View"
>
> allowed_interface="zope.publisher.interfaces.browser.IBrowserPage"
> />
> </class>

The <class/> hack is not necessary in Zope 3. This is much closer to
<browser:page/> and easier to read:

<adapter
for=".interfaces.IMyType
Products.CMFDefault.interfaces.ICMFDefaultLayer"
provides="zope.publisher.interfaces.browser.IBrowserPage"
name="myview"
factory=".myview.MyView"
permission="zope2.View"
/>

Cheers,

Yuppie

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

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

y.2008 at wcm-solutions

Dec 12, 2008, 4:40 AM

Post #13 of 14 (961 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Lennart Regebro wrote:
> On Tue, Dec 9, 2008 at 14:31, Martin Aspeli <optilude-hi6Y0CQ0nG0[at]public.gmane.org> wrote:
>
>> I'd wager this is a lot closer to what people would expect:
>>
>> <cmf:addview
>> for="Products.CMFCore.interfaces.IFolderish"
>> fti="..interfaces.IDexterityFTI"
>> class=".add.DefaultAddView"
>> permission="cmf.AddPortalContent"
>> />
>
> Yes, although I'd probably call it addform. There is a browser:addform
> in Zope3, right?

'browser:addform' and 'browser:editform' automatically generate forms
based on a schema. The no longer supported 'browser:addview' directive
was much closer to the directive Martin proposes. Since this registers
an adapter that provides IBrowserPage, 'cmf:addpage' might be an
alternative.

Cheers, Yuppie

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

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

charlie at begeistert

Dec 13, 2008, 9:20 AM

Post #14 of 14 (950 views)
Permalink

Re: CMF add views and <browser:page /> [In reply to]

Am 12.12.2008 um 13:40 schrieb yuppie:

> 'browser:addform' and 'browser:editform' automatically generate forms
> based on a schema. The no longer supported 'browser:addview' directive
> was much closer to the directive Martin proposes. Since this registers
> an adapter that provides IBrowserPage, 'cmf:addpage' might be an
> alternative.

I'd be happy with either cmf:addview or cmf:addpage. There's no way
around the somewhat counterintuitive fact that the views are
registered for the containing object type but as long as this is
explained somewhere then anyone working with this should be okay.

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]lists.zope.org
http://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 lists@gossamer-threads.com