Support fully customizable areas in centrally managed "static" content layouts

[datakurre]

Open a new issue about this again, because this is still requested every now and then. I'm not going to work again on this any time soon, but probably this will evolve when we have more experience about the current Mosaic in production.

To recap, Mosaic has current two mode: You either select and use a pre-defined layout and be able to only edit its field tiles or re-configure its other tiles, or you fully customize the content layout. These are both valid use cases.

Partially customizable layouts is also a valid use case, but would add "a third mode" depending on the implementation either make the composition or layout design more complex. Yet, technically this would not be too difficult.

There is an outdated and unmergeable branch, which implemented this with just content layouts: https://github.com/plone/plone.app.mosaic/tree/datakurre-editable-static-tiles

A simpler option is to achieve this with more specific site layouts (yet could result in a lot of site layouts with a lot of redundant markup): such site layouts would contain both site layout and static content area layout and define editable slots only for those customizable areas. Yet, a fee additional changes would be required to allow editing of field tiles reconfiguration of other tiles outside those freely customizable areas.

[djay]

Another way to put the usecase is - if tiles becomes our primary way to
layout text, insert images, videos or dynamic content into text, then how
do you still allow that while having compulsory theme elements on the page
like titles, bylines, lead image etc.

The other use case is similar to portlet managers. Where you want to allow
users to insert multiple things in a row or col but not finite slots. For
example to have them automatically styled a certain way.

On Fri, 18 Sep 2015 5:52 pm Asko Soukka notifications@github.com wrote:

Open a new issue about this again, because this is still requested every
now and then. I'm not going to work again on this any time soon, but
probably this will evolve when we have more experience about the current
Mosaic in production.

To recap, Mosaic has current two mode: You either select and use a
pre-defined layout and be able to only edit its field tiles or re-configure
its other tiles, or you fully customize the content layout. These are both
valid use cases.

Partially customizable layouts is also a valid use case, but would add "a
third mode" depending on the implementation either make the composition or
layout design more complex. Yet, technically this would not be too
difficult.

There is an outdated and unmergeable branch, which implemented this with
just content layouts:
https://github.com/plone/plone.app.mosaic/tree/datakurre-editable-static-tiles

A simpler option is to achieve this with more specific site layouts (yet
could result in a lot of site layouts with a lot of redundant markup): such
site layouts would contain both site layout and static content area layout
and define editable slots only for those customizable areas. Yet, a fee
additional changes would be required to allow editing of field tiles
reconfiguration of other tiles outside those freely customizable areas.

—
Reply to this email directly or view it on GitHub
#134.

[djay]

Another usecase is

• how to have floated images, ie content flowing around an image or another
  kind of tile.
  The only way I can see that working is to allow tiles to be inserted inside
  tinymce as well. But maybe that's not such a bad idea?
  Or perhaps a special floating tile mode that doesn't push other tiles out
  of the but rather an text underneath?

On Fri, 18 Sep 2015 6:17 pm Dylan Jay dylan@dylanjay.com wrote:

Another way to put the usecase is - if tiles becomes our primary way to
layout text, insert images, videos or dynamic content into text, then how
do you still allow that while having compulsory theme elements on the page
like titles, bylines, lead image etc.

The other use case is similar to portlet managers. Where you want to allow
users to insert multiple things in a row or col but not finite slots. For
example to have them automatically styled a certain way.

On Fri, 18 Sep 2015 5:52 pm Asko Soukka notifications@github.com wrote:

Open a new issue about this again, because this is still requested every
now and then. I'm not going to work again on this any time soon, but
probably this will evolve when we have more experience about the current
Mosaic in production.

To recap, Mosaic has current two mode: You either select and use a
pre-defined layout and be able to only edit its field tiles or re-configure
its other tiles, or you fully customize the content layout. These are both
valid use cases.

Partially customizable layouts is also a valid use case, but would add "a
third mode" depending on the implementation either make the composition or
layout design more complex. Yet, technically this would not be too
difficult.

There is an outdated and unmergeable branch, which implemented this with
just content layouts:
https://github.com/plone/plone.app.mosaic/tree/datakurre-editable-static-tiles

A simpler option is to achieve this with more specific site layouts (yet
could result in a lot of site layouts with a lot of redundant markup): such
site layouts would contain both site layout and static content area layout
and define editable slots only for those customizable areas. Yet, a fee
additional changes would be required to allow editing of field tiles
reconfiguration of other tiles outside those freely customizable areas.

—
Reply to this email directly or view it on GitHub
#134.

[datakurre]

Thanks. Some of these are partially implemented:

Tiles can be annotated so that they cannot be moved and/or removed and/or edited (readonly) in the editor. So, when you press "Customize layout" the layout could still have kind-of-static parts (yet the layout is now saved locally and cannot be centrally managed). There's just not UI for adding those annotations yet.

There are "float left" "float right" tile styles in the tile format menu, which give you "floating tile". Yet it has some UI issues (sometime it's hard to edit a floating tile).

I guess, collective.tinymcetiles could be used together with Mosaic (or if there are issues, those could be fixed). Yet, having many ways to add/edit new tiles could be confusing.

[djay]

Lets called can’t move or remove
pinned”. It’s shorter :)
I guess the pinned/readonly function solves most use cases.
For example if you pin the title field to the top, then you can’t insert any tile above it?
But then let say you wanted to ensure the byline is pinned to the bottom of the page, does that prevent inserting other tiles above?
Perhaps there needs to be a directional pinning where you saying that you are preventing anything being inserted to the left or right or top or bottom or some combination.

Does this also mean, that the act of inserting an image for example means you have switched to customising the layout? And even though you might be prevented from moving any pinned tiles in your new custom layout, if the original global layout is changed then you won’t get any of those changes?
Could readonly tile contents always from the global layouts version during render? Could a pinned tiles dimensions be read from the global layout on render?

Also, how does the permissions work? Do some people get the right to customise a layout and unpin tiles? or perhaps everyone has a choice between customising a layout (with pins and readonly in place) vs copying a layout (they can do whatever)?

[datakurre]

Can't move is separate from can't remove :-)

Currently there's no "directional pinning", so tile can still be "moved" by adding tiles above. This sounds useful, but needs more logic into the editor.

You have to first click "Customize layout" to be able to insert new tiles. And then the layout is completely separated from the global layout. But I suppose we should enable ploneimage-plugin for TinyMCE so that images can be embedded into rich text areas in the old way without customizing the layout.

Technically the layout is either global (static) or local (customized) and there's nothing between. Yet, tiles in the layout may have local (persistent annotation) configuration overriding the "transient" configuration in the global layout.

Possible tile configurations are read from the global layout unless they are "reconfigured" even once, which creates a local configuration for them (not sure, if there's yet UI to remove that local override).

I must ping @vangheem for the permissions. I suppose that cmf.modifyPortalContent is enought for changing the layout, but "plone.CustomizeContentLayouts" is required for the "Customize layout" to appear.

[vangheem]

That is correct. It's not a hard permission, just a permission that is checked to configure the editor to allow layout customization.

[agitator]

I have the impression I'm running into this limitation over and over again.

This time I wanted to add 1-x contact persons via existing content tile to a page, but not luck without customizing and the layout. (Placeholders are not really an option)

[datakurre]

@agitator I've implemented this for myself with site-layouts, but my branch has still broken parts. I expect it to stabilize in 1-2 months.

This is, how this work for me:

1. User edits page and selects "content layout". Instead of traditional data-layout="@@page-site-layout" the content layout defines some specific site layout to use.

2. Site layouts, of course, use a good amount of tiles with fixed configuration to include required viewlets etc.

3. Site layouts may define panels without mosaic-grid (they can be surrounded with any HTML). Tiles in those panels may be editable in editor, but not movable or editable.

4. Site layouts may define panels with mosaic grid. Those panels can get their default contents from "content layout", but can also be fully customized.

[agitator]

To get a better understanding...

How are the slots of site layouts stored? Each slot get's it's own "layout" field?

[datakurre]

Single "content layout" (shared or customised) have always been able to contain tiles/layout/content for any amount of "panels". That's from original Deco design. The hard part was to support both customisable areas and static areas with customizable tiles. Since we made possible to customize tile configurations without customizing layouts (to support shared layouts, thanks to Nathan), this has been possible. Only that editor in master has currently issues with multiple panels. That's fixed in my branch, but it still has other issues (I haven't completed properties-overlay).

…

On 19. tammikuuta 2017 klo 12.16 +0200, agitator ***@***.***>, wrote: To get a better understanding... How are the slots of site layouts stored? Each slot get's it's own "layout" field? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#134 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAJyv17n_1pHyKI-KzdjcXpVzV3BcJBUks5rTzfqgaJpZM4F_yYA).

[agitator]

I think I have to try out your branch, to fully understand how an editor could add any additional amount of tiles to a shared layout.