Re: What I'd like to see gsoc achieve: plone distributions

> On 2 Apr 2015, at 7:20 pm, Asko Soukka <[email protected]> wrote:
> 
>> Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> kirjoitti 2.4.2015 kello 13.38:
>>> Context portlet configuration (with inheritance and blocking) is still something, which cannot be fully solved with Diazo. Even blocks / deco / mosaic is still lacking missing that.
>> 
>> Not sure what you mean. I thought you we were just talking about legacy portlets which include ZPT in them?
> 
> I mean that legacy portlet is currently the only existing and working way to implement new portlets TTW, and portal_skins/custom is the only reasonable place for their ZPT (because portal root would be even worse).

Ah ok. So I didn't misunderstand you.
I think perhaps there is over concern for backwards compatibility.
The end goal here is a environment that is easy to understand, play with and build real sites. Dragging in old ZMI stuff that everyone agrees is should be replaced I think just muddies the waters. Instead your effort into replacing python scripts with something inside the theme editor is awesome. It just needs to make useful for everything.

I know the next bit is long but bare with me and excuse my inability to explain these things more succinctly. 

As I stated there are other ways to achieve new portlets without legacy portlets.
We currently use listingviews which allows you to create new portlet types that bring in data from the database without knowing python or perhaps knowing a little TAL. It works now and we use it production for this purpose.
Unfortunately it stores its data in the registry rather than the theme.

Instead I'd like to replace it with the concept of views/fragments inside a theme that can come from two sources

- build them using python or TAL (hopefully not compulsory for both) - ie fragments (btw this is a terrible name and should change to just views or similar).
- build them using configuration/UI

We already have a system in place to create html fragments via configuration. It's called tiles but it's only used currently by the content editor not the themer. I propose it be allowed to be used by the themer as well.

For example lets say the themer wants to hard code a listing of news articles into the footer of a site (not very flexible for the editor but on some sites thats a good thing). Now they could create a ZPT fragment with a catalog query in it but then they have to learn ZPT and catalog api. What if instead they can create a tile instance inside the theme perhaps called mynewslisting.tile and fileview replaced by the tile UI. It lets them select the fields they want to list and the types they want to show and some basic formatters for the data. Internally its saved as json so export as zip still works.

Then the themer can just include it where they want in their theme using <replace href=...>. They can even transform the plain html it produces to something much nicer using diazo. No new strange languages or api learnt. Brand new themer knows just html, css and learns diazo in a day and they are creating complex sites. This is a big win for site building.

Now lets say they want to give the editor control where to add this view as a new portlet type (or tile type). For this I propose the concept of editor styles. We currently have the ability for a theme to give styles a name and let a editor pick them from a dropdown in tinymce. Plugins like portletstyles extends this to portlet types. Plugins like listingviews further extend that to adding in items in the displaymenu on content items (and portlets). 
Why not let all of those be defined in a single place in the manifest of a theme. A list of named styles or signals that form the link between what the editor would like to insert, and what the themer chooses to define them as. These could equally be ZPT or python views. Each style should have not just a name but a description and images.

So thats how I propose you have a new portlet type in this brave new world. All the code in one place and one method to get your content into a themed site (diazo). Things like viewlets can just fade away or be used internally for plone core development.


> 
> 
>>>>> I did an experimental branch, where you can define restricted python view methods for fragment views:
>>>>> 
>>>>> https://github.com/collective/collective.themefragments/commit/75c194b26a5dd9a3827c2d43876042fb3cd860c2
>>>> 
>>>> Can you call python directly from diazo?
>>> 
>>> I hope not. Why would you want to?
>> 
>> Let's say I want to do
>> 
>> <replace content=".lastupdated" href="@@lastupdatedview" />
> 
> Injecting plain text strings felt a rare special case for me, but of course, it could be made to work similarly to ZPT-fragements (@@theme-fragments/foobar now, maybe @@ttw/foobar later, if Eric agrees with the themefragments implementation).
> 
>> I think if we could get it as close to a view as possible it would make things much less confusing for a user. Having one way to do things TTW and another on the FS is just painful all round.
> 
> I'm not convinced yet. TTW is different environment and has different audience than FS. I'm not trying to convert FS-developers to TTW or otherway around. Forcing class + method -definitions in TTW adds mandatory boilerplate and two indenting levels before your the actual code. I cannot see it making TTW any more popular.
> 
> Also, I'd prefer to stay within the limits of restricted python (no importing [or need to remember where to import from] BrowserView).

well maybe you have a point. But I'd prefer we minimise the gap as much as possible. We can always going to have to deal with the annoying aspect that suddenly they will want to do more, want to convert it to a FS and then find they have to rewrite it all. It would be great to avoid that. It would also be great to reduce the documentation burden of having to say - you could do using X or you could do it using Y, if you want to do Z you have to use method X etc etc.

> 
> Instead, I think, I should fix the current implementation to provide all the same script locals as legacy PythonScripts (in addition to the currently provided "self", when called through ZPT-fragment view).

There is entirely no need to provide support for legacy pythonscripts. Magical params etc and imports is a bad idea IMO. Keeping it as close to python is better I think.


> 
> Regards,
> Asko


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/