Themefragments / Mosaic demo

Plone Support Customizing Plone
1

I made a small themefragments demo, a bit 'messy', but maybe useful for someone.

There is a typo, the syntax should be

${request/form/fieldname|None}

Note: there is no need for the Dexterity Content type, I just use it as a UI to 'construct the fields'

2

@espenm Also normal tile data access “view/data/fieldname” should work with current themefragment version.

3

This is cool... esp the schema based settings panel but...

  1. Why can't we use pure python as well? We don't want to resort to embedding complex logic in TAL.
  2. Why do we need to resort to using DX to store config data? It's not the right solution for this. Content is content. Just because its easy to create DX types, doesn't mean we should treat it as a DB. There is a need for a third type of data store between the config registry and content types.

These are two things that rapido tried to solve. It would be great to have a more unified solution @ebrehault @datakurre @smcmahon pretty please? :slight_smile: With steves new soltuion we have something else that allows code but only for views stuck on content types so it doesn't help when you want more global customisations.
Is there going to be an open space on the unified TTW customisation killer?

4

I believe that both 1. and 2. are misunderstandings. Theme fragments supports accompanying RestrictedPython modules for tiles (just like for fragments/views), and data is stored just the same as with normal tile. DX editor is probably just used for creating those schemas in the first place.

So, each tile can be made of three tiles: foobar.xml (schema), foobar.pt (view) and foobar.py (“module” with def something(self) -view methods (without class wrapper).

It’s obvious that easy to use editor is missing, but that’s probably because so are the resources to do it :wink:

5

Ah cool. Thats great.

yes I completely misunderstood the usecase. So really it's because XML sucks. So the alternative is either support YAML schema definition (con: yet another format), or support the schema editor embedded in the theme editor (con: more work as you suggested).

I guess if there is a need to save data somewhere that isn't content or config then we can just encourage the use of souper as rapido users without in being built in.

So then I guess themefragments can pretty much do everything rapido can do.

So next is why the need for ambidextrous? Can't you create a view for a DX type using themefragments? (without using mosaic). The reason I ask is because its confusing and/or frustrating for the user to have two similar solutions that get used in overlapping use cases. Documentation is easier, support is easier, the user cognitive overhead is lower. Everyone is happier with one TTW solution to rule them all right?

Also, can you create content rule actions using themefragments?

6

Is the schemaeditor a pattern? What if the theme editor used a plugin system that mapped file extension to pattern to load a given editor for a given file type? @datakurre. the user can choose to use text editing or X associated pattern to edit the file.

7

True: What I wanted to show is that it is possible to do a lot , with no need to 'learn anything'. If someone wants to make a theme, this should be very easy (for a beginner), no need to learn diazo, yams etc.

I know that this approach is not 'perfect', but I find it worse that to do something like this without themefragments for many looks so complicated that they choose another CMS.

8

I believe this being easier, because most of the code exists already for DX editor, it’s “just” requires all the glue code.

Themefragments can be used as default DX type views or using good old layout attribute. Populating layout menu would require dirty global utility override I did not want to do.

Ambidexterity has nice control panel and support for defining validators.

Personally I view both themefragments and ambidexterity as temporary add-ons before we manage to build plone.app.addons as more official and theming independent “instant add on” / “eggless” feature.

9

This ugly hack right? :slight_smile:

collective.listingviews/src/collective/listingviews/browser/views/controlpanel.py at da2b40a8b5ae54854cf7582542fb23bc01b28c02 · collective/collective.listingviews · GitHub

Let's start tomorrow! Combine forces and save the planet!

![quote="datakurre, post:8, topic:5027"]
Ambidexterity has nice control panel
[/quote]

So first decision is it in the theme or not. Nice control panel its stored somewhere else. Which means one more install/import/export story :frowning:

Validators often need settings, similar to tiles. ie "number in range" needs a range. I've implemented a cool macro system in plomino that works that way. Themefragments has a way to create a tile with settings. Generalise that idea. If you had the view with no template, and just the python that returned a value, then you could return true or false. Then you just need a way to register a themefragments view as a validator for certain tile types.

1 Like