and please help us test Plone 5.2 on March 14, 2019 (this week): Plone 5.2 release testing day coming up, March 14, 2019 PY DAY
3 Likes
Flexible Behaviors might be slightly challenging...
Behaviors already depend heavily on schema caching even they are defined only per content type. So, instance behaviors should cost either in memory or in performance.
While I agree that tiles and behaviors have overlapping features, refactoring the current behavior machinery to work well with "multiple same behaviors per object" sounds even more crazy... 
Interested to hear more on how this is planned.
1 Like
@tisto @pbauer Can something we added to roadmap to explain how a lift and shift theming is supported? ie, take an existing site or a theme written in just html and css and whatever js and convert it into a plone theme. and also a description of what training time it would take to get someone to trained up to do that.
Forgive me if I misunderstood something but I've seen volto described as easy to theme but I can't see how. For all the talks at plone conf last year and from talking to those involved my understanding is volto still doesn't support a "lift and shift" theming experience. Creating a theme in volto seems to be a) take volto b) modifying using a lot of knowledge of volto css, html, components. ie you have to be an expert in volto to know "what to customise" no? To me this would be a backwards step. It's going back the old plone 3/4 (non-diazo) ways of doing things which was very expensive and time consuming.
I also have reservations about the removing tiles over behaviours. Behaviours is less flexible in that you can't add two behaviours of the same type. It's just subtyping so you can still get issues of conflicting fields in addition. Tiles solved similar problems to streamfields in wagtail but in a much better way.
Implementing fleixble behaviors with multiple instances of the same behavior is indeed challenging. There is no concept yet on how to achieve that but it will be discussed at the Beethoven-Sprint. It we can't find a good and performant solution for this we'll probably stick with tiles.
I like the idea though since it would move content (in this case values stored with objects) in the domain of the schema of the object.
1 Like
As Philip said, we are aware of that. Our plan is to invite the smartest people we have in the Plone community to Beethoven sprint and other sprints to see what we can do to simplify our stack. This is why you really have to come.
Most of the PLIPs for Plone 6 are kind of optional, we have fallbacks if we can't work that out. If the folderish root does not work, we already have a workaround for the root in Volto that we use today. If the folderish content types do not work well in "classic" Plone we can keep them simple (e.g. just make the page folderish or even have a fallback profile to keep the old way).
If we can't make the behavior/tiles simplification work, we can just stick to what we have today.
That's the good thing of having Volto in production. We had to find solutions for the most common problems already.
Keep in mind that this is just a roadmap. Each individual PLIP has to go through the Framework team and it will be reviewed individually. We are also still looking for champions for some of the PLIPs in case there are people willing to help.
3 Likes
I gave a three days corporate training a few weeks ago on Volto. The participants had some experience with HTML/CSS and no JS experience whatsoever. They were beginners with no programming experience.
We spend one day teaching them basic HTML/CSS, one day LESS and Semantic UI. We were a bit slower than expected, so at the end of day three, we only had two hours left to build a Volto theme.
Within two hours, all participants were able to build a Volto theme with just basic HTML/CSS/LESS/Semantic UI knowledge. No need to explain them what Plone is or how Plone works. No need to understand JavaScript.
This is the great thing about Volto. We will make Plone theming a lot easier for everybody. We use standard web technology in Volto. You can theme Volto by amending a few LESS variables even if you do not know HTML/CSS.
At some point you will have to learn JSX and some basic JavaScript. Though, the only thing you need to do is to grab an existing template and drop it into a folder of your Volto theme. We use a JBOT-like approach in Volto.
Here is how you create a new Volto app/theme (if you have npm and yarn installed):
npm install -g @plone/create-volto-app create-volto-app myvoltoapp cd myvoltoapp yarn start
Fire up the backend with:
docker run --rm -it -p 8080:8080 kitconcept/plone.restapi:latest
Then you can start grabbing components from Volto and override them. We will make that even easier and document everything properly. Bear with us.
You definitely do not have to be an expert on Volto. If you want to be an expert, become an expert on React. Volto uses what is considered best practice in the React community. There are a bazillion tutorials, videos, books, etc. on React. Just grab them.
Same is true for developers. Companies always have problems finding experienced Plone developers. With Volto you can just look for experienced React developers.
Regarding tiles/behaviors: as said, we know it is complex. We have to discuss it and see if we can simplify things. This is an optional cleanup, not a requirement for Volto.
4 Likes
This could be a starting point:
This isn't solving the multiple instances of the same behavior nor caching, though.
2 Likes
I agree it makes sense to behaviors and tiles in terms of schema definition, serialization and storage. Registration and lookup might need new ideas to not complicate the current behavior framework further. I could "easily" think of a new behavior managing tiles through behavior framework... 
@pbauer Were "instance behaviors" added to the roadmap only to make "tiles => behaviors" possible or was there separate push for that? (Just to make sure that they are considered as separate issues.)
All valid points from the frontend prospective. Growing Plone or at least stabilizing the current Plone market because of the separation of backend and frontend in order to make it approachable for the frondend devs is perhaps a wild claim or wishful thinking. None of us can predict the future. The question is more or less how the existing Plone developers can or want support Plone in future with a mandatory React frontend (not in Plone 6 but perhaps in Plone 7). Personal opinion: React is not for me. Two options: implement my own stuff in my own favorite JS framework, work with React developers on frontends or leaving the Plone market and or migrating Plone customers to other platforms in the long run. Really no offense to Volto, your work or anyone working in this area but 95% of our customers will also be happy with server-side rendered HTML using "traditional" technology. This worked for two decades and will continue to work for another two decades. Nobody knows if React is still the thing at the time of Plone 7. React/Volto/Frontend are in my business experience not major selling points that would allow us to maintain or even grow the Plone business.
3 Likes
To see this other way: Volto takes all the pressure for "bells and whistles UX" and the traditional Plone UI can focus on its strengths. Maybe even rollback some Plone 5 solutions when it makes sense.
The developer approachability of React and the JavaScript toolchain is neither a wild guess nor wishful thinking in my experience. This is what we encounter every single day at kitconcept. We train new developers, interns, and clients on a daily basis. We host React sprints, barcamps, and meetups, where we get lots of feedback from people with different backgrounds. From that experience I can tell that it is far easier to train a developer on React than on Plone.
Modern JavaScript takes over web development, this is just a reality in my humble opinion. All other open source CMS projects are either already moving or at least evaluating to move to a modern JS stack.
We can ignore this of course. Though, what is the alternative? Stick to Python-based server-side rendering and move in the opposite direction of everybody else? Maintain our own JS stack with 3-5 devs and compete with frameworks that have 10k devs? Stick with the outdated JS stack of Mockup?
We can start to mix in React components, modernize Mockup, etc. Though, where are the developers that are willing to work on this? We asked around to find people that are willing to work on this. We offered to factor out Volto components to be integrated into classic Plone. Though, the truth is I do not know a single developer who tasted a full-fledged modern JS solution and wants to go back to Python-based rendering or mix Python with React.
Just to be 100% clear: The current roadmap does not say that we will deprecated the classic Plone UI. It will still be around as long as people want to use it. You can continue to use Plone 6 the way you use Plone 5.2.
This planned roadmap does not take anything away from anybody. You can use classic Plone, you can use Angular SDK, Vue, whatever you like. As always, we try to make everybody happy.
Volto is something that you can use or something that you can ignore if you want.
The React stack has proven to be very stable and mature in the last years. They rewrote the thing from the scratch from React 15 to 16. We upgraded Volto in half a day. They kept their router implementation stable over years, when Angular replaced their router 4 times from alpha to rc. This is all very impressive if you dare to look at it.
I'd personally rather bet on the future and maturity of React than on the future of Plone or Python in web development. Though, of course nobody can predict the future.
Volto is a major selling point in my experience. I wouldn't know how to sell my clients an expensive Python 3 upgrade without a real gain like Volto. With Python 3 and Volto I can provide our clients with a future proof, stable, mature, and secure backend and a future proof and modern frontend.
This is one of the great stories about the Plone community. Two groups of developers worked their asses off on unrelated areas (Python 3, Modern JS) and with Plone 6 those efforts come together to ship a mature, stable and future proof stack.
4 Likes
Maybe it helps to think of Volto/React as a way to do modern Plone theming. You keep everything that makes Plone great and combine that with the current de-facto best practices in web technology.
I have some doubts also about plugins.
How we are supposed to develop plugins for Plone/Volto?
I mean: in Plone we have everything in one single package (content-types, logic, permissions, layout, views, control panels, tiles) and installing it, we provide a complete new functionality to Plone out of the box.
If Volto become the official frontend from Plone 6 this means that we need to split it into two products? One for the backend (content-types, logic, wf, maybe some new restapi route/serializer/deserializer) and one for the presentation (npm package with some react components)?
I know that i've already asked this question before, but maybe in the meantime you've found a solution or a common way to do it 
3 Likes
I'm fine with Plone going completely headless and not providing a default human facing side out of the box.
Bottom line is that we would have to come up with a unified format for frontend and backend code and wrap that into a releasable format. This would also mean that you can't upgrade one without the other.
Take collective.solr for instance. We ship it with a React view to replace the Plone search form. This means that if you upgrade the c.solr backend you also have to update the frontend. Though, you might be on a different React version there. You might also choose to not use React at all or build a complete custom frontend for your application.
We gain a lot of flexibility by separating the frontend from the backend and the REST API is the right level ob abstraction IMHO. With the experience we gained from c.solr and other plugins, I sincerely believe that we should value that separation of concerns and keep it.
It is fine with me to release a c.solr backend that provides a REST API endpoint and an additional npm package for the frontend. The truth is that most likely you don't even need to release a frontend package because there is already lots of them.
Another example. We build a fancy calendar for a client that asked us for a traditional Plone 5 site. We shipped a modern React-based calendar as a view:
We could release that calendar view as an npm package. Though, I don't think it makes much sense. We use the AirBnB datepicker and some other React components. In the end the calendar just assembles and configures existing React libraries and packages. The backend is just the standard p.a.event type with some additional fields exposed via plone.restapi.
Say we would want to release that. It makes a lot of sense to release this separately. Maybe someone wants to add custom event fields. Maybe someone wants to use a different calendar view, maybe even Vue or Angular instead.
If we would release frontend and backend all together, we would limit those options and tightly bind the two. Frontend will always evolve faster than the backend. Therefore we should treat them separately.
Will that make the release process more complex? Sure it will. Though, with modern CI and tools like zest.releaser or release-it doing releases is a no-brainer. Therefore I think we can easily live with the overhead when doing releases when we gain lots of flexibility.
We thought about this a lot and had lots of discussions. Though, I really do not see any sane way how we could bring Python and JavaScript together, without inventing a frankenstein-like monster that will die a painful and foreseeable dead in the future.
So, yes. You will have to develop a frontend and a backend implementation for your add-on. Though, this is a good thing! It will prevent us from inventing another TTW bundler that promises something that we can never deliver in a sane way. You will have tools like bobtemplates.plone, create-plone-app, etc. that helps you along the way like they do today.
Technically I fully agree. I would be fine with shipping Plone completely headless. We do not want to force people to use a specific frontend technology and everybody should be free to choose. This is the whole idea behind plone.restapi.
From a non-technical and marketing perspective, Plone always has been an out-of-the-box solution for websites and intranet. Even compared to other CMSes, we were able to provide a far better out-of-the-box experience than most of the systems out there. This made Plone stand out in the crowd and also define its market.
Therefore, my opinion is that we have to ship Plone with a default frontend. If we don't we would stop competing with Drupal, Wordpress, etc. and become an open source alternative to Contentful and friends. This would put Plone into a completely different market with different requirements and competitors. I wouldn't want to have this on our shoulders right now...
When we ship with Volto, we do not lose any flexibility and we do not force anyone to use it. Though, if we do not ship with Volto, we will lose our well known market and our most important target group.
We never said that and never questioned that.
1 Like
My two cents:
On Guillotina we does not have tiles, we have three global concepts on object modelling:
- Base resource object: a small pickable element that is a node on the tree
- Static behavior: a behavior that is applied on all instances of nodes
- Dynamic behavior: a behavior that is applied dynamic on a node of the tree
Then behaviors can be:
- Context behaviors: small behaviors where the information is stored on the node object
- Annotation behaviors: behaviors that are stored on separate annotation
Then at the field side we can scale more with:
- Dynamic fields: fields defined ttw that are indexed properly
- Bucket field: list or dict of elements that are stored grouped on annotations and liked to be able to go though them
- JSON field: a field with json schema validation.
- File dict field: a dict of files.
With this concepts in mind, our best aproach to allow the dynamic component model of Volto would be to have dynamic or static behavior with dynamic fields or a json field. Files and images on a file dict field. Conversations or any long list of object on dynamic field.
About the dynamic behavior implementation in our case we apply the marker on the object when its added and there is an specific API to see which ones are applied. Then based on annotation or context behavior they get stored on a annotation or on the main object itself.
Multiple instances of a dynamic behavior on a object is something that guillotina does not support right now but would be possible to implement it as a specific kind of dynamic behavior.
When I discussed the aproach of this thread at Tokio, the idea is that dynamic behaviors are usefull to define: I want attachments, I want discussion, I want page composition....
4 Likes
Probably something similar makes sense with Plone also: maybe not "multiple instances of the same behavior" a such, but a special behavior that can then manage storage for multiple behavior provided schemas. (I assume multiple instances of the same behavior only make sense for behaviors that mainly provide form fields).
Dynamic behaviors would probably be more expensive on Plone than on Guillotina, because of all related magic.
My use case for "dynamic behaviors" on Plone has been to "sub type" content on different branches of content tree of the same site.