Re: tiles/blocks
Martin Aspeli <[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Message-ID | <CAPN0AARFizO46xUcErRBrqE9+aa53easDsmg9QLy2b+R52BiUQ@mail.gmail.com> |
Hi, I'm not sure if this is what you're looking for, but I thought I'd share some of the design thoughts we had when trying to build Deco. The first question is *how* you actually edit the site layout (that is, the thing that determines the overall composition of the page, including a slot for "the content"). In a standard Plone 4.3 site, the layout is determined by main_template + possibly a Diazo theme, with some variable bits: the left and right slots that enumerate portlets, and the content area in the middle. We do have a TTW editor for Diazo themes, although it doesn't let you edit the *theme* per se except through editing HTML. I could see a mode where this was possible, for example by using a Deco-like grid editor to change parts of the theme HTML in a grid system, and then possibly injecting some kind of enumeration of tiles into the underlying Plone content (via a viewlet, say) and automatically mapping these in rules.xml. However, this probably gets quite confusing, as it's interweaving two concepts that weren't really designed to be used in this way. The way Deco thought about it was as follows: We have a generic rendering engine (plone.app.blocks) that acts as a transform (similar - and *prior* in the transform chain - to the Diazo theme transform). It looks for two things: tile references, which are just hyperlinks, and panel references, which are named containers analogous (but not identical) to ZPT's fill-slot mechanism. The rendering process is basically: 1) Render the content at the current URL. It should return a simple, semantic HTML document. The <body /> contains the content the user has created, and the <head /> contains any specific required resources such as JavaScript or CSS files. 2) In the head of this document, look for a <link rel="layout" ... /> to the *layout* to use. Resolve this in the background, to another semantic HTML document. 3) The layout should contain at least one panel placeholder (call it "main"), indicated by a `data-panel` attribute.. The content in step 1 should contain content to fill into that panel (indicated by an `id` that matches the `data-panel` attribute value). If so, replace the placeholder in the layout with the content. At the same time, merge the <head /> of the content into the <head /> of the layout, so things like custom CSS and JavaScript is included. Repeat for all panels. 4) The merged document might contain tile references (again indicated by `data-tile` attributes). Resolve each tile in the background, to another semantic HTML document. Replace the tile placeholder in the merged content/layout document with the tile's <body /> and merge any relevant <head /> links into the <head /> of the rendered document (so tiles can also indicate they need certain resources). All of this is implemented in p.a.blocks. See https://pypi.python.org/pypi/plone.app.blocks and its doctests. Now, the interesting bit for you, I think, is where the *layout* comes from. In plone.app.page, we have (had?) an implementation with the following semantics: - Either the view template for a content object, or the main_template, will render the <link rel="layout" /> so that when p.a.blocks fetches the content document, it finds a layout. - The `href` for this link is looked up either from an attribute on the content object itself, an attribute acquired from a parent folder, or obtained from the FTI. The idea here was that rather than have people manage "portlets" in a special UI, you would store globally a set of HTML documents (either in the ZODB or on the filesystem - we were using plone.resource in the same way that plone.app.theming is) representing available layouts. Each layout could contain a number of panels (but at least one, for the main body content, with a conventional name of `main`) so that content objects could override bits of the layout (e.g. you could also take over `left-column` or `footer`), and a number of tiles (e.g. "recent items", that is, the portlets use case). An administrator could choose the global layout, and in different sections (folders) you could choose a different layout, which would then apply to all the content underneath. This way, you could have different layout in /about-us, /photos, /news or whatever. In this world, main_template, and the views of the various content items, become pretty basic. They just render a semantic HTML document with relevant <head /> content and a <body /> consisting of one or more panels (usually one) where the content comes from the content item being published. So long as they provide appropriate semantics to obtain a <link rel="layout" />, then all the site layout semantics are there. If you were to adopt this, the biggest missing pieces would be: - A grid editor for building layouts, probably as a control panel ala plone.app.theming - Some UI to select layout by section - Insert/edit tile semantics (but see plone.app.tiles) - Enough tiles to support the use cases you have in mind (protip: virtually all tiles should be transient tiles that render simple HTML documents on a unique URL; persistent tiles are evil). Hope this helps, Martin On 14 April 2014 05:59, Guido Stevens <[email protected]> wrote: > I'm working with Netsight to improve the baseline for Plone intranets. > > We've identified having a tile-based layout engine as one of the key > technologies we need to have in place for this. > > This is not about "full deco" drag-n-drop editable WYSIWIG tiles: full > deco combines both layout (drag-n-drop tiles) and editing (editable > tiles). We want to focus just on the layout aspect and solve that first. > We're interested in rendering a constellation of application tiles, not > multiple richtext fields. > > We'd like to work with the existing plone.app.blocks + p.a.tiles > infrastructure if at all possible. My questions are: > > - Whom should we talk to / work with, aka who's been working with this? > > - Who has an interest in this and will be at Sorrento next week? > > I already know that Rok is not coming to Sorrento. Would there be > interest in having a separate sprint on this topic? > > :*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 > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Plone-developers mailing list > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/plone-developers > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Plone-developers mailing list Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/plone-developers