Is Diazo a deadend? What do we do?

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.

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

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.

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:

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

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

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

@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

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

(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

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:

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

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

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.

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

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

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

Hey Dylan!

A very interesting question! We didn't find much of trouble with it, since the components are well differentiated. So if you override the Breadcrumbs component, then you have the logic and the presentation both shadowed, so the parent component that "calls" it, will call a valid full working version of the component, and it will work. If at some point Volto updates the Breadcrumbs component and introduces a new feature, we take care it's not breaking and complies with the existing API (eg. actions and reducers) so the new and the shadowed component would work both although the shadowed component won't have the new feature, for sure.

Also, experience tells that you tend to provide and write your own components (eg. footer) then it becomes more than an override, it becomes a "fill-slot" where you drop in any component you want. The component nature has an interesting duality from the "overriding just a template" in the JBOT approach. It's far more similar in the way of using a layer to override a full Zope view where you override the logic and the template, than the raw JBOT concept.

We take close care that the internal API (actions and reducers) do not change, and if a change is required, then we issue a major version and document it properly.

We are aware that we need to split down some components, that with time grew big, and try to separate logic from presentation so you could only shadow the presentation part, if required. That would improve the developer experience for sure, although might imply a breaking change on its own.

We are also aware that we need to introduce insertion points (in a viewlet manager fashion) that would make not required the forced override of key components (App, View etc). They are already in the roadmap.

"Implementations may change over time, the good concepts and values remains"

3 Likes

I can see that its one step better than jbot in that the api a component uses is more well defined. Plone never had a well defined api so once you are in a jbot template you are fiddling around with whatever the view methods were.

But the technical debt issue is still more complex because a theme is about a centrally managed policy on how something looks that can affect many different things across the site or page.
Consider that I want to change all the Divs in the header or fiedsets, or add a the class "djays-theme" to all LI on the page. Traditional plone or jbot this was a nightmare. I had to override dozens or more templates to get the final html I wanted. Even if the presentation of a component is separated having all these shadowed presentation components to implement some small global changes doesn't seem like a good solution either.
Is there some react or volto solution for these kind of "theme" changes?

Is this the documentation to use whatever CSS framework I want in Volto?

SemanticUI's last commit was on 2018-10-21, and there appears to be no roadmap for future development from the author.

There's an active community fork here: GitHub - fomantic/Fomantic-UI: Fomantic-UI is a community fork of Semantic-UI

I've even played with replacing semantic-ui in Volto with fomantic, it's definitely doable, if needed. CSS frameworks aside, for Volto the React components are more important, and those are actively maintained and developed: Releases · Semantic-Org/Semantic-UI-React · GitHub

1 Like