browserlayer-registered views don't show up in portal_view_customizations

[davisagli]

...at least, not if you follow the example in the README.txt for plone.browserlayer.

In order for them to show up, the browser layer interface needs to inherit from zope.publisher.interfaces.browser.IBrowserRequest. It would be great if the docs could be updated to indicate this, as creating an add-on product that registers its views to a browser layer that only gets applied to sites with that product, and then wanting to make those views customizable, is a pretty common use case.

I'd be happy to update the README, but would appreciate someone else taking a peek and making sure this doesn't have side effects.

(I believe james4765 has also e-mailed you about this, optilude.)

[optilude]

Inheriting from IBrowserRequest doesn't work. I think we need to fix portal_view_customizations to be more inclusive.

Andi?

[davisagli]

Can you be more specific, Martin? I tried it out with inheriting from IBrowserRequest, and it seemed to work -- at least, my viewlets showed up in the customerizer, and I could customize them and see them applied to my site.

[witsch]

Replying to davisagli:

Can you be more specific, Martin? I tried it out with inheriting from IBrowserRequest, and it seemed to work -- at least, my viewlets showed up in the customerizer, and I could customize them and see them applied to my site.

in the meantime: david, could you perhaps attach a tarball of your code so i don't have to replicate things first in order to look into customerize? i'm very short on time these days, so it would greatly help... :)

[witsch]

Replying to optilude:

Inheriting from IBrowserRequest doesn't work. I think we need to fix portal_view_customizations to be more inclusive.

i don't think the marker interface should inherit from IBrowserRequest, but something needs to be changed in the way the views are registered. five.customerize, and plone.app.customerize for that matter, is build around that interface so it can't easily be extended, at least not for plone 3.1. somehow the views get registered differently here — well, obviously :), but also in respect to customerize — and imho this needs to be fixed somehow...

like i said, i'll try to look into it later this week, hoping david will send me some code... ;)

[jnelson]

example plone.browserlayer product showing problems with portal_view_customizations

[jnelson]

I've attached the product I put together, which is showing the issue. having IneHeaderViewletView inherit from IBrowserRequest allows it to be customized, whereas inheriting from zope.interface.Interface does not.

So long as inheriting from IBrowserInterface won't cause anything to blow up, I'd like to use the product, and address the issues with portal_view_customization once there's agreement on how the interface is supposed to work.

[davisagli]

Well, Andi, there really isn't any code to send...I just changed the following interface in my product:

class IMyBrowserLayer(zope.interface.Interface):
    pass

to the following:

class IMyBrowserLayer(zope.publisher.interfaces.browser.IBrowserRequest):
    pass

It would probably be a bit clearer for me to extend zope.publisher.interfaces.browser.IBrowserDefaultLayer, which in turn extends zope.publisher.interfaces.browser.IBrowserRequest. I spent some time in plone.app.customerize in pdb, and it looks like most things that are returned by getViews() pass its checks because of having IBrowserDefaultLayer.

For what it's worth, here is the inheritance tree for the IThemeSpecific layer which ZopeSkel creates for theme products, and which is already correctly showing up in the customerizer:

(theme product).interfaces.IThemeSpecific
 < plone.theme.interfaces.IDefaultPloneLayer
  < Products.CMFDefault.interfaces.ICMFDefaultSkin
   < zope.publisher.interfaces.browser.IDefaultBrowserLayer
    < zope.publisher.interfaces.browser.IBrowserRequest

So maybe I should extend IDefaultPloneLayer like this.

In any case, I don't think a change to plone.app.customerize is necessarily needed, except for perhaps a better comment explaining what getViews() is doing. :)

[witsch]

Replying to davisagli:

Well, Andi, there really isn't any code to send...

jim already sent some — i guess i just felt it'd make sense to use your code instead of potentially trying to reproduce and ending up like martin, i.e. not being able to. otoh it seems easy enough to track this... :)

I just changed the following interface in my product:

thanks for the details, i'll look into it as soon as i'm done with the csrf stuff, so hopefully when we're on the road later today.

In any case, I don't think a change to plone.app.customerize is necessarily needed, except for perhaps a better comment explaining what getViews() is doing. :)

heh, like i knew... ;)

[witsch]

(In [20094]) make sure the extension for browserlayers works for viewlets as well (this also fixes #7960)

[witsch]

customerize now knows about browserlayers, so view(let)s can again just inherit from zope.interface.Interface. could one of you, david or jim, perhaps verify this again? :)

[davisagli]

Yep, I confirmed that it works for our use case. Thanks!

[witsch]

(In [20100]) some more tests (see #7960)

[witsch]

Replying to davisagli:

Yep, I confirmed that it works for our use case. Thanks!

thanks for checking — i'll make a release to be included in 3.1rc1 in a few minutes... :)

[witsch]

(In [20103]) another test for the browserlayer extension (also see #7960)

[witsch]

Replying to witsch:

thanks for checking — i'll make a release to be included in 3.1rc1 in a few minutes... :)

fyi, just released and included for 3.1...