anyway, a couple of comments below...
Héctor Velarde On 20/09/12 18:10, Martin Aspeli wrote:
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?
HV> collective.cover was created to serve news, government and corporative intranet sites mainly; the package should be flexible enough for this audience, but easy enough to be used on smaller sites.
when you create a cover, you need to select the content that is going to be on it, among many other content that has been created recently; so, the screenlet is the solution to that.
a screenlet is nothing but a collections of ways to find a piece of content on the site.
we though on 3 different ways: a list of recent items with a search box attached to it; a "clipboard", a site structure tree.
currently, only the first way is implemented and it works like this: when you press the Add Content button, you will see a small window displaying a list of the most recent items; this window lists only certain content types, because you don't want to put a, let's say, folder in your cover. you can select one piece of content and drag and drop it inside a tile. all tiles know what content type is allowed to be dropped on it. there are tiles that support any content type, and there are tiles that support just one content type.
you can also search for specific text and the screenlet will display only the content containing that text, sorted by most recent first.
this has been proved to be usable by news site editors.I made a mistake on the message I just sent to the core developers list and now that I'm reviewing it I want to amend it: this code is based on what the MultiContentSearchFieldWidget does, but it does not depends directly on collective.z3cform.widgets.
the "clipboard" should theoretically work like this: an editor put a piece on content on her clipboard by marking it. when she goes to edit the cover, she will see all content she marked on the clipboard and then drag and drop it to the cover tiles. when she drags a piece of content, it will be removed from the clipboard.
the site structure tree should work the same way the plone.formwidget.contenttree works. but we need a new implementation as plone.formwidget.contenttree has demonstrated to be unusable on sites with hundreds of objects.
- 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
HV> yes, and we don't want that to happen; all tiles written for Deco should work on collective.cover; tiles written for collective.cover should probably have more features like permissions and configuration.
best regards
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
