I have been working with collective.easytemplate product which allows users to use template tags on various places on Plone site. Currently supporting
- Kupu
- Outgoing email actions (Content rules ones)
The users can place ${title}, ${object_url} and other template in the edit mode. These variables which are directly mapped from Archetypes fields when the content is viewed/sent. Also, one can register custom snippet generators like $list_folder_content.
I hope Easy Template to cover some more actions in the future. I have noted PloneFormGen and Singing & Dancing product authors that we could add some mixed in functionality together.
Currently Easy Template uses Cheetah template backend. Cheetah is not Zope security friendly and exposing templated actions should be allowed only to trusted members. I am not huge fan of Plone’s TAL template language which is based on XML attributes and thus suitable only be used in XML context – this language is aimed only for hardcore hackers and software designers and ordinary folk really cannot wrap their minds around it.
Because I am not sure which will be the chosen template backend in the future I chose to abstract the template engine layer away. I created collective.templateengines product. It is a bunch of Zope interfaces and utility functions to abstract away common template actions like
- Applying a template
- Adding a template context variables
- Registering custom template tags
Currently collective.templateengines supports Cheetah and Django templates.
So, dear audience, what do you think of all this? What template engine would you suggest which would be Kupu friendly – you can edit the template language in WYSIWYG editor? Do you see any other usages for collective.templateengines? Which other projects could adopt template engine abstraction layer?
I’m not sure I’m reading this correctly, but if you’re talking about writing templates through the web with Kupu, then I don’t think that’s a use case Plone really should cater for by default.
The only use case I think could make sense, would be simple variable substitutions. In this case, string.Template probably makes sense – I certainly wouldn’t invent a whole pagetemplate abstraction library.
However, I think a better solution would be to use HTML markers, e.g. . These would be transformed on page rendering to insert the appropriate values.
Martin
> writing templates through the web
It’s about using templates in Kupu.
I can definitely see some use cases (mainly involving PloneFormGen or S&D, as Mikko suggests) for doing simple variable substitutions in Kupu.
e.g. on a Thank You page, the user would like to write the page in Kupu but be able to stick in form variables.
Right, “string.Template“ is fast and simple and it could be used lazily, such that values would only be computed when requested.
You can use string.Template as a backend. But you still need to have a way to map context object to template variables.
I have found out that simple strings are not enough in real life. I wouldn’t have gone through to make this exercise just for fun.
If you’re talking about userland variable substitution a’la mailmerge in ms word, why not just simply write a new portal transform?