Let there be TTW add-ons

@b4oshany I recall that you were planning scaffolding support and inline documentation in to theme editor. This app project is an example, why it would be nice, if those features would be generic enough to use configure and use with custom data also outside theme editor (possibly through file manager pattern configuration).

What you seem to be talking about is a fat theme right? Is there difference is that you can have multiple plugins installed at the same time? Do you have a couple of examples from existing plugins that can be replaced with this zip approach?
Also not sure why you want views when rapido already handles that. Rapido will also do first class tiles soon too.

I've used all the features above already in fat themes, but I want to decouple all this from themes to make them reusable (installable and ugradeable) separate from theme.

This approach allows installing and maintaining simple content types with custom views, permissions and workflows separate from theme TTW without buildout or restarts. An example of a site build with this technique is https://kielikeskus.jyu.fi/eoto/en/info. It's a complete app as a fat theme: custom content types, permissions, workflows, views, email notifications etc. Yet, it's hard to reuse because bundled with theme. Also all fatness in theme is exposed through ++theme++, which could be a security issue depending the contents.

About Rapido. AFAIK Rapido views do not support the default toolbar Display menu. Also Rapido expects trusted TTW admins (its Python scripts allow plone.api by default that allows escaping its sandbox; here I like boring tech – the current scripts supported by AccessControl). I don't want to depend on it myself. Yet, it should be easy to implement Rapido support for those, who want to use primarly it. Main issue is possible namespace conflicts (AFAIK there can be currently only one active rapido folder – the on in the default theme).

I like apps too. They also could be named "plugins" (a lot of systems referer to this kind of thing that way).

1 Like

I also think .ini is probably better.

1 Like

For wider audiences it seems to me both plugins and apps might be confusing / hard to differentiate from regular add-ons.

Thus I'd suggest something more explicit for newcomers, like one of:

  • TTW add-ons
  • Restricted add-ons
  • Light add-ons
  • Uploadable add-ons
  • ...?
1 Like

Yes, this is probably the most difficult decisions here. TTW, Restricted and Uploadable are very technical terms. Light underestimates the possibilities. Simple add-ons might be little better (indicating they are simple to create), but still underestimating.

  • Plug'n Play add-ons
  • Live add-ons
  • Instant add-ons
  • Scaffolds (they can be customized TTW)
  • Jet packs
There are only two hard things in Computer Science: 
cache invalidation and naming things.
-- Phil Karlton

(and the variation with '... and off-by-one-errors')

To borrow from gaming (admittedly also nerdy but maybe less so) I'd say

  • mods

but let's see if we can get some more suggestions in. It is indeed hard, and once done you're stuck with it...

1 Like

Loving that.

Thats easily fixed.

Not true. it has the same security model as other restricted python. It's the same tech. If plone.api is a security risk then its a bug that needs fixing in plone.api. Not much point having an api if it doesn't work in restrictedpython.

I think perhaps you should learn and use it before reinventing it.

zip addons or upload addons.

From the suggestions, I like:

  • Live add-ons
  • Plug'n'play addons
  • Mods (I think this is better than plugins/apps which will IMO really create trouble)

I agree TTW is too hermetic and that Light is too shy but Restricted, Uploadable and Zip Addons do not strike me as so bad either.

Another idea: Hotplug/Hotswapping add-ons, or something similar, which would go inline with Webpack's similar concept.

1 Like

I asked some non technical people today what they think would be better: no one understood what mods are. But everybody seem to know what apps are (we now have app stores, play stores, ...). So this seems to be very common and understandable. Also, everybody understood when I explained that add-ons are coming with the Plone installation and can be activated, and apps could be installed like any browser extension.

Btw, looking at the Chrome store they now have:

  • Extensions
  • Themes
  • Apps
  • Games

Thomas

1 Like

live add-ons gets my vote. I also like "Hot" add-ons but that might sound scary to some persons.

1 Like

If it's hard to choose a word, which means something in our context, what about something with less meaning

  • chords
  • pods
  • pearls
  • rocks
  • spots
  • specks
  • tapes

Plone currently has two very different security contexts: one trusted (without internal security checks because the security has been applied further upwards towards the user/request) and one "untrusted" (with explicit checks for each operation). One consequence thereof are the two sets of catalog methods ("normal" and "trusted").

With respect to this, one should ask what of these security contexts is targeted by plone.api and its functions. A function destined for the trusted context may be a risk in the untrusted context. Like for the catalog, it may be necessary to have two versions of a function - one for the trusted and one for the untrusted context.

It's really too hard to give something meaning unless you are really lucky or influential.
We are better to have something that is descriptive but still sounds smooth (otherwise it won't be used).
Apps is too overused and I think its a different idea from something that adds a feature. An app is generally an destination in itself.

I think the ideas are around "X add-on" which is saying its very similar to other kinds of addons that add features or modifications to the CMS but without a restart or redeployment. So hotswap addons or live addons. Or going forward you can forsee a install process where you pick it from some webstore and click install and its done.
So maybe just "web addons"?

I'm pretty sure that plone.api was designed and developed primarily the trusted context in mind. It's only used in TTW context by default in Rapido. Rapido's restricted Python scripts are different from default Plone "untrusted" Python scripts in that it does not use guarded getattr with RestrictedPython. In my understanding that is for convenience, because guarded getattr prevents access e.g. to Python datetime objects' functions (Zope DateTime has explicit support for AccessControl).

That said, I obviously want the TTW add-on story to fully work in "untrusted" context by default, but make it extensible so that Rapido could later support it.

No it used untrustedpython because it seemed that it would be more supported in the future and because it also works on pyramid. @ebrehault is now switch it back to using pythonscripts version of restrictedpython since this now seems like it will be supported into the future.
It was never about lowering the security.

It's a really bad idea to try and tell people they have to use two apis. If plone.api doesn't target untrusted users and the solution is to have multiple apis then we have created yet another obstacle to adoption. Is there any reason why plone.api can't be made to transparently be supported in untrusted code?

I agree, X add-on seems to be the safes bet. I liked also mods, but as @tmassman surveyed, it's probably too technical. apps might be oversell (although, it's also beyond meaningless).

So, how about "Instant add-ons". That should be both positive and describe their function pretty well. And like instant coffee works best with freshly boiled water, also "Instant add-ons" are best served with freshly installed Plone. (Of course, they work on any Plone, but are allowed to override settings.)

@datakurre hey, that's great!

  • +1 for apps. That's easy to remember and everyone knows what to expect from apps. Maybe plugins is also a good name :slight_smile:
  • better use plone namespace than collective. If this should be officially supported at one point, the plone namespace is better.
  • If there are no good reasons against plone.memoize, I'd perfer that because it's out main caching framework. It should also be easy to invalidate.
  • Regarding the directory structure:
    • What's the difference between public and resources? Can't those be combined by just using plone.resource directories?
    • Where should site and content layouts be placed?
    • I'm thinking about combining views and tiles, as tiles are a lot like views. Although I'm not sure and that's probably not a good idea.