search

plone / plone.app.tiles

Plone UI integration for plone.tiles
http://pypi.python.org/pypi/plone.app.tiles
Other
6 stars 7 forks source link

Deprecate and remove plone.app.tiles registry key? #9

Closed datakurre closed 8 years ago

datakurre commented 8 years ago

@jensens @vangheem @hvelarde

Would you have opinion on plone.app.tiles' plone.app.tiles-registry key?

I believe, it is supposed to list "currently enabled tiles". The only place it's currently used is "Add new tile"-form, which has not been used since some early Deco versions. I'm using it on a custom app based on early package versions, but would not mind seeing it go away. I feel it only complicates the stack, because all real use cases seem to require additional ways to define available tiles.

jensens commented 8 years ago

Offhead I think this can be removed w/o harm. I'am a big fan of simplifications.

hvelarde commented 8 years ago

in collective.cover we register tiles in that key and then we use it as a source to create a list of available tiles in the layout editor; how are you going to reimplement this? a vocabulary also?

https://github.com/collective/collective.cover/blob/master/src/collective/cover/vocabularies.py#L53-L72

I think this is no used anywhere else.

CC @rodfersou

datakurre commented 8 years ago

@rodfersou @hvelarde Thanks. That means we must keep the registry key definition in plone.app.tiles registry.xml until 3.x, but we could remove the use of the key in plone.app.tiles already in the next feature release in 2.x. I'll replace it in plone.app.tiles' add tile form by simply listing all available tiles (for which the user has add tile permission). That should not have any effect on collective.cover.

plone.app.tiles will continue to have it's own GS profile for browser and default rolemap. Also the upcoming CMFVersions support for persistent tile data will be in plone.app.tiles (I'll do it at Mephisto sprint).

datakurre commented 8 years ago

I'll replace this key with two context aware vocabularies