New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PLIP: Reuse code among portlets, tiles and views #1755

Open
rodfersou opened this Issue Sep 9, 2016 · 12 comments

Comments

Projects
None yet
5 participants
@rodfersou
Member

rodfersou commented Sep 9, 2016

Proposer : @rodfersou

Seconder : @hvelarde

Abstract

Move small applets in different layout machinery existent in Plone

Motivation

Some applets like portlet calendar are really complex, and there is no point to rewrite this code when need it in other places of Plone.

Assumptions

Define where the code should be centralized, and what is the better way to share code and template.

Proposal & Implementation

Need suggestions.

Deliverables

One place for code and templates, reused for portlets, tiles and views in a easy way.

Risks

Depend on how we are going to achieve this.

Participants

@rodfersou @hvelarde

We started with an implementation using mixins and macros, but it was pointed that this is not the better way to go plone/plone.app.event#243

@rodfersou rodfersou added this to the Future milestone Sep 9, 2016

@hvelarde hvelarde changed the title from PLIP: Reuse code between Portlets, Mosaic Tiles, Views and Cover Tiles to PLIP: Reuse code among portlets, tiles and views Sep 9, 2016

@hvelarde

This comment has been minimized.

Show comment
Hide comment
@hvelarde

hvelarde Sep 9, 2016

Member

we wanted to do that during the Mephisto Sprint but obviously that was not a good idea as developers were focused on other things.

@datakurre sugested to move the resulting code to plone.app.layout; @thet and @jensens didn't like the idea of mixins and suggested adapters as an option but we have no experience on that and need some code examples.

Member

hvelarde commented Sep 9, 2016

we wanted to do that during the Mephisto Sprint but obviously that was not a good idea as developers were focused on other things.

@datakurre sugested to move the resulting code to plone.app.layout; @thet and @jensens didn't like the idea of mixins and suggested adapters as an option but we have no experience on that and need some code examples.

@jensens

This comment has been minimized.

Show comment
Hide comment
@jensens

jensens Sep 9, 2016

Member

So we need a snippet for that which is code+template, has access to the context and request...

So just a view, right?

Then the view can be rendered in different scenarios such as portlet, tile, viewlet and so on by just looking it up and calling it in the template maybe like so:

<div tal:replace="structure: context/@@plone.snippets.calendar" />

This could be looked up and called in code too.

Just an idea, open for better/simpler solutions.

Member

jensens commented Sep 9, 2016

So we need a snippet for that which is code+template, has access to the context and request...

So just a view, right?

Then the view can be rendered in different scenarios such as portlet, tile, viewlet and so on by just looking it up and calling it in the template maybe like so:

<div tal:replace="structure: context/@@plone.snippets.calendar" />

This could be looked up and called in code too.

Just an idea, open for better/simpler solutions.

@jensens

This comment has been minimized.

Show comment
Hide comment
@jensens

jensens Sep 9, 2016

Member

Since parameter passing is needed it could be turned into traversal:

<div tal:replace="structure: context/@@plone.snippets.calendar/hash/1234567890/otherkey/othervalue" />

Also just an idea. This would work with parametrized JS as well

Member

jensens commented Sep 9, 2016

Since parameter passing is needed it could be turned into traversal:

<div tal:replace="structure: context/@@plone.snippets.calendar/hash/1234567890/otherkey/othervalue" />

Also just an idea. This would work with parametrized JS as well

@thet

This comment has been minimized.

Show comment
Hide comment
@thet

thet Sep 9, 2016

Member

I've done that like described by @jensens numerous times, except for passing parameters. But for parameters, you can also do:

<tal:init define="calendar_view nocall:context/@@plone.snippets.calendar">
    <div tal:replace="structure python:calendar_view.__call__(context, parameter_1)"/>

    <!-- somethign else... -->
    <div tal:define="items python:calendar_view.get_items(parameter_2='something')">
        <div tal:repeat="item items" tal:content="item/title"/>
    </div>

</tal:init>

just dummy code and also just an idea...

Member

thet commented Sep 9, 2016

I've done that like described by @jensens numerous times, except for passing parameters. But for parameters, you can also do:

<tal:init define="calendar_view nocall:context/@@plone.snippets.calendar">
    <div tal:replace="structure python:calendar_view.__call__(context, parameter_1)"/>

    <!-- somethign else... -->
    <div tal:define="items python:calendar_view.get_items(parameter_2='something')">
        <div tal:repeat="item items" tal:content="item/title"/>
    </div>

</tal:init>

just dummy code and also just an idea...

@jensens

This comment has been minimized.

Show comment
Hide comment
@jensens

jensens Sep 9, 2016

Member

<div tal:replace="structure python:calendar_view.__call__(context, parameter_1)"/>

I dont think this works like so. Anyway, the overall goal is to have a generic view-like thing which is in fact just a callable.

Member

jensens commented Sep 9, 2016

<div tal:replace="structure python:calendar_view.__call__(context, parameter_1)"/>

I dont think this works like so. Anyway, the overall goal is to have a generic view-like thing which is in fact just a callable.

@rodfersou

This comment has been minimized.

Show comment
Hide comment
@rodfersou

rodfersou Sep 9, 2016

Member

fine, I got the idea, thank you, and where is the right place to put then? I mean.. a place where in the future could be where to put every portlet / tile views

Member

rodfersou commented Sep 9, 2016

fine, I got the idea, thank you, and where is the right place to put then? I mean.. a place where in the future could be where to put every portlet / tile views

@gforcada

This comment has been minimized.

Show comment
Hide comment
@gforcada

gforcada Sep 9, 2016

Contributor

@thet no python: in templates pretty please :-) that has a high performance impact

Contributor

gforcada commented Sep 9, 2016

@thet no python: in templates pretty please :-) that has a high performance impact

@jensens

This comment has been minimized.

Show comment
Hide comment
@jensens

jensens Sep 10, 2016

Member

@gforcada, do you have measurements here? In restricted templates that may be true (i never profiled this with chameleon), but with chameleon and unrestricted templates (which we are talking about) from my experience tales expressions are slower than native python. This is true in pyramid as well btw, where python expressions are default.

Member

jensens commented Sep 10, 2016

@gforcada, do you have measurements here? In restricted templates that may be true (i never profiled this with chameleon), but with chameleon and unrestricted templates (which we are talking about) from my experience tales expressions are slower than native python. This is true in pyramid as well btw, where python expressions are default.

@gforcada

This comment has been minimized.

Show comment
Hide comment
@gforcada

gforcada Sep 11, 2016

Contributor

@jensens what are restricted/unrestricted templates? AFAIK any template has to go through the template engine (zope.tal, chameleon) and they are patched to go trough RestrictedPython, right? That's what I read about it, and since then moved as much logic as possible to python code(views) rather than on the templates

Contributor

gforcada commented Sep 11, 2016

@jensens what are restricted/unrestricted templates? AFAIK any template has to go through the template engine (zope.tal, chameleon) and they are patched to go trough RestrictedPython, right? That's what I read about it, and since then moved as much logic as possible to python code(views) rather than on the templates

@rodfersou

This comment has been minimized.

Show comment
Hide comment
@rodfersou

rodfersou Sep 12, 2016

Member

Hi everyone, I need your help to decide where the code should be placed, then I can create the view and move the code.

It would be nice if we can decide it today, since we have a customer waiting for this change.

@datakurre could you please share your thoughts about it?

Member

rodfersou commented Sep 12, 2016

Hi everyone, I need your help to decide where the code should be placed, then I can create the view and move the code.

It would be nice if we can decide it today, since we have a customer waiting for this change.

@datakurre could you please share your thoughts about it?

@jensens

This comment has been minimized.

Show comment
Hide comment
@jensens

jensens Sep 12, 2016

Member

@gforcada From my understanding and from a look at five.pt: No, they are not all restricted Python.

If you look at five.pt where all the magic happens, it makes a difference if your code lives in the zodb and is untrusted (zope2), or if it is trusted code on the file-system via zcml (called zope3).

https://github.com/zopefoundation/five.pt/blob/master/src/five/pt/engine.py#L57-L77
and
https://github.com/zopefoundation/five.pt/blob/master/src/five/pt/engine.py#L121-L123

This also explains why templates customized through the ZMI portal_view_customizations do often stop working and start raising unauthorized if they used untrusted Python features before.

So, in short

  • filesystem-templates = fast = python expressions are good, native python parsing, no extra parsing needed.
  • zodb templates = slow, it should not make a big difference compare to TALES, but I have no numbers here.
Member

jensens commented Sep 12, 2016

@gforcada From my understanding and from a look at five.pt: No, they are not all restricted Python.

If you look at five.pt where all the magic happens, it makes a difference if your code lives in the zodb and is untrusted (zope2), or if it is trusted code on the file-system via zcml (called zope3).

https://github.com/zopefoundation/five.pt/blob/master/src/five/pt/engine.py#L57-L77
and
https://github.com/zopefoundation/five.pt/blob/master/src/five/pt/engine.py#L121-L123

This also explains why templates customized through the ZMI portal_view_customizations do often stop working and start raising unauthorized if they used untrusted Python features before.

So, in short

  • filesystem-templates = fast = python expressions are good, native python parsing, no extra parsing needed.
  • zodb templates = slow, it should not make a big difference compare to TALES, but I have no numbers here.
@rodfersou

This comment has been minimized.

Show comment
Hide comment
@rodfersou

rodfersou Sep 13, 2016

Member

@jensens interesting

If I understand well the right place to create the calendar view is at plone.app.events package, and where can I put the rss tile code as a view?

Is plone.app.standardtiles a good place?

Member

rodfersou commented Sep 13, 2016

@jensens interesting

If I understand well the right place to create the calendar view is at plone.app.events package, and where can I put the rss tile code as a view?

Is plone.app.standardtiles a good place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment