Re: tiles/blocks

Martin Aspeli <[email protected]> Thu, 24 Apr 2014 11:08:05 +0100
Newsgroups	gmane.comp.web.zope.plone.devel
Message-ID	<CAPN0AAR+X3RytcUet9e77dzF0dGnwmardafV-o1FWSXBmh9hCg@mail.gmail.com>
Hi,

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)
>

<snip />

> - 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".
>
>
If we require themes to be able to render a very simple grid *in some parts
of the page*, then that may not be so onerous. As a sketch:

~~~~~

The rendering model is basically: [content] -> [main_template] -> [panel
merging] -> [tile merging] -> [Diazo theme]

[content]

A content item renders itself using a page template. It references
`main_template` and fills the `content` slot as normal. The output is
semantic HTML. It may contain tile references.

[main_template]

Renders some basic structural markup to help the panel merging. Basically:

<head>
  <link rel="layout" tal:attributes="href view/currentLayout" />
  <!-- other head resources -->
</head>
<body>
  <div data-panel="left" tal:content="structure view/renderLeftTilesGrid">
 </div>
  <div data-panel="main" tal:define-slot="content"> <!-- main body content
tiles --> </div>
  <div data-panel="right" tal:content="structure
view/renderRightTilesGrid">  </div>
</body>

The idea is that we reference the layout (perhaps looked up as a property
on the context, a parent, or the site), and we define the panels we want to
populate.

Note: In a slightly more radical world, we probably don't need the
main_template indirection at this stage, because most of the things we do
with main_template today would be done by the layout. However, as a
transitional step it makes sense, because otherwise we'd need to update all
the view templates or all content types for this to work.

Note 2: From this point on, the HTML rendered by [content]+[main_template]
will be called the "page layout".

[panel merging]

At this stage, the first plone.app.blocks transform kicks in. It fetches
the referenced site layout, which we'd probably store in a plone.resource
type directory and make editable TTW. It may include content both inside
and outside panels. Any content *inside* a panel in the site layout is
liable to be replaced by a panel from the page layout.

The kicker here is: if we have a tile/grid editor, it should only require a
grid inside the panels. If this grid is quite simple (very basic CSS, no
real dependencies) then it's probably not too onerous to require a Diazo
theme to include this CSS and render a basic grid.

[tile merging]

At this point, we have a full page with tile placeholders. They will be
replaced with actual tiles by the second plone.app.blocks transform.

[Diazo theme]

Each panel will have an id. The Diazo theme will replace this into the
theme. So long as it can render a simple grid system, then it'll render the
right layout of the content, left column, right column, footer, header, or
whatever other aspects we chose to make editable.

~~~~~

In this model, we have a layered model of layout editability. From top to
bottom:

 1) The Diazo theme (technically optional): Requires HTML/CSS skills. Some
minor CSS requirements (a basic grid that must work inside the editable
bits of panel, an ability to render things like content listings when
produced by tiles), but this is not really different from what happens
today. Target audience: web designers.

 2) The placement of tiles into the grid in the various panels of the site
layout: Can be done with a GUI through Site Setup. It's possible to define
multiple different site layouts (corresponding to different sections of the
site). Target audience: site administrators.

 3) The definition of panels and their logical placement in the "unthemed"
site. Requires HTML/CSS skills. The easiest way to implement this would be
to have some "skeleton" layouts (3 column, 2 column, with header/footer,
etc) that we ship as flat HTML files. When an administrator goes to create
a new site layout, the "skeleton" is copied into an editable object. The
GUI editor allows changing the contents of the grid inside the pre-defined
panels, but not the static bits around it. Target audience: Integrators.

This is also why the Diazo bit is technically optional, because you could
get away with implementing the look and feel entirely in the site layout.
It'd just be more brittle and fiddly.

 4) The panels and any static content (hopefully none) in main_template.
Requires ZPT skills. Hopefully rarely needed. Target audience: Core
developers.

 5) The view templates that render content items. Requires ZPT skills.
Target audience: Core developers and add-on developers.

Martin

------------------------------------------------------------------------------
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

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers