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@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests