[Framework-Team] Middleware render on Plone 5

Wed Oct 9 16:45:36 UTC 2013

We need to think about, what would be the profit for a standard intergrator
if there is a diazo theme?

You cannot derive from it like a normal skin, so a intergrator always needs
to start over, or we need a feature for this.

I think we need to make sure the default skin theme is strong, simple and
having all the features needed, the diazo theme only needs to copy header,
col-one, content, col-two and footer including all features from the theme.
This way if a intergrator creates a new viewlet, its automaticly copyed by
the diazo theme.

Second most, i like to use bootstrap in my themes, we need to make sure the
default diazo theme is so simple that moving out the css and replacing it
by bootstrap or any other default css framework it would work, the edit
logica is in the p.a.toolbar so we dont need to worry about that.

On Wed, Oct 9, 2013 at 6:24 PM, Ramon Navarro Bosch <ramon.nb at gmail.com>wrote:

>
>
>
> 2013/10/8 David Glick (Plone) <david.glick at plone.org>
>
>  On 10/8/13 1:38 PM, Ramon Navarro Bosch wrote:
>>
>> 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 ?
>>
>>
>> I guess you are asking how to disable some viewlets that are not used in
>> the theme, so that you can avoid the overhead of rendering them?
>>
>> We can disable diazo for the manage-viewlets page. But it may be better
>> to have a more conventional control panel where you can click a checkbox to
>> show/hide each viewlet.
>>
>>
>>
> That's my idea.
>
>
>>   * 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.
>>
>>
>> The current main_template already has the ajax_request flag to disable
>> rendering of most viewlet managers. Do we really need something new?
>>
>
> I know the ajax_request flag that hides most of the rendered viewlets,
> just trying to figure out a way that is customizable, enables calls from
> toolbar to get just content and nearby viewlets. If we move main_template
> to a browser page we have more options to do it in a clear way and easier
> to customize, no ?
>
> I don't know which is the status of the tiles project but creating a tile
> for content when we need the content by itself would be a step forward ?
>
> So aside to decide what is going to be rendered on plone I think that it's
> needed to provide and easy customizable way to decide what's going to be
> rendered on different scenarios (toolbar request, diazo request, .... ) so
> it's much more aproachable to create custom layouts for integrators.
>
>
>>
>>
>>  * 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 view.
>>
>>  * 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.
>>
>>  Ramon
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> Framework-Team mailing listFramework-Team at lists.plone.orghttps://lists.plone.org/mailman/listinfo/plone-framework-team
>>
>>
>>
>
>
> --
> Ramon a.k.a bloodbare
>
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-framework-team
>
>

-- 
-- 
Maarten Kling
http://fourdigits.nl/mensen/maarten-kling

Four Digits BV
http://www.fourdigits.nl
Jansbinnensingel 26, 6811 AL, Arnhem
tel: +31 (0)26 4422700 fax: +31 (0)84 2206117
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20131009/edf990db/attachment-0001.html>