gyst
commented
10 years ago On 17/06/14 08:18, Asko Soukka wrote:
There has been a long discussion about plone.app.blocks causing issues with AJAX HTML-snippets and JSON-data (with wrong content-type header).
5 https://github.com/plone/plone.app.blocks/issues/5
What do you think, should be make the transform opt-in instead of opt-out? @bloodbare https://github.com/bloodbare @simahawk https://github.com/simahawk @gyst https://github.com/gyst @hvelarde https://github.com/hvelarde @robgietema https://github.com/robgietema
The change would be that plone.app.blocks would not register its IBlocksLayer during GS import (install/activation), but each view that require transform, should apply it to the request individually.
That's ugly.
Ideally you'd want the blocks transform to behave as a multi-adapter on (view, request) so you could switch it on/off via a marker interface on the view.
However, the transform chain is coded in a way that only looks at the request, agnostic of the view. To then implement per-view behavioral switching by toggling an interface on the request feels icky.
Not that I have a better alternative :-(
If we were to go that route, I propose to keep IBlocksLayer on by default since that conforms to what everybody is expecting from other packages, and it is also useful by itself (e.g. the resource views ought to be bound to that layer).
Instead use a separate marker IBlocksTransformEnabled to switch on the transform adapters.
In c.cover that would require either the view of c.cover doing alsoProvides for request or just to register the layer in its own GS profile.
GS would not be valid, since it would apply globally across the whole site and might break other add-ons on non-cover pages in the site.
In Plone Mosaic that would require alsoProvies into the default view of ILayoutAware (in p.a.blocks' mosaicsprint-branch) and the same in main_template-view and content-type view traversers in p.a.mosaic.
In c.dynamicmosaic this would require something else (I've not yet looked into its implementation).
Extends plone.app.blocks, so same change applying alsoProvides(IBlocksTransformEnabled) on the request for each view.
There might be some pro's for this, e.g. you could AJAX load site layouts and content layouts without getting them tile-transformed automatically.
:*CU
Guido Stevens | +31.43.3618933 | http://cosent.nl
s o c i a l k n o w l e d g e t e c h n o l o g y
datakurre
There has been a long discussion about plone.app.blocks causing issues with AJAX HTML-snippets and JSON-data (with wrong content-type header).
https://github.com/plone/plone.app.blocks/issues/5
What do you think, should be make the transform opt-in instead of opt-out? @bloodbare @simahawk @gyst @hvelarde @robgietema
The change would be that plone.app.blocks would not register its IBlocksLayer during GS import (install/activation), but each view that require transform, should apply it to the request individually.
In c.cover that would require either the view of c.cover doing alsoProvides for request or just to register the layer in its own GS profile.
In Plone Mosaic that would require alsoProvies into the default view of ILayoutAware (in p.a.blocks' mosaicsprint-branch) and the same in main_template-view and content-type view traversers in p.a.mosaic.
In c.dynamicmosaic this would require something else (I've not yet looked into its implementation).
There might be some pro's for this, e.g. you could AJAX load site layouts and content layouts without getting them tile-transformed automatically.