Plomino future

[ebrehault]

Renaming: instead of releasing Plomino 2, we could rename it (and pick a better name, more meaningful). Dylan and I talked about Rapido dureing the conf sprint. Then I thought about Velocity. It is opened.

Plone version support: 4.3 and 5

Architecture:

• use plone.api to access Plone features
• use souper for storage (plus a folder to manage attached files)
• UI based on mockup/patterns (and not jqueryui anymore)
• content-types (db, forms, fields, views, etc.) based on Dexterity
• JSON or YAML import/export (instead of XML)

We would propose a side-product to enable importing an old design (+old docs) as XML.

Any thought ?

[jean]

Velocity: less google-friendly than Plomino or Rapido. Not as bad as Windows or Surface ;-)

[jean]

For export I would strongly favour something that's friendly to edit on the filesystem.

I think that's easier to manage in YAML than in JSON. YAML can be done in many different styles, and I think an editing-friendly approach is possible. I think a good approach would be a combination of references (i.e. YAML metadata that defines properties about a form but links to separate layout.html etc. files for longer content, instead of doing everything inline in long YAML docs) and good naming conventions (i.e. similar to the names in /scripts/), making clear the relation between YAML metadata and layout/formula files.

It's probably better to have one .py file per form, rather than many small ones per formula. That also makes it tempting for such a .py file to have a shared section that is global to all the formulas in that file.

(Neither /scripts/ nor export should use _ as delimiter though, it is a normal character in ids. The ~ character would probably work.)

[jean]

plone.api :+1:

souper :+1:, but I think there are wrinkles to work out. E.g. for rendering would this mean instantiating a PlominoDocument with info from the souper object so that Plone assumptions hold? Does souper open any interesting possibilities regarding references and querying?

E.g. this stuff looks intriguing (from node, used by souper):

node.behaviors.Adopt
    Plumbing part that provides adoption of children. See node.interfaces.IAdopt.
node.behaviors.NodeChildValidate
    Plumbing part for child node validation. See node.interfaces.INodeChildValidate.

mockup/patterns :+1:

Dexterity :+1:

[jean]

Maybe also worthwhile creating milestones and picking from these to assign to milestones: https://github.com/plomino/Plomino/issues?labels=feature&page=1&state=open https://github.com/plomino/Plomino/issues?labels=proposal&page=1&state=open

[fulv]

+1 +1 +1

It would be good to have a very immediate way to add external functionality to a Plomino db, sort of like a plugin system. I know it's possible, but it should be as easy as selecting a custom action adapter is in PloneFormGen now.

[ebrehault]

Yes I also like the custom action adapter idea. In the Plomino case, the idea would be to declare extra features that can be binded (through the web interface) to Plomino events (save, open, etc.).