[Framework-Team] Middleware render on Plone 5

Ramon Navarro Bosch ramon.nb at gmail.com
Tue Oct 8 20:38:08 UTC 2013

I've been sprinting today on the middleware rendering subject and this are
my points to be discussed :

* Without direct access (with diazo) to Plone we will not be able to access
@@manage-viewlets so we will need some control panel that decides which
viewlet should be rendered on the middleware for diazo ?

* The main goal I'm looking for is reducing the amount of things that are
beeing rendered on plone before diazo. So my idea is to implement a
IMainTemplate view that renders the main template depending on the viewlet
managers that are active. Also in case it's a browser request from toolbar
( we can mark with some interface ) render only the content part with some
possible viewlets managers before or after. Toolbar is only rendering the
content of the edit page and doesn't make any sense to render all the page
for this requests.

* So we render the viewlets that have been said to be rendered, the view of
the content and the portlets ( we could integrate plone_layout and plone
view on this main_template view ). The question is how we show it:

* We need to find a a way that it's easy for themeeditor to map the content
to the diazo theme. Maybe a list of elements (viewlets/portels/contents)
instead of seeing the actual sunburst view.

* We need to discard XML for the user content as they can write non valid
XML and we need to render the view of the content with the custom browser

* We need to use the same id's we have now on the main_template to provide
BBB on diazo themes ?

* What about js registry and css registry ? we need to render the bunch of
js/css that are needed on addons and the one's that are conditionals
(logged in and aren't not on toolbar)

I'm thinking on small steps that are affortable to provide a better "diazo
only" concept on Plone 5.

We did some tests, creating a main_template-remove on Products.CMFPlone and
did some performance tests having a bit better performance.

If somebody knows some work done on the same direction, or have some time,
I'll try to sprint on it tomorrow also so I can write a PLIP.


2013/10/2 Johannes Raggam <dev at programmatic.pro>

> On Die, 2013-10-01 at 15:58 +0100, Martin Aspeli wrote:
> > On 1 October 2013 14:03, Ramon Navarro Bosch <ramon.nb at gmail.com>
> wrote:
> >> Since we are moving to Diazo I have the bad feeling that rendering
> twice the page is a waste of energy and a possible missunderstanding for
> integrators / developers ( we will have the frontend, the backend of
> widgets, the native rendering ... )
> >> During these days in Brazil, we've been discussing if it's possible
> to change the main_template to export the structure of plone instead of
> a rendered page, different sections with the viewlets, with the
> portlets, the content, .... and on diazo rules it would be much easier
> to define the rules. As right now is the moment to discuss about this
> subject(diazo theme is really in early step and plone5 is a possible
> target to change this), my idea is to talk about it today at FWT meeting
> if it's ok with you.
> > So to check my understanding: you are saying main_template exposes
> something very simple, e.g. a pile of divs with sensible ids, and then
> Diazo makes it visually appealing?
> > If so, that makes sense to me, at least once we have good "out of the
> box" Diazo themes.
> What if we expose each of these building blocks via HTTP and let diazo
> fetch them via the href attribute?
> This way we can also provide alternative dynamic user interfaces, where
> we fetch the contents for a page via Javascript AJAX calls.
> Johannes
> --
> programmatic  web development
> di(fh) johannes raggam / thet
> python plone zope development
> mail: office at programmatic.pro
> web:  http://programmatic.pro
>       http://bluedynamics.com

Ramon a.k.a bloodbare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20131008/070c2f4f/attachment.html>

More information about the Framework-Team mailing list