[Product-Developers] Questions about collective.cover

Martin Aspeli optilude+lists at gmail.com
Thu Sep 20 21:10:27 UTC 2012


Hi,

I'm just digging into collective.cover a bit more, and I have a couple
of questions about the implementation that would help me understand it
better. Most of this is just about trying to understand whether we
should be pushing some of the tile related stuff upstream to
plone.tiles or not.

 - What are screenlets for?

 - Why do we need IPersistentCoverTile?

 - What is the idea behind populate_with_object() in that interface?
The idea of a tile being populated with a content object is confusing
to me. Is it something every tile needs?

 - Why do we have so many get_* methods in IPersistentCoverTile? Why
not just access through the tile data API?

 - Suggestion: Instead of storing allowed/disallowed groups to edit a
tile on the tile itself, maybe delegate this to an adapter? It would
allow c.cover to work with tiles not derived from its special
IPersistentCoverTile

Side note: I have a hope that most tiles will not need to be
persistent. There is something very clean and lightweight about only
storing configuration parameters in the query string in a tile href,
and annotations are somewhat opaque.

 - What is get_tile_configuration() for? Why are we looking up a
screen from the tile? Should the dependency not be the other way
around?
 - What is the purpose of ITilesConfigurationScreen? It seems to just
store things in annotations. Why the extra indirection?

 - What is get_configured_fields() for?

 - What is the thinking behind IBasicTileData? What is the use case
for most/all tiles having title, description, image, date (which
date?) and subjects (which subjects?) fields?

 - Why does IBasicTileData have get_* methods? Why not just access
through the tile data API?

 - What is the thinking behind the ConfigureTile namespace? How does
it differ from the stuff in plone.app.tiles?
 - Same about the edit form in edit.py - what is missing from p.a.tiles?

Anyway, sorry for the long list of questions. It does look really
clean and well written, just trying to understand the rationale. I'm
keen that we avoid a situation where people build a bunch of tiles for
collective.cover that ends up being incompatible with other uses of
tiles, or vice-a-versa. So, perhaps, we should push the relevant bits
of this up into p.tiles or p.a.tiles. It may also be worthwhile to
then release the tiles independently so that they can be used outside
of c.cover.

Martin


More information about the Product-Developers mailing list