Re: [Plone Mosaic Sprint Barcelona discussion] Re: Plone Mosaic Sprint Barcelona June 10 - 13

Thanks Simone.
>> The first thing to do is to get rid of the 3-columns constraint that we have right now. The idea is to render the blocks (again... portlets, tiles, viewlets, it's the same) as a stream, one after each other. Each of them will have some metadata attached and exposed via data- attributes for instance. Those metadata can be based on type of element, type of content, global rules, etc. 

It should be trivial to look up (the default) viewlet managers and
portlet managers and render their contents as a stream of blocks (all on
the same level; probably each wrapped with a div with descriptive tags).

>> Note that, the main goal here is to ease the way we present the content of the page (what's now identified by the #portal-columns element) not the entire site layout.

Is this commonly agreed as the scope for the sprint? This would
definitively make the goal easier, because we can keep using the old
rendering for the rest.

> I would go one step further and say the themer should be given the
> freedom to decide how much control the admin and editors have over the
> layout, ie a decision made at the birth of a new site.

This sounds like how p.a.blocks is made to support two level of layouts
ootb: site layout and page layout. The both are technically just
HTML-pages (or HTML-code generated by views) defining the available
slots for rendered blocks with the difference that site-layout defines
the areas (in plural!), which are filled from the page layout.
>> Another difficult part - maybe not so difficult - is: which kind of blocks do we want? We had an interesting discussion with Ramon about the fact that portlets could fit the requirements instead of tiles

This more political than technical issue, because we can make all of
them (viewlets, portlets, tiles). Personally, I would not want to limit
the options.

>> To finally sum it up: on a lower level we need a good base for making rendering easier. On an upper level we need to find a good balance between flexibility and complexity. Is Deco enough for this? Maybe. We'll have for sure to bring back the "lost knowledge" from the deco experience (the project is kind of dead since nobody has move it forward since years) and try to take the best from it.

I'm quite familiar with most of the "Deco technologies" and would like
to help in re-using them. Especially, I think, it would be waste to not
re-use the well thought rendering model p.a.blocks.

To summarize the most important packages:

- p.a.blocks and p.tiles are solid and most widely used
- p.a.tiles (UI for creating tiles) has usability issues (because of
relying in overlays)
- p.a.standardtiles (tiles for all in main_template and default content
types) is completely broken, but its revision history has examples e.g.
rendering existing portlets and viewlets in tiles
- p.a.page (almost working, but may be too radical)

> One other goal that wasn't mentioned aspart of the discussion was one
> of the original deco goals of simplifying the editing experience by
> removing default pages, folders and collections and replace them with
> a way to insert blocks/tiles/portlets into the middle of the page.

This is in p.a.page. I tried it last week, got it runnning, and it's
mostly missing only the layout editor (well, and all the usable tiles,
because p.a.standardtiles is broken).

I'd guess that the sprint might benefit form p.a.page's ideas of content
type (or section) specific layouts, as a whole it's probably too radical
(and a direct rival for p.a.contenttypes).

Regards,
Asko

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs