Is Diazo a deadend? What do we do?

Plone Support
1

I use Diazo regularly, even today I was doing customisations with Diazo and theme fragments on a client project. It seems the momentum for Plone 6 is towards headless + volto (or something very similar). I'm onboard, with some reservations.

My preferred workflow now is to do all my interactions and design in a Web design tool like Webflow and then use Diazo to "fit" it onto Plone. The signals I'm getting from the community make me feel like my workflow does not fit into the new paradigm. One of the big advantages of Diazo was that it matched this workflow and allowed me to really invest in the best (meaning more visual) theme design tools.

I understand that it's easier to bring people over to the platform if they interface with the tools that they already know (meaning a frontend stack that feels like what they use today).
Unfortunately, rather than supporting design with design tools, the web design tools of today are still what I call "code and peek".

If I'm being fair, Diazo does, in many cases still require code, but when strategically combined with themefragments it really doesn't have the same code and peek feel. It is more of an "assembly" task, a job that happens after the design step. It also means that I get the best of both worlds as my theme can get the full CI/CD treatment.

What I'm trying to ask is... is there a path for a Diazo like experience in the new paradigm?

Don't mind me, just venting a bit.

4 Likes
2

Good question!
In one of the last bigger projects we were using plone.app.blocks layouts and lots of tiles via plone.app.mosaic without the mosaic editing features. That made Diazo almost unnecessary.

Today, if not doing a frontend rendered JavaScript site, I'd explore that option again or even just doing templating the old way with customizing the main_template and speed up rendering by just including the parts I want.

3

So effectively we're looking at plone.app.blocks with tiles as a Diazo alternative.

4

I can recommend it. If you need some code pointers let me know.

On the other hand - tiles are more heavyweight than browser views: they have the possibility to have configuration which might not be necessary for your project. They are also rendered after the blocks layout is being parsed by plone.transformchain - and plone.subrequest come into play. On top of that, you cannot add any logic to the plone.app.blocks html layouts.

Instead you could also just use normal browser views and <tal:tile replace="structure context/@@viewname"/> (or so) them within other browser views...

So thinking again about that - I probably do not recommend plone.app.blocks layouts but the other variant outlined here :slight_smile:

5

When Diazo came out I was a huge fan of it. I had a (university) background in XML technology and I even enjoyed writing XSLT transformations. I think I even worked on the project where XDV (the Diazo predecessor) was born.

Though, after using Diazo for lots of projects for many years I came to the conclusion that Diazo ultimately failed to deliver its core promise: to make theming easier and less work compared to the old standard way of theming Plone.

To make things worse, I saw people putting an insane amount of work into writing complex transformations (sometimes even XSLT) to make things work in Diazo that would have been a no-brainer in a template. So for some people, I'd say a Diazo theme was even more work than the classic way.

Bottom line is that in my experience from the past 10 years the amount of work that you have to put into creating a Plone theme from a design (PDF et al.) hasn't really changed.

I am not talking about showing off how fast you can theme a site with Diazo. I used to show people how I could theme random sites they threw at me with Diazo in a few minutes and this never failed to impress people.

Though, when you need to deliver the real thing (a fully-featured polished theme), it does not matter if you are doing a classic Plone pre-Diazo theme, a Diazo theme, or a Volto theme. The amount of work you will have to put into it is basically the same (because you have to sync/merge the layout HTML/CSS with the CMS related HTML/CSS).

Therefore we never considered implementing Diazo (or something similar) in Volto.

If you are doing a classic Plone 5.2 theme I wouldn't consider Diazo to be a dead end. It is still the best practice and the way to go.

Mosaic and plone.app.blocks in contrast are a dead-end IMHO. The implementation is just outdated and overly complex. If you are not Asko, I wouldn't recommend using it (and he started to use Volto as well). :wink:

The main advantage of Volto theming IMHO is that you can do this with just HTML/CSS knowledge and minimal JS skills. I trained people in three days from almost zero knowledge in HTML/CSS to being able to do Volto themes. They did not have to learn a single Plone specific thing.

Using industry-standard tooling compared to a CMS specific solution (Diazo, Plone templates, etc.) will always win in the long run and this is the way to go IMHO (I am biased here of course).

3 Likes
6

The ideas that I'm grappling with are: workflow and working closer to the problem.

Working visually (ie. working closer to the problem)
Because of how I got into web dev, I tend to wear many hats (system admin, design, code etc..). When I'm designing, being able to think visually and work with code visually helps me stay closer to the problem. Think Adobe Illustrator vs trying to "draw" an SVG with a text editor. I don't have the same need when coding business logic.

Workflow
This is probably very opinionated but... Webflow is the closest to getting visual design for HTML/CSS right (with some trade-offs). The overall workflow means I'm able to think about design decisions and logic in the same space. By contrast the standard workflow tends to assume a designer that delivers a mockup in PNG, PDF or a vector format and then another team member that translates it into HTML/CSS. This workflow assumes that the "creatives" design and the "techinical people" implement. Perhaps it also assumes that those who can operate both "creatively" and "technically" are some kind of rare beast and therefore, to reduce risk, we build systems that separate the two functions.

Again, this is a semi-rant. This is not a strike against Volto or industry standards, @tisto matching your system with the industry approach is a sensible move. In the end, my "holy grail" for theme implementation feels Webflow-ish, ie. visual theme creation. Maybe I'm yearning for an approach that isn't suitable for the majority. For now, Diazo is the best "framework" that supports this approach.

In web dev as in life, the cheese is constantly moving so I'm keeping my running shoes on.

7

I believe @pigeonflight is specifically saying he doesn't always work on large projects where the theme is completely custom and a designer delivers the design to you in PDF. Webflow gives you the html, not a PDF saving you time.
Perhaps the word Diazo is what throws people off? What I believe @pigeonflight is talking about is little to do with XSLT and mostly what the effort and skills it takes to produce a theme from a workflow where you get given html, js and css, not a PDF. That could be because any of these apply

  • you buy a theme from somewhere like themeforest,
  • you use something like webflow,
  • because you are doing a site conversion from another technology where they don't want to change any html,
  • you work with a designer who knows html but not plone
  • or because you do government work and they a design system with templates you have to comply to.

The good news is that Redturtle did some work to make that more possible with Volto I beleive - Frontend — Plone Documentation v6.0. It would be great to see some real world stories of how that reduces the time to theme when given html not a pdf and how best to go about that because its unclear from that documentation how the whole process would work when you need to customise the html, not just include your own JS and CSS. Does that require forking volto completely? or overriding a large react component (and having to deal with merging in upgrades to this later manually) or is there some lighter quicker method to get the html to match the html you were given? And in a practical project what skills are needed and how long does that take on average?

At first look the example given in the documentation includes a lot of JSX code - design-volto-theme/src/components/ItaliaTheme at master · RedTurtle/design-volto-theme · GitHub. I'm not sure if they are volto overrides where just some small changes to html was needed or the theme really required very different custom components from volto. Or is that perhaps a bad example to compare with when you're researching if a quick conversion of given html, js and css is possible with volto?

8

Some more radical answer: honestly, I am sick with Diazo and all its implications.The more informed answer is perhaps: it depends on the nature and complexity of a site. With a site like www.onkopedia.com, we suffered a lot under Diazo. For new complex projects (complex regarding theming) I would likely goes with a headless approach (with all pros and cons). The decision about Volto vs not Volto, React vs. Vue has to be made be my frontend team. Personally, I am not much interested in Volto because I still dislike React a lot - but this does not count since I am usually no longer working on frontend stuff. Diazo is of course still an option where the standard Plone theming can be easily adjusted to the target layout...having some high expectations in Plone 6 and Bootstrap-based theme which will clearly solve a bunch of problems with Barceloneta customizations through Diazo under Plone 5.2

1 Like
9

Just to add my two cents, with Volto, volto-columns-block and volto-block-style you can get similar workflow and flexibility like you do with Mosaic.

1 Like
10

I am a big fan of Themingfragments and Mosaic.
With that, just a few lines of very simple diazo might be needed.

If it was possible to put permissions on themingfragments (about who could edit them / their fields), most of my use cases would be covered).

PS: Using 'normal permissions' on the fields will not work, they will save as 'empty'.

11

Hurray for themefragments!

One pattern I've settled on is using themefragments to display content stored in folders, I didn't want my users messing with the layout, only the content. For example a folder for sponsors with sponsor images which get displayed by a "sponsor" themefragment. As you can imagine, the themefragment could be presented as a slider or just a list. I then varied what part of the fragment was displayed using permissions (e.g. display special notes or "edit" links for administrators)

1 Like
12

It's a huge timesaver. It means everything is responsive and working as expected at implementation time. The big win is that your customer can interact with the "finished" HTML much earlier in the process, before you cut it over to Plone (this is probably similar with a headless approach). Depending on how thorough the PDF mockup is, you will be confronted with how best to deal with responsiveness etc.., something that is "solved" already once a Webflow prototype has been signed off by a customer.

@djay In terms of customisation, nowadays I try to avoid touching the backend experience. If you're customising backend perhaps Volto wins there.

13

Besides Volto, if we are coming to Core or Classic Plone development - which still has its use cases and an active community behind:

I am a big fan of using plone.app.blocks with site-layouts using it with plone.app.mosaic, which does all the wiring but with the mosaic editor disabled. Diazo is just a pass-through here, with one rule to copy all (because I did not find an easy way to disable Diazo).
This way I got full control over the site layout (everything around the content area, the part managed by views). A site layout is just a HTML page with some data-attributes to include tiles and very simple to create. You also do not need to care about viewlet-managers any more. All default viewlets are already available wrapped or re-implemented in plone.app.standardtiles ready to use in site- or content-layouts.

For content both can be used: content-layouts (again w/o mosaic editor) or classic views. This really depends on. As soon as you have reusable/repeating elements in different content views I recommend to choose content-layouts over views. Since tiles can take parameters, one tile may behave a slightly different appearance in different places while overall being a reusable snippet. I.e. we used it to control the header level (h1..h4) dependent on the place we used it or to control image captions.

I do not agree Mosaic is a dead end as mentioned above. The code is well maintained, there is a part of the community behind developing it and taking care, improving and releasing often. Even the well aged editor will get an overhaul to use Bootstrap 5 markup with coming with Plone 6. The editor is anyway the weak part here: it's JavaScript comes directly out of the stone and today one would write it completely different. However, w/o the Mosaic editor Blocks brings many advantages, to me it is the least important part here.

1 Like
14

I have two projects where we went all in with Mosaic. Due to the lack of an undo, the editing experience, especially when adjusting layouts is anxiety inducing.
At this point I've moved away from handing layout capabilities to clients and like the idea of disabling the editor.

@jensens...

  1. For a project that is already using mosaic layouts, is this "disabled mosaic editor" approach the way forward?
  2. Do you see this being viable 5 years from now? (this helps when planning)
15

Lets say you have a front-page (landing) page:
If it was possible that only 'admins' could edit 'fragment 1', while 'editor' could edit 'fragment 2' I would be happy.

Or (even better): Editor could edit 'content', but not 'settings'

1 Like
16

ad 1: You can freeze the existing layouts - but converting them is some work and needs custom migration code.

ad 2: In fact nobody can say. From my personal perspective I would say at least 3 active years are save to assume. In maintenance only mode 5 years or longer is very realistic. But it is OpenSource, so it dies if we decide to let it die.

17

One way forward that I saw today.... the Volto Slate editor looks like an interesting approach to handing layout capabilities to users. Data-driven Documents with Volto and Plone

18

@pigeonflight volto-slate is just a replacement for the draftjs-based editor used by Volto. It's nothing fancy in itself, except that it's more extensible, plugin oriented and it allows us to have "smart text", connected to Plone dexterity fields or sql data. So, just a replacement for the Volto richtext "line" editor. In fact if you don't know, you might confuse them.

But Volto itself, together with a couple of addons (mentioned above by me) can give you a simple editing interface where you can split your content with mobile-responsive columns,

19

Ah... so this is really about Volto, not so much volto-slate?

20

Yes. Volto gives us the "blocks" (the equivalent of tiles in Plone mosaic), but, by default, Volto doesn't give you a way to do complex layout with it. You can use the Align widget, but that would only give you 2 columns, with a hard to control behavior. volto-columns-block will give you a "row" with up to 4 columns where you can add any number of blocks.