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.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

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

Reply via email to