Thanks for proving that there are alternative ways for comments these days
I agree about themefragments vs. rapido. Fragments is older, has less features and thanks to Rapido, there's no need to develop it further. (There will be some enhancements for Mosaic support, once Mosaic has better interface to generate tiles into its Insert-menu, but no more.)
On the other hand, sometimes Rapido has "too much" features and then fragments is still an option.
@datakurre nice summary of the approach. Fat themes is a nicer name than going eggless
I think you only touch on the benefit of creating quicker iterations. It's kind of hard to quantify but I can attest it makes the process of building sites more agile and more productive. You really have to try yourself to find out. I hope lots attend the TTW training at the ploneconf to see for themselves.
rapido: I wouldn't describe it as a successor to plomino, even though it was originally intended as that. It is actually more a successor to themefragments. It takes the idea of adding ZPT inside your theme and adds .py files that contain multiple python functions. These are similar view callables in pyramid. It is more pythonic than zope python scripts. In terms of using either diazo or tiles to insert it into your site, it works the same as themefragments.
If your usecase demands it, it comes with a simple field/form framework and the ability to store light records easily in a non DX/OO way. But you don't have to use that.
Is that a fair assessment @ebrehault?
c.listingviews and c.facets are the other tools we normally use in our fat themes. We find that the combination of c.faceted navigation + c.listingviews + DX often makes for quick turn around on customising search and listing pages for clients.
About gitresource. Right now I feel plonetheme-download next to plonetheme-upload and doing commits manually afterwards feels simpler and good enough. In theory, gitresource could add versioning features for theme editor, but that would require a lot of UI development (and making versioning control easy to use is always hard).
On Plone 5 collective.listingviews is not yet an option.
Mosaic is able to do what collective.listingviews does and feels far more flexible, so I consider it to be an acceptable replacement.
@datakurre I do think themefragments are slightly simpler with less moving parts but rapido has the following going for it:
Genuine TTW - It doesn't require a restart of Zope when a new block is created
Learn once - It presents a single, buildout free paradigm to learn (a novice can create a rating system by following a simple tutorial while a more experienced developer might be able to quickly integrate a third party shopping cart (see: https://makina-corpus.com/blog/metier/2016/paypal-tracking-with-rapido), a mailing list platform like mailchimp or a smart recommendation system)
The potential to grow a community around rapido - since it can be decoupled from Plone, rapido.pyramid or rapido.kotti seem like legitimate possibilities.
@pigeonflight Mosaic doesn’t solve most of what c.listingview does. e.g. it doesn’t let you customise listings. At the moment all you can do is pick from a list of baked in templates for different kind of listing views, ie pretty much the same as display views.
I’ve began exploring some ideas that could make mosaics work well for customisable listing view without the need for c.listingviews here https://github.com/plone/plone.app.mosaic/issues/239. It would be good to get some additional feedback on these ideas from someone like you who is used thinking about plone from an onboarding perspective.
@pigeonflight me? Yes, those two gifs were implemented with code as the code was simple. but to make them work fully would be harder and I'm not sure when I will have time for it. if I don't use code I use gomockingbird.
Error: ENOENT: no such file or directory, open 'package.json'
at Error (native)
at Object.fs.openSync (fs.js:549:18)
at Object.fs.readFileSync (fs.js:397:15)
at Object. (/usr/lib/node_modules/plonetheme-upload/index.js:15:26)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)
Maybe even set active site (while I'm working on a specific site then pulling always pulls from that site, pushing always updates that site)
I don't know if it is a design decision to make plonetheme-upload ONLY able to push themes, the name certainly suggests that. If you do add pulling, activating and listing as part of the feature set then you may need a new name...
plonetheme-cli plonethemer plonetheme-util
or if it becomes a universal bridge between TTW and filesystem then something like: plonebridge (which I "secretly" want to be the name of a Plone distribution ).