[Plone-UI] [Plone-developers] Plone 5 Theme

Timo Stollenwerk tisto at plone.org
Mon Nov 18 16:32:28 UTC 2013

Hi Nathan,

Am 18.11.2013 16:54, schrieb Nathan Van Gheem:
> On Mon, Nov 18, 2013 at 9:44 AM, Timo Stollenwerk <tisto at plone.org
> <mailto:tisto at plone.org>> wrote:
>     Am 18.11.2013 16:23, schrieb Ramon Navarro Bosch:
>     > Mainly for two reasons:
>     >
>     > * In most of our use cases the client prefers no modals ( there is
>     a lot
>     > of content edition and they love to see the edit and the view with the
>     > same skin )
>     + 100
> ...
>     Not having a separation between backend and frontend has always been one
>     of the biggest selling points of the Plone UI. As far as I can tell
>     other CMSes are trying to get rid of that separation for a good reason.
> which ones? Others are doing the contextual editing finally but, if they
> mix editing, they'll just end up getting the same theming nightmare we have.

If you don't want a separation of backend/frontend there is no way
around having to integrate those two. If you want the edit overlay to
look like the real page, you have to do the integration on just another

>     We are about to go into the opposite direction "to make theming easier"
>     (which was the original point of p.a.toolbar if I recall correctly).
>     Though, according to Ramon and what I saw so far theming will become
>     more complicated with p.a.toolbar.
> It's not more complicated to theme with plone.app.toolbar. It might be
> more difficult to theme the backend...

The rationale for p.a.toolbar was to make theming easier. It seems to me
we are just making one use case easier and another one a lot more

>     > * In most of our use cases the client needs specific edit forms
>     (skinned
>     > and layout) so it's common that we need to skin also the backend
>     and the
>     > edit forms layout.
>     Same here. Right now I can't imaging to use p.a.toolbar/modals (again)
>     for my customer projects (for UI as well as technical reasons that I
>     pointed out before) and I would really like to see a Plone 5 where I'm
>     not forced to use overlays.
> Wow, yikes. Are you sure these customers just aren't too used to the old
> plone way of doing things? Have you tested this on new customers?

No. As I told you long time ago (at sea sprint I think :)), I had a
larger project where we wanted to use a top toolbar and edit forms
overlays and failed miserably, both on a technical and on a UI level.

In the end we had to remove all overlays because we could not handle it.
Maybe technology has moved on since then and the people working on it
today are a lot smarter than we were back then...

> So what you're saying is that we should maintain backend css in our
> themes still and then also maintain all the toolbar, modals, etc. Sounds
> like a really bad idea.

I'm just saying that we might want to take a step back and should look
at what our objectives for p.a.toolbar were. Then we should compare the
new solution with what we already have. Changing things always comes at
a cost (developer, integrators have to adapt, existing sites have to be
migrated, old use cases might not work any longer, etc). If the new
solution does not offer a significant advantage over the old system, we
should just not do it.


More information about the UI mailing list