Is Diazo a deadend? What do we do?

Plone Support
21

My 5 cents, on the Volto side of things, although this is not about Volto vs Diazo fight:

If you use Diazo for rapid prototyping, there are a lot of tools that can go from the design to React directly (even with behavior on them), and back again (so the roundtrip is supported). Look for Figma React and others. That should work with Volto or even with plain React for early stages of development.

Regarding customization, of the presentation only part, when it comes to the current components, it's known that the current shape of the Volto components need to be splitted between the logic and the presentation to make easier and more accurate the customization story. Some of the current components are too big (even huge). We will get there.

It is also known that Volto needs more insertion points, and I can say there is an effort to design how to implement them in the most approachable and extensible way, Plone style.

At the end, we all know that "implementations change, but ideas remain". You won't see a Diazo implementation in JS, but we have enough experience with how theming works and what works and what doesn't we have to make Volto provide this knowledge in the form of familiar patterns for theming/customization story.

Regarding theme fragments, a theme fragment is a view that does/renders something and you put it somewhere in the DOM, right? In React, that is a component, placed with a React Portal whereever you want. Again, concepts and ideas are the same, implementations and naming differs.

To end, during my talk last year I mentioned Diazo a bit :slight_smile: let me rant about it again.

Any of you remember Diazo motto?

“We write XSLT so you don’t have to”

I even think it's on the documentation. I laugh at it every time I remember it.

After all these years of experience implementing Plone themes, (including Barceloneta itself), I got to the conclusion that Diazo was at the same time, both the most amazing technology Plone ever got to add to its stack and the worse one, at the same time. If you ever tried to teach Diazo (while teaching Plone Theming) you know what I'm talking about. Let me explain.

It's the most amazing because it allowed power users to achieve all the "wow" moments and the agility for prototyping that you all have mentioned. It provided an easy, magical way to modify "on the fly" HTML to match your desired one, to amazingly place dynamic pieces here and there in a store-bought theme.

BUT, sorry Diazo, it also was the worse, because the “we write XSLT so you don’t have to” was a lie, and because of it, it has the privilege to be the least approachable technology in the whole Plone stack. The truth is, that if you really wanted to do magic, you'll have to learn XSLT and come up with terrible transforms, just to keep the simplest class attribute to not break the CSS of your pre-baked shopped theme.

I found incredibly simplest (to teach, to implement, etc) to just shadow whatever thing you have to change with the HTML of the desired design, even in plain Plone using JBOT.

BTW, @pigeonflight thanks for your famous "Diazo snippets", it was countless of times I used them as a documentation reference while writing my themes.

So yeah, I'm not going to miss Diazo if at some point it just go away.

2 Likes
22

not really… although you can do that and inject or replace it with diazo.

The best use case is with Mosaic.
You have a folder 'fragments' in your theme. Every fragments has a view.pt. If you need settings, you use an XML file view.xml . The XML is basically the same as a dexterity content type, so you can just copy it from the TTW Dexterity Types control panel if you want.
You can also have logic, which you put in your view.py file

So lets say you want a block in you view saying

2 + 2 = 4 (or 3 + 3 = 6), you add

template.pt

<p>${view/data/number1} + ${view/data/number2} = #{view/sum} <p>

in your view.py

def sum():
    return self.data['number1'] + self.data['number2']

and in view.xml

… <field name="number1" type="schema.Int"> …
.... <field name="number2" type="schema.Int">
23

This is the part that I'd like to see explained exactly how this works in terms of the BYO theme usecase.
I guessing kitconcept does this rarely and perhaps for others involved in core development. I agree that Diazo results in XSLT and that is not pretty. This is not about Diazo the implementation but the concept of DIY themes.

Let me give you an example. These guys came to us a couple of years ago with a problem. lecc in nsw.gov.au. They had a site on another technology that had overpriced yearly fees. We could offer them the same or better CMS functionality via Plone at a lower price. So how do we convert them without the cost of conversion wiping out the gains they make on yearly hosting/support/licensing?
They had already spent money on the design, got it approved, accredited and didn't want to go through that process again and people were happy with the design.
As you can see by looking at the internet archive the site didn't change. We use the same html, js and CSS with adding in the bare necessities to style plone content. We use the frontend/backend split so the plone editing experience did not require customisation. We use mosaic on the front page and some plone technology to turn that into the original theme html so the final result is exactly as it used to be, only now they control with Plone. All that was relatively quick and low risk.

We haven't moved volto yet. What is the process to do the same thing using Volto? @sneridagh

24

I'd bet that you can get pretty close to what you're looking for with Volto.

You can shadow (overwrite, like z3c.jbot) any Volto file so you add your own custom logic in the overall page structure. Maybe you want the breadcrumbs above the footer, who knows.

Let's say you don't like the markup produced by a block. You can wrap the block view (or edit) component in another component or totally replace them.

In my experience, the bigger Diazo challenges were related to the main navigation menu. For this there's volto-dropdown menu, where you can build TTW complex "fat menus". There's no equivalent for this in Plone right now, AFAIK.

Another important aspect: Volto is UX-improved Mosaic. There are two basic capabilities in Mosaic: layout and combining blocks in a single page. The layout part is intentionally not provided, by default, by Volto, but the second part is really core Volto, creating and combining blocks on a page are basic things in Volto. And for the layout part, splitting rows into columns, there's plenty of solutions as well.

I think we're missing one core aspect: with Volto we have access to a huge variety of React libraries and components and integrating most of them is mostly an easy task. Right now I can't find any decent Plone gallery addon, for example and trying to integrate one would be more then I can stomach. With Volto you can literally draft an addon that integrates with other React/JS libraries in a matter of minutes.

25

Well, it was a rethoric question, I do know what a theme fragment is :slight_smile: What I didn't know is the small XML thinggy, nice.

My whole point in that statement is that in React, that feature can be achieved in matter of minutes by using first class citizens (components, Portals).

Also, do not miss the new Dexterity content types blocks layout feature in Volto. Kudos to EEA and @avoinea for it.

26

@djay First, again, I didn't want to start a Volto vs Diazo fight, I just wanted to give an update and make sure the community knows all the goodies the Volto community is delivering these days to Volto. Also make sure that people know Volto is in continuous improvement and polishment process and everybody is welcomed to participate.

Regarding the theming, of course we (at kitconcept, and in other companies too that are Volto early adopters) have this use case. RedTurtle introduced a way to use a completely different CSS framework in Volto some months ago, so you are no longer tied to SemanticUI anymore.

The example you mentioned, in fact, I've been doing exactly that these last days. A project where we have to deliver a Volto theme exactly with the same look and feel than the original one. It took me very little to reuse the existing CSS and shadow a few components to make it looks like the original, no Diazo of course. Every time when I did that in bare Plone with Diazo, it always took me more time figuring out the XSLT transforms more than if I would have just JBOT the whole thing. As said, is good for prototyping, but for the real thing, (including matching internal tiny classes, match the originals, etc) you always end up making these small adjustments.

I hope all of you have read: https://plone.org/news/2020/data-driven-documents-with-volto-and-plone

Leaving Diazo behind is well worth in exchange of the whole new world that Volto opens.

FYI there is an almost a whole Volto track during the conference, so you can see first hand the new features the Volto community pushed into it last year, and get a grasp of what you can achieve with it.

27

The challenge I see at the moment with any Volto adoption by the Plone Community:

Since the beginning of 2020, now 4-5 companies with maybe 20-25 people have been working very very hard to use Volto as an open sourced internal toolkit to develop and deliver custom projects to the paying clients they have found.

[RANT] But the only output to the rest of the community have been links to repositories and some marketing documents thrown over the wall of how cool the end result with Volto could be if you have a lot of paid (work) time to spend on using React/Volto.

Meanwhile Volto is a Tesla/Porsche 911 with

  • a stuck gearbox (layout blocks to do any formatting like mosaic are in custom repo's and not installed by default)
  • a wooden steering wheel (Lets use a 2.5 year old draft.js component, no sorry, we prefer Slate, no let's pick the next editor component)
  • no user manual
  • no place to get a drivers' license to obtain unless you work at the manufacturer.
    [/RANT]

I completely understand this. I've been wanting to spend much more time with React/Volto this year, but been fully absorbed with Plone 5.2 migrations, custom projects, supporting legacy installations for our existing customers. etc.etc. There is only so much free time left to do some useful community work with the knowledge I already have. And your first sound (business) priority is earning a living and that's using whatever there is to deliver functional cool stuff to your own client projects, be it with Volto, Plone 5.2, Mosaic, Diazo of Plone 4. :open_mouth:

The current situation with a superlekker 75% finished end product without consensus among the early adopters how the last 25% should be delivered as a 1.0 or up to date developer documentation after a year of delivering customer projects with it is in my opinion the biggest hurdle for further Volto adoption into Plone.

28

And yes that was a rant to spike some discussion. :mask: I'm very well aware of all the great existing documentation efforts, I wrote the post myself september 2020 at the end of the thread here:

29

IMHO, this is a critical piece of the puzzle for integration etc...

30

a stuck gearbox (layout blocks to do any formatting like mosaic are in custom repo's and not installed by default)

Those addons are open source, you can add them to a latest Volto release and they'll work. By having them as an addon, we can iterate development faster. Once they've stabilized they'll be forked to collective.

My wish is for a bigger Volto community, so that it's easier to make decisions on what to include in core Volto. You can't judge if your needs are "fringe" or mainstream without a bigger diversity of projects around. Would you want a single company making these decisions? From my side, Volto should stay as lean as possible while also open to extending. I've contributed to the "Volto addons story" for exactly this: make it possible to extend Volto with new functionality without a lot of conflict.

a wooden steering wheel (Lets use a 2.5 year old draft.js component, no sorry, we prefer Slate, no let's pick the next editor component)

That comes down to a personal decision that I made. The volto-slate is, again, just an optional addon. For our use case it works better because we've put development time in it. The community "at large" uses draft. May I remind you about Kupu and FCKEditor, some other editors that Plone used along the way before settling on TinyMCE?

no user manual

That is indeed a problem.

no place to get a drivers' license to obtain unless you work at the manufacturer.

That is exactly what Volto is not just trying, but actually solving: allow non-Plone people to work on Plone projects.

1 Like
31

yup, every month or so, I take a peek and see how far I can get with Volto.
My last attempt resulted in this... Tip: Running Volto on AWS Cloud9 you'll need to set a few env variables such as PORT - #6 by pigeonflight

32

@fredvd This is not about Diazo anymore :slight_smile:

There are indeed challenges, a huge amount of them. Challenges that should be addressed as a united community. The community is fully aware of it, you named just a few. We are in continuous improvement, and the same Volto nature allows us to do giant leaps forward, but we need hands to continue nurturing it. I'd say Volto is where Plone 2 was back in the day.

Yes, we have kupu on it, but hey, we already have Mosaic (one with superpowers) on it. We still don't have portlets or viewlets, but we will get (soon) to them.

That's why today I asked for keeping the focus in other discussion.

I'm confident we will get there, together.

2 Likes
34

Whats wrong with plone.gallery?
I'm open for ideas.

35

(2020-06-11) initial release

Nothing wrong, but I did not knew about it, or it wasn't available when I needed it. I'll use it for sure, now that I know about.

1 Like
36

It is pretty simple, could properly use some flexibillity in the configuration, there is nothing yet. But it does a pretty good job out of the box, for album style view and and zooming into a gallery. The tools i used are spotlight and flexbin.
And yes i build it, for the same reason, there was nothing excaptable out there for me :slight_smile:

37

Hi David it's been a long time ;). I will have a talk "Plone 6 Theming with Diazo" at the conference, about this topic.
And besides the points of Plone backend markup being easier to integrate into your theme, especially when you are using Bootstrap markup, I'll also show what i understand of using the right mix.

Diazo is great in what it does, if one does not use it to fix backend problems, nobody needs to write XSLT to do a theme. I also refactored the existing XSLT from plonetheme.barceloneta to stay not so much in the way. I was never really happy with the big XSLT chunk in the rules. Now there is still a bit XSLT, but it's in a separate file and it only handles the css classes for bootstrap. If we would use bootstrap mixins instead of these classes in the template, we could even avoid this. Now the content area uses a normal replace to insert the content into the template, which is easier to customize.

If parts of the backend markup are not as you need it, I recommend to override them rather than fixing this in XSLT. With jbot this is simple enough and keeps the Diazo theme clean.

With the Resource Registry becoming less of a burden, it should also getting simpler to insert UI components where one need some. Of course this not Volto, but I believe there is something between JQuery and SPA wonderland. So if you are stuck on the classic stack, you don't have to suffer to much.

1 Like
38

Sounds like a good talk. My current workflow is based around TTW themes and plonethemeupload. I only touch jbot when I use filesystem themes.

39

jbot or collective.themesitesetup both allow you to override templates or create new once. collective.themesitesetup is awesome but right now not supporting Python 3. And when you are using a Python package anyway, you don't really need it. With jbot and GS profiles you have the same options.

Keep in mind, that in Plone 6 there will be no LESS compiling in the Browser, so you have to use vanilla CSS or compile LESS/SCSS outside of Plone before uploading your theme. Compiling SCSS in Plone backend is theoretical doable, but it is currently not planed to keep the Resource Registry as simple as possible. But compiling/bundling of JS in the Browser will definitely be not supported anymore.

40

@MrTango sorry for the long winded response below.
TL;DR
My current workflow leans heavily on CI/CD and I want to keep that; I need to look at themesitesetup again to see if I can get the jbot like benefits; I'm looking into Volto, maybe for early 2021;

I will need to give themesitesetup a second look (though Python 3 is important!) I seem to recall having some hiccups with "jbot-ish" behaviour through the web (TTW). When I use Python packages, jbot is great but... my preferred workflow combines CI/CD with TTW theming and avoids Python packages.

Here's my TTW/CI workflow in a nutshell

  1. Develop on the filesystem but not with Python packages: In development, I mount my theme under resources/theme and launch a dockerized version of my site. This allows a themer to focus solely on theming.
    The command looks something like this
docker run -it -v $(pwd)/theme:/plone/instance/resources/theme -v $(pwd)/data/filestorage/Data.fs:/data/filestorage/Data.fs -v $(pwd)/data/blobstorage:/data/blobstorage -p 8080:8080  mycustomplonedockerimage fg

(The theme is a separate git repo but not a Python package)

  1. Automate deployment with Gitlab CI and plonetheme uploader: This process is manged using gitlab ci, so I automate less compiling and, if everything passes, it is automatically sent to a staging site using plonetheme uploader. Most customisation is achieved using themefragments.
    Here's a rule that injects a dynamic themefragment of sponsors into the theme
 <replace css:theme-children=".sponsor-holder">
    <include css:content=".sponsorform" href="../@@theme-fragment/sponsors" />
</replace>

We also take advantage of Plone's cache-busting capabilities by adding a ++unique++ string to the paths of static resources (strings like "++unique++5f0bcad318" are "injected" into our Diazo rules using a sed command based on the current git commit hash).
A rule that includes a static resource with a unique url might look like this

<before css:theme-children="#more">
     <script src="++theme++my.theme/++unique++5f0bcad318/js/custom.js" type="text/javascript">
     </script>
     
 </before>
  1. Gatekeeping of the production theme using git tagging: If we're satisfied with how it looks in staging, we create a git tag for the theme and this triggers a CI process that pushes the finished theme to production.

Benefits

  1. The themer can use their preferred IDE/text editors etc... to develop the theme.
  2. No need to restart the clients to push theme changes
  3. All deployed themes have a corresponding git commit hash. This means I can revert to an older version by redeploying a specific hash at anytime.
    image
    image1802×1050 239 KB
  4. Sane workflow for themers
  5. Themefragments driven so very little Diazo knowledge is required for day to day use, and zero XSLT.
  6. Deployment becomes a git push
    It also doesn't hurt that theme related changes get beautiful commit message like this...
    image
    image1394×1260 78.6 KB

As you can see from my current workflow, I'm okay with the resource registry going away. It will have no impact on the way I currently work.

Future planning
I've been tinkering with Volto but have not put it in production. I want to be confident about handing a similarly robust workflow to a themer. One benefit is that it reinforces the little React that I've done here and there. I see a sensible Volto approach emerging for me by early 2021. I will probably continue with classic Plone 6 for some projects.

3 Likes
41

if you shadow a volto file how much technical debt do you take on?
One thing I disliked about jbot is that to change one small part of a markup I have now to worry about all the code copied over and all the internal apis it uses potentially changing in the future. diazo rules had its own debt in the form of when the underlying content (barceloneta html) changed, but that always seemed more stable.
Does a shadowed volto component depend on the react state, other imports of other components as well as the restapi? so any of those change in a future release do I have to fix my code in order to get back the small html rearrangement I wanted?
This is a genuine question. I'm sure the authors have considered this issue of what it takes to keep a theme up to date with customisations where the end html is very different from default volto. And if its not solved now then hopefully it will be soon in the future.

1 Like