For views and stuff, Tutorial — Ambidexterity 1.0 documentation looks interesting. Did anyone tried this?
For views and stuff, Tutorial — Ambidexterity 1.0 documentation
https://collectiveambidexterity.readthedocs.io/en/latest/tutorial.html
looks interesting. Did anyone tried this?
Yes - it solved some problems for me under Plone 5.0.x - it's a shame it
doesn't seem to have had much love. It seemed to me to complete
Dexterity's TTW story, for my modest needs at least.
I've been working with some "no code" stuff recently, and I keep
thinking that Dexterity + something like Ambidexterity could give Plone
a niche in that world.
Another under-loved but useful product is: -
1 Like
we use ambidexterity. We had to fix some bugs with it and there are some open PR's that we need to be merged. The main reason we use ambidexterity is the dexterity schema editor has no support for custom vocabularies and I think so other things it does.
In terms of creating a view GitHub - collective/collective.themefragments: Theme Fragments for Plone Themes we also use and just as powerful in that they let you write python to create a custom view. The difference is they can also do tiles or portlets or almost anything.
One other solution we use for custom views is GitHub - collective/collective.listingviews.
Less obvious but it does let you create a custom view that can be applied to different content types. The code has to single line TAL statements however 
But it's good in that it makes a quick no code or low code custom listing view for a collection portlet or collection or folder, or even a regular content type.
1 Like
I tried to make a 'customisable view' (GitHub - espenmn/medialog.dexterityview: A generic browserview for Plone dexterity content ) ages ago, but I have hardly used it myself (basically, I used it mostly for prototyping).
Anyway: if it should be of any interest to anyone, there is still a video at youtube. medialog dexterityview - YouTube
this is exactly right the audiences are different. Part of the problem is us in the core community have very little idea of the audience for the TTW/low code approach and if it exists or not or could exist if it was promoted right. But regardless without the support of the community it gets hidden and breaks and anyone arriving at the plone documentation will likely never realise what is and isn't possible. Plone isn't sold as a low code CMS and never will be because TTW doesn't scratch open source developers itches. Such is life.
1 Like
in the core community have very little idea of the audience
Oh, how I wish there was a way to know more of the audience of Plone. I feel that there's a lot of users/developers that we know nothing about, and we may not even know how to reach them or target their needs.
1 Like
I tried collective.ambidexterity but I preferred the power of collective.themefragments for making views and collective.taxonomy for creating vocabularies that are directly indexed in the catalogue and usable in faceted views.
collective.ambidexterity also allows you to add validators but I very rarely needed this feature in my TTW projects.
themefragments is not TTW... or they can bu customized via portal_view_customizations?
You can add a theme fragment to a folder called "fragments" in a custom theme using the "Theme Editor"
in the theming controlpanel (http://localhost:8080/Plone/@@theming-controlpanel).
It works in Plone 5.2.4/Python 3.7 with collective.themefragments 2.12 .
1 Like
yes collective.taxonomy is awesome, i added support for collective.collectionfilter and collection tabular view too recently.
themefragments are TTW by defintion, they could come with a theme (still possible via upload in Plone 6) or portal_skins as @sverbois stated.
Indeed, but i see a pattern here, it seems that the audience who uses these kind of things the most is actively contribute enough. Be it by hiring developers to work on features like this or working on it them self. Otherwise there would be more developent going in that direction.
Themefragments are 'awesome'. Combined with Mosaic they are better than the Gutenberg (Wordpress) editor (in my opinion). Fragments are easy to make and uses 'well know technology '. ( TAL / Python / XML ).
The 'weaknesses'
- They need to be in the theme (can not be added from an add-on)
- Only restricted Python
- Datagridfield fields needs to be defined elsewhere.
- Max size for JSON can be a problem
- There has been some unicode encoding problems when upgrading.
With Mosaic combined with theme fragments, I can make almost any view TTW.
We have, for example, site editors which are not tech guys (they even complain to tinymce and template inserting...), I don't think Mosaic + themefragments are for them.
@espenmn yes, the lack of possibility to create them programmatically (would solve add-on + unrestricted python) is a limitation of the Classic UI experience.
You're totally right. Sorry, I was thinking to fs themes, mea culpa.
Yeah, i used fragments for this too in the past, but in the future I'll probably go more for real tile's created by plonecli. It will be the same or less effort, but a bit more powerfull and reuseable. It's a shame that we have so little free Mosaic tiles out there. I hope we can improve this with plonecli support soon. For me doing this in the filesystem has more pros than cons. It just has to be as simple as customizing the templates, schema and Python logic.
That's really good to know, thanks - will go and investigate that.
some of these limitations are not true limitations but just not enough effort gone in (mainly due to not directly helping core developer needs).
For example we regularly add to GitHub - collective/collective.trustedimports: sandboxlib whitelists a number of functions for use in restrictedPython whenever we come across libraries we need in restricted python. Anyone can add to it.
Themefragments has rough edges like we can't seem to use related items widgets. These can be fixed.
Themefragments outside of the theme I'd guess you mean to seperate the two use cases of TTW tile type creation from TTW view/viewlet-ish creation. Because a themefragments that aren't tiles rely on diazo to determine where on the page they go, To keep that ability with themefragments outside a theme you need to replace that the mechanism to determine where they go with something else. or drop it completely? (which seems a shame)
I still really like the idea of everything being in the theme in one place even if the editing experience is more code like and therefore less non-developer friendly. Tiles come from a design that normally needs to consider how it looks not just what it contains so to me its right they should be bundled togeather.
Could you clarify what you mean by this? If I'm correct this was in response to @espenm 's list of weaknesses in the collective.themefragments which is not in the core Plone distribution.
If you want to to improve the situation/weaknesses and you have customers or your own organisations' developers use this add'on extensively, by alll means spend time on it to improve it and if there is functionality missing write and support (time/financially) PLIP's to improve the usefullnes of this add'on, get parts of it in the core distribution or otherwise.
I don't see what this has to do with core developers. @djay What is according to you a core developer?
You are right, I used the wrong term in that example. I should have have said any plone developer/integrator since some of the TTW capabilities were done as plugins.
But the point is still the same. The people who can make the code, aren't the users of TTW and the users of TTW aren't the ones who can make the code. And there isn't any kind of feedback mechanism inside Plone open source community to correct that. I've personally worked on many plugins to help the TTW story but without solid proof that a good TTW story makes more money for all of us, it really is just an uphill battle that is now lost.
I don't know any more than any one else, that the people who would use low code/no code in a CMS, if it was done right, are a large enough group in the CMS market to matter.
1 Like