Re: tiles/blocks
Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Message-ID | <[email protected]> |
On 18 Apr 2014, at 4:02 am, Guido Stevens <[email protected]> wrote: > Thanks Martin, this is delicious. It fills me in on the backstory of all these components. > > Of great interest in the scenario you're sketching: > - Layout definition/editing is a completely separate phase, intertwined with neither content editing nor rendering. Sweet. Maybe it's clear to others but I'm still confused by who you want to create the layouts and who you want to insert the tiles and what the skill level of each kind of user is? Know who we want to do what really helps understand what we build. Perhaps this might help your analysis at PLOG? My understanding of the deco design Martin outlined is below. This kind of requires a grid based layout editor since sitesetup users shouldn't be required to know html. And it means themers have to create themes that work with any layout (unless they can disable it) create layout | select layout | insert tile into layout | can edit tile settings -------------------------------------------------------------------------------------------------------- theming space | | | | -------------------------------------------------------------------------------------------------------- sitesetup | Y | Y | | -------------------------------------------------------------------------------------------------------- content space | | Y | Y | Y -------------------------------------------------------------------------------------------------------- The tinymce tiles is below. It doesn't have a concept of a reusable layout. It could be possible introduce default content however but thats editable after adding so not really a fixed layout. create layout | select layout | insert tile into layout | can edit tile settings -------------------------------------------------------------------------------------------------------- theming space | | | | -------------------------------------------------------------------------------------------------------- sitesetup | | | | -------------------------------------------------------------------------------------------------------- content space | | | Y | Y -------------------------------------------------------------------------------------------------------- it's also possible to a diazo solution without any grid editor needed. (i.e. themer can create mockups that include both tiles they configure or html markers to a content space UI that allows a user to insert a tiles in a certain direction but the size is fixed. Layout selection can be by diazo rule or via display menu) create layout | select layout | insert tile into layout | can edit tile settings -------------------------------------------------------------------------------------------------------- theming space | Y | Y | Y | Y -------------------------------------------------------------------------------------------------------- sitesetup | | | | -------------------------------------------------------------------------------------------------------- content space | | Y | Y | Y -------------------------------------------------------------------------------------------------------- What is it you are thinking of? create layout | select layout | insert tile into layout | can edit tile settings -------------------------------------------------------------------------------------------------------- theming space | | | | -------------------------------------------------------------------------------------------------------- sitesetup | | | | -------------------------------------------------------------------------------------------------------- content space | | | | -------------------------------------------------------------------------------------------------------- > - Layout selection can be done via injecting a <link rel="layout" .../> into any view. That provides the runtime fluidity I'm looking for. So this means that inside diazo mockups a themer can choose to enable or disable theme selection for any given theme (but not really "select a particular layout)? Still confused by the words "runtime fluidity". > > I look forward to exploring this line of thought and the existing code base at PLOG next week :-). You've provided a much needed mental map, thanks. > > -- > 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 > > > On 17 apr. 2014, at 18:43, Martin Aspeli <[email protected]> wrote: > >> 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 ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform