enhanced collections views

classic Classic list List threaded Threaded
11 messages Options
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

enhanced collections views

Hi,

I'm looking for advise on how to get something like collective.listingviews into the plone core.

- Collections is a powerful tool that lets users choose what items they want to show.
- Page templates is a powerful tool that lets plone developers create new custom views for folders, collections and items
- Diazo is a powerful tool to for a themer with control panel access to change the layout of collections

Until now there hasn't been much in between. 
ie, if I'm not a plone developer but a themer or site administrator and I want to display more info about items in a collection, what can I do?
There is the table view for collections but to me it has always seemed a bit of a hack.

This is why we created collective.listingviews was created (In fact we went beyond collection views and made it so you can display a lot more info about on any content item in plone.) 
So far we've found it to be very useful and have ended up using it on 4-5 different sites. Since we find it so useful, we think this with some more work, or something very similar would be a useful core feature.

For example the following page was made just using eea.facetednavigation, collective.listingviews and plone.app.theming.





I realise this might not seem that useful to many of you because anyone on this list knows and loves ZPT. You might ask why do it in a more indirect and roundabout way?
The main reason is that we believe the learning curve is much lower and the chance of the user creating a view that breaks the site is less since less code is involved.
For some more UI love this could be easier and less error prone still. (note the custom expression above are an optional part).
The other reason is that separating the definition of the what attributes to list (listingview) vs how this should be laid out (diazo) allows for diazo patterns to be reused between different views and different sites (e.g. a sortable table layout). ZPT on the other hand combines presentation and attribute definition into the same file making reuse harder.


---
Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/pretaweb | linkedin.com/in/djay75




------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

Hi


On 20 May 2013 08:27, Dylan Jay <[hidden email]> wrote:
Hi,

I'm looking for advise on how to get something like collective.listingviews into the plone core.

It would be useful to articulate "why", i.e. why is it better for this to be in core than in an add-on? I wonder if c.listingviews is analogous to PloneFormGen: perhaps a "must have" add-on for a lot of sites, but not something necessarily appropriate for core (either because it is confusing to a casual end user, as opposed to the type of power-user [but non-developer] you describe, or because of concerns around maintainability and technology choice, or simply to allow more rapid innovation). That's a genuine question, though, not an attempted put-down.
 
- Collections is a powerful tool that lets users choose what items they want to show.
- Page templates is a powerful tool that lets plone developers create new custom views for folders, collections and items
- Diazo is a powerful tool to for a themer with control panel access to change the layout of collections

Until now there hasn't been much in between. 
ie, if I'm not a plone developer but a themer or site administrator and I want to display more info about items in a collection, what can I do?
There is the table view for collections but to me it has always seemed a bit of a hack.

This is why we created collective.listingviews was created (In fact we went beyond collection views and made it so you can display a lot more info about on any content item in plone.) 
So far we've found it to be very useful and have ended up using it on 4-5 different sites. Since we find it so useful, we think this with some more work, or something very similar would be a useful core feature.

For example the following page was made just using eea.facetednavigation, collective.listingviews and plone.app.theming.





I realise this might not seem that useful to many of you because anyone on this list knows and loves ZPT. You might ask why do it in a more indirect and roundabout way?
The main reason is that we believe the learning curve is much lower and the chance of the user creating a view that breaks the site is less since less code is involved.

One question: How do people not familiar with the internals of Plone figure out what to put in the 'TAL expression' boxes?
 
For some more UI love this could be easier and less error prone still. (note the custom expression above are an optional part).

I am a bit sceptical when people say things like "some more UI love" or "all that remains is some UI" as if that was the easy part. I think for this kind of thing to be part of making Plone more user friendly and not less, the UI needs to be pretty obvious. The model above is quite complex. I think it's great for the kind of non-developer power user you're targeting, but it may be scary to more traditional site administrators.
 
The other reason is that separating the definition of the what attributes to list (listingview) vs how this should be laid out (diazo) allows for diazo patterns to be reused between different views and different sites (e.g. a sortable table layout). ZPT on the other hand combines presentation and attribute definition into the same file making reuse harder.

Yes, I agree.

One thing that strikes me is that in plone.tiles/plone.app.tiles we have a means of building lightweight, embeddable "snippets" that can have optional forms-driven configuration. These can then be included in themes by href (if plone.app.blocks or at least one of its transform is enabled), or perhaps be pulled in automatically via a ZPT looking up some configuration (say, a viewlet looking for config stored in portal_registry).

I wonder if there's a way to extend the plone.app.theming theme editor and/or provide a control panel to allow admins to configure one or more tiles and embed them into a theme or assign them to a type's default view for incorporation via a Diazo rule.

For example:

 - Go to the list of "theme tiles"
 - Click "add tile"
 - Choose "custom listing" or something else
 - Configure (ideally, we should have a small number of common use cases in multiple tiles rather than a single uber-tile to do everything)
 - Save: stores a reference to the tile's URL in portal_registry (with parameters embedded in the query string)
 - A viewlet (e.g. below the footer) fetches all tiles applicable to the current page and renders them, each contained with a <div /> with a unique id that makes it easy to target in a theme
 - In a Diazo theme, you can pull the relevant stuff through

Some variants:

 - Choose a content item where the tile is going to be shown (as opposed to globally)
 - Allow the tile to be inherited by children if the content item is a folder (note: the big mistake we made with portlets is that they opt-out inherit rather than opt-in)

This has some advantages:

 - Tiles are lightweight and simple (portlets would be too awkward for this use case, I think)
 - Add-ons can add more tiles to be used like this
 - Configuration can be managed via registry.xml (especially for transient tiles, which 99% of tiles should be if we build them right)
 - plone.app.tiles has UI and hooks that can be used to manage tiles with only a small bit of integration required

I'm still not 100% convinced this wouldn't be better in an add-on than in the core - at least at first - but it feels like something worth exploring.

(Disclaimer: I've not spent a huge amount of time thinking about this, so there may be some fatal flaw in what I'm suggesting)

Martin

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views


On 20/05/2013, at 11:40 PM, Martin Aspeli <[hidden email]> wrote:

Hi


On 20 May 2013 08:27, Dylan Jay <[hidden email]> wrote:
Hi,

I'm looking for advise on how to get something like collective.listingviews into the plone core.

It would be useful to articulate "why", i.e. why is it better for this to be in core than in an add-on? I wonder if c.listingviews is analogous to PloneFormGen: perhaps a "must have" add-on for a lot of sites, but not something necessarily appropriate for core (either because it is confusing to a casual end user, as opposed to the type of power-user [but non-developer] you describe, or because of concerns around maintainability and technology choice, or simply to allow more rapid innovation). That's a genuine question, though, not an attempted put-down.

because it's tightly linked to theming and collections. You can create much better themes with something like listingviews.
Although I think a way to create forms in the core to replace PFG (based on dexterity schema editor) would be a good idea I think PFG doesn't have that many interactions with other components. 

 
- Collections is a powerful tool that lets users choose what items they want to show.
- Page templates is a powerful tool that lets plone developers create new custom views for folders, collections and items
- Diazo is a powerful tool to for a themer with control panel access to change the layout of collections

Until now there hasn't been much in between. 
ie, if I'm not a plone developer but a themer or site administrator and I want to display more info about items in a collection, what can I do?
There is the table view for collections but to me it has always seemed a bit of a hack.

This is why we created collective.listingviews was created (In fact we went beyond collection views and made it so you can display a lot more info about on any content item in plone.) 
So far we've found it to be very useful and have ended up using it on 4-5 different sites. Since we find it so useful, we think this with some more work, or something very similar would be a useful core feature.

For example the following page was made just using eea.facetednavigation, collective.listingviews and plone.app.theming.
 - http://mhcs.nswgov.pretacloud.com/publicationsandresources#b_start=0

<Screen Shot 2013-05-20 at 1.34.39 PM.png>


<Screen Shot 2013-05-20 at 5.19.29 PM.png><Screen Shot 2013-05-20 at 5.20.12 PM.png>


I realise this might not seem that useful to many of you because anyone on this list knows and loves ZPT. You might ask why do it in a more indirect and roundabout way?
The main reason is that we believe the learning curve is much lower and the chance of the user creating a view that breaks the site is less since less code is involved.

One question: How do people not familiar with the internals of Plone figure out what to put in the 'TAL expression' boxes?

good question. The custom fields is meant to be an advanced option. listing views is still very useful without using them.
It could be improved with some inline documentation or common api and by having many of the commonly used expressions preset for use in listing views (which we've already started doing)

 
For some more UI love this could be easier and less error prone still. (note the custom expression above are an optional part).

I am a bit sceptical when people say things like "some more UI love" or "all that remains is some UI" as if that was the easy part. I think for this kind of thing to be part of making 
Plone more user friendly and not less, the UI needs to be pretty obvious.

hence why I'm bringing it to this list.
I'm very open to how to improve it and know that anything in the core has very well thought out and easy to use and that isn't hard.

The model above is quite complex. I think it's great for the kind of non-developer power user you're targeting, but it may be scary to more traditional site administrators.

It's a themer tool. Since it requires daizo changes to make it look like you want it's tightly liked to your diazo theme. The themer creates a series of views which the content editors  can apply to their content.

 
The other reason is that separating the definition of the what attributes to list (listingview) vs how this should be laid out (diazo) allows for diazo patterns to be reused between different views and different sites (e.g. a sortable table layout). ZPT on the other hand combines presentation and attribute definition into the same file making reuse harder.

Yes, I agree.

One thing that strikes me is that in plone.tiles/plone.app.tiles we have a means of building lightweight, embeddable "snippets" that can have optional forms-driven configuration. These can then be included in themes by href (if plone.app.blocks or at least one of its transform is enabled), or perhaps be pulled in automatically via a ZPT looking up some configuration (say, a viewlet looking for config stored in portal_registry).

I wonder if there's a way to extend the plone.app.theming theme editor and/or provide a control panel to allow admins to configure one or more tiles and embed them into a theme or assign them to a type's default view for incorporation via a Diazo rule.

For example:

 - Go to the list of "theme tiles"
 - Click "add tile"
 - Choose "custom listing" or something else
 - Configure (ideally, we should have a small number of common use cases in multiple tiles rather than a single uber-tile to do everything)
 - Save: stores a reference to the tile's URL in portal_registry (with parameters embedded in the query string)
 - A viewlet (e.g. below the footer) fetches all tiles applicable to the current page and renders them, each contained with a <div /> with a unique id that makes it easy to target in a theme
 - In a Diazo theme, you can pull the relevant stuff through

Can you explain more what the integration with the theme editor does in the above? (there is already a listing tile that lets you pick a list template and listingviews will integrate with this).
Which problem are you trying to solve with what listing views already does? Is it that you don't want a "naked" listingview to ever be visible to an editor?



Some variants:

 - Choose a content item where the tile is going to be shown (as opposed to globally)
 - Allow the tile to be inherited by children if the content item is a folder (note: the big mistake we made with portlets is that they opt-out inherit rather than opt-in)

are you just talking about the part of deco which replaces portlets? or maybe there is a difference I'm missing.
Note that listingviews already works like this with portlets (since tiles and deco isn't there yet) and it works quiet well.
You create listingview template, pick a view and choose either to make it relative (uses current context) or pick a specific item to show attributes + contents of.
Make it trivial to the equivalent of a last published viewlet, or a news portlet that includes images, or a featured item portlet/time, or a carousel from a collection.
or for items (which I didn't show before)
but with deco it would more like portlets (except they'd be tiles).... and you'd just use the query building directly in the tile rather than point to a collection. Actually I should do the querybuilder part now in the existing listingview portlet since deco isn't coming anytime soon.


This has some advantages:

 - Tiles are lightweight and simple (portlets would be too awkward for this use case, I think)
 - Add-ons can add more tiles to be used like this
 - Configuration can be managed via registry.xml (especially for transient tiles, which 99% of tiles should be if we build them right)
 - plone.app.tiles has UI and hooks that can be used to manage tiles with only a small bit of integration required

I'm missing something about what your idea is I'm sure. It would be great to understand your idea more.


I'm still not 100% convinced this wouldn't be better in an add-on than in the core - at least at first - but it feels like something worth exploring.

(Disclaimer: I've not spent a huge amount of time thinking about this, so there may be some fatal flaw in what I'm suggesting)

Martin


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

Hi,

(Small request: can we avoid giant images to a mimum, please? The
horizontal width of my Gmail has gone haywire ;-)


On 20 May 2013 16:22, Dylan Jay <[hidden email]> wrote:

>
>
> On 20/05/2013, at 11:40 PM, Martin Aspeli <[hidden email]> wrote:
>
> Hi
>
>
> On 20 May 2013 08:27, Dylan Jay <[hidden email]> wrote:
> Hi,
>
> I'm looking for advise on how to get something like collective.listingviews into the plone core.
>
> It would be useful to articulate "why", i.e. why is it better for this to be in core than in an add-on? I wonder if c.listingviews is analogous to PloneFormGen: perhaps a "must have" add-on for a lot of sites, but not something necessarily appropriate for core (either because it is confusing to a casual end user, as opposed to the type of power-user [but non-developer] you describe, or because of concerns around maintainability and technology choice, or simply to allow more rapid innovation). That's a genuine question, though, not an attempted put-down.
>
>
> because it's tightly linked to theming and collections. You can create much better themes with something like listingviews.
> Although I think a way to create forms in the core to replace PFG (based on dexterity schema editor) would be a good idea I think PFG doesn't have that many interactions with other components.


I can buy that. It does mean the bar for usability and "future
proofing" is pretty high, though. Once something goes into core, it's
hard to take out.

>
>
>
> - Collections is a powerful tool that lets users choose what items they want to show.
> - Page templates is a powerful tool that lets plone developers create new custom views for folders, collections and items
> - Diazo is a powerful tool to for a themer with control panel access to change the layout of collections
>
> Until now there hasn't been much in between.
> ie, if I'm not a plone developer but a themer or site administrator and I want to display more info about items in a collection, what can I do?
> There is the table view for collections but to me it has always seemed a bit of a hack.
>
> This is why we created collective.listingviews was created (In fact we went beyond collection views and made it so you can display a lot more info about on any content item in plone.)
> So far we've found it to be very useful and have ended up using it on 4-5 different sites. Since we find it so useful, we think this with some more work, or something very similar would be a useful core feature.
>
> For example the following page was made just using eea.facetednavigation, collective.listingviews and plone.app.theming.
>  - http://mhcs.nswgov.pretacloud.com/publicationsandresources#b_start=0
>
> <Screen Shot 2013-05-20 at 1.34.39 PM.png>
>
>
> <Screen Shot 2013-05-20 at 5.19.29 PM.png><Screen Shot 2013-05-20 at 5.20.12 PM.png>
>
>
>
> I realise this might not seem that useful to many of you because anyone on this list knows and loves ZPT. You might ask why do it in a more indirect and roundabout way?
> The main reason is that we believe the learning curve is much lower and the chance of the user creating a view that breaks the site is less since less code is involved.
>
> One question: How do people not familiar with the internals of Plone figure out what to put in the 'TAL expression' boxes?
>
>
> good question. The custom fields is meant to be an advanced option. listing views is still very useful without using them.


So, to check that I understand: without this, it provides
UI-configurable views for folders, content items, portlets or
collections where the administrator can choose what gets rendered
(from schema or catalogue fields) and how (e.g. pagination)

>
> It could be improved with some inline documentation or common api and by having many of the commonly used expressions preset for use in listing views (which we've already started doing)
>

That's a good start, indeed.

>
> For some more UI love this could be easier and less error prone still. (note the custom expression above are an optional part).
>
> I am a bit sceptical when people say things like "some more UI love" or "all that remains is some UI" as if that was the easy part. I think for this kind of thing to be part of making
>
> Plone more user friendly and not less, the UI needs to be pretty obvious.
>
>
> hence why I'm bringing it to this list.
> I'm very open to how to improve it and know that anything in the core has very well thought out and easy to use and that isn't hard.
>
> The model above is quite complex. I think it's great for the kind of non-developer power user you're targeting, but it may be scary to more traditional site administrators.
>
>
> It's a themer tool. Since it requires daizo changes to make it look like you want it's tightly liked to your diazo theme. The themer creates a series of views which the content editors  can apply to their content.


I think that's quite powerful. It does, however, create a dependency
between a theme and things in content space (layout of folders, items,
collections; assignments of portlets; assignments of custom views).
This makes it somewhat harder to package and propagate themes (e.g.
from dev to test to production). It may be worth thinking about how we
solve this, probably by using the plugin points in plone.app.theming
and packaging settings in the theme manifest (there's infrastructure
for this already).

>
> The other reason is that separating the definition of the what attributes to list (listingview) vs how this should be laid out (diazo) allows for diazo patterns to be reused between different views and different sites (e.g. a sortable table layout). ZPT on the other hand combines presentation and attribute definition into the same file making reuse harder.
>
> Yes, I agree.
>
> One thing that strikes me is that in plone.tiles/plone.app.tiles we have a means of building lightweight, embeddable "snippets" that can have optional forms-driven configuration. These can then be included in themes by href (if plone.app.blocks or at least one of its transform is enabled), or perhaps be pulled in automatically via a ZPT looking up some configuration (say, a viewlet looking for config stored in portal_registry).
>
> I wonder if there's a way to extend the plone.app.theming theme editor and/or provide a control panel to allow admins to configure one or more tiles and embed them into a theme or assign them to a type's default view for incorporation via a Diazo rule.
>
> For example:
>
>  - Go to the list of "theme tiles"
>  - Click "add tile"
>  - Choose "custom listing" or something else
>  - Configure (ideally, we should have a small number of common use cases in multiple tiles rather than a single uber-tile to do everything)
>  - Save: stores a reference to the tile's URL in portal_registry (with parameters embedded in the query string)
>  - A viewlet (e.g. below the footer) fetches all tiles applicable to the current page and renders them, each contained with a <div /> with a unique id that makes it easy to target in a theme
>  - In a Diazo theme, you can pull the relevant stuff through
>
>
> Can you explain more what the integration with the theme editor does in the above? (there is already a listing tile that lets you pick a list template and listingviews will integrate with this).


First of all, the thinking here is that you configure the listing in
the tile settings, rather than referencing something that's persisted
elsewhere. Because (transient) tiles (i.e. the good kind of tile) are
configured entirely through the query string of the href that invokes
them, this is lightweight and robust: if a theme or registry setting
makes reference to a tile, the reference itself carries all the
information requires to render it correctly and there is no need to
sync up the reference to separate persistent configuration.

Again in thinking-out-loud mode, it may be interesting to experiment
with something like an overlay in the theming control panel that lets
you add/remove/change tiles associated with theme. These tiles would
then be rendered in the content (probably just one after the other in
a viewlet at the bottom of the page) for use by a Diazo rule (which
you could build using the point-and-click editor). The list of tiles
itself could be saved into portal_registry (a list-of-strings field
storing tile urls including query string parameters) or perhaps even
be kept entirely in the manifest.cfg file (against as a list of
strings in a section read by plugin configuration). With a bit more
config, the tiles could be tied to specific content types or
locations.

>
> Which problem are you trying to solve with what listing views already does? Is it that you don't want a "naked" listingview to ever be visible to an editor?

Not necessarily. I'm trying to think of a way to make this
configuration lightweight and isolated enough that it is predictable,
doesn't depend on infrastructure that may or may not go away in the
future, and allows for a modular style of configuration. If all we are
doing is providing 5-7 common use cases as tiles that can be inserted
and managed in a user-friendly way for use in a theme, it feels more
likely to be accepted than if we're building a bunch of new
infrastructure. I haven't looked closely at the listingviews code (at
least not for a while) to know if this is already the case, but
smaller, more precise things are more likely to end up in the core.

> Some variants:
>
>  - Choose a content item where the tile is going to be shown (as opposed to globally)
>  - Allow the tile to be inherited by children if the content item is a folder (note: the big mistake we made with portlets is that they opt-out inherit rather than opt-in)
>
>
> are you just talking about the part of deco which replaces portlets? or maybe there is a difference I'm missing.
> Note that listingviews already works like this with portlets (since tiles and deco isn't there yet) and it works quiet well.

I think it's potentially confusing to expect people to walk around the
content space and add portlets to things for their themes to work as
expected. It feels more appropriate for this to be done in the context
where you are managing the theme (i.e. the theme editor).

> You create listingview template, pick a view and choose either to make it relative (uses current context) or pick a specific item to show attributes + contents of.
> Make it trivial to the equivalent of a last published viewlet, or a news portlet that includes images, or a featured item portlet/time, or a carousel from a collection.
> or for items (which I didn't show before)
> but with deco it would more like portlets (except they'd be tiles).... and you'd just use the query building directly in the tile rather than point to a collection. Actually I should do the querybuilder part now in the existing listingview portlet since deco isn't coming anytime soon.

Again, I'd try to make the number of concepts and moving parts as low
as possible. So, if a use case involves adding a collection, setting
up some stuff in the control panel (the listing view), setting a
property on the collection (e.g. through the 'display' menu) and then
building a Diazo rule, then that's potentially four places to go to
get to the result you want. It works, absolutely, and it's a great
tactical solution for a lot of sites right now. However, for this to
be in the core of Plone, we'd likely want it to be something you do in
only one place. My thinking above was that this "one place" is the
theme editor (presuming the primary use case is theme building). This
would suggest that you instantiate tiles from within that UI and that
all the configuration required to render the thing you want (e.g. the
query parameters for a search) live inside the configuration of that
tile, not in some other extant UI construct (a collection) that you
then reference.

> (Disclaimer: I've not spent a huge amount of time thinking about this, so there may be some fatal flaw in what I'm suggesting)

That still stands, by the way. This is a fairly complex problem to
solve and there are many moving parts inside Plone that have to align.
I'm sure I haven't thought of all of them. Again why smaller, more
precise changes are preferable to sweeping ones. My first reaction
seeing http://pypi.python.org/pypi/collective.listingviews is that
"this thing does four or five different things". Of course they're all
related. And of course they're all useful to a lot of people. It's
just much harder to swallow one such thing, which potentially has
dependencies on "legacy" stuff or perhaps slightly suboptimal
engineering decisions, into the core of Plone at a time when people
are pining for a lighter core.

Martin

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

On 21/05/2013, at 4:51 AM, Martin Aspeli <[hidden email]> wrote:

> Hi,
>
> (Small request: can we avoid giant images to a mimum, please? The
> horizontal width of my Gmail has gone haywire ;-)
>
>
> On 20 May 2013 16:22, Dylan Jay <[hidden email]> wrote:
>>
>>
>> On 20/05/2013, at 11:40 PM, Martin Aspeli <[hidden email]> wrote:
>>
>> Hi
>>
>>
>> On 20 May 2013 08:27, Dylan Jay <[hidden email]> wrote:
>> Hi,
>>
>> I'm looking for advise on how to get something like collective.listingviews into the plone core.
>>
>> It would be useful to articulate "why", i.e. why is it better for this to be in core than in an add-on? I wonder if c.listingviews is analogous to PloneFormGen: perhaps a "must have" add-on for a lot of sites, but not something necessarily appropriate for core (either because it is confusing to a casual end user, as opposed to the type of power-user [but non-developer] you describe, or because of concerns around maintainability and technology choice, or simply to allow more rapid innovation). That's a genuine question, though, not an attempted put-down.
>>
>>
>> because it's tightly linked to theming and collections. You can create much better themes with something like listingviews.
>> Although I think a way to create forms in the core to replace PFG (based on dexterity schema editor) would be a good idea I think PFG doesn't have that many interactions with other components.
>
>
> I can buy that. It does mean the bar for usability and "future
> proofing" is pretty high, though. Once something goes into core, it's
> hard to take out.

agreed.


>
>>
>>
>>
>> - Collections is a powerful tool that lets users choose what items they want to show.
>> - Page templates is a powerful tool that lets plone developers create new custom views for folders, collections and items
>> - Diazo is a powerful tool to for a themer with control panel access to change the layout of collections
>>
>> Until now there hasn't been much in between.
>> ie, if I'm not a plone developer but a themer or site administrator and I want to display more info about items in a collection, what can I do?
>> There is the table view for collections but to me it has always seemed a bit of a hack.
>>
>> This is why we created collective.listingviews was created (In fact we went beyond collection views and made it so you can display a lot more info about on any content item in plone.)
>> So far we've found it to be very useful and have ended up using it on 4-5 different sites. Since we find it so useful, we think this with some more work, or something very similar would be a useful core feature.
>>
>> For example the following page was made just using eea.facetednavigation, collective.listingviews and plone.app.theming.
>> - http://mhcs.nswgov.pretacloud.com/publicationsandresources#b_start=0
>>
>> <Screen Shot 2013-05-20 at 1.34.39 PM.png>
>>
>>
>> <Screen Shot 2013-05-20 at 5.19.29 PM.png><Screen Shot 2013-05-20 at 5.20.12 PM.png>
>>
>>
>>
>> I realise this might not seem that useful to many of you because anyone on this list knows and loves ZPT. You might ask why do it in a more indirect and roundabout way?
>> The main reason is that we believe the learning curve is much lower and the chance of the user creating a view that breaks the site is less since less code is involved.
>>
>> One question: How do people not familiar with the internals of Plone figure out what to put in the 'TAL expression' boxes?
>>
>>
>> good question. The custom fields is meant to be an advanced option. listing views is still very useful without using them.
>
>
> So, to check that I understand: without this, it provides
> UI-configurable views for folders, content items, portlets or
> collections where the administrator can choose what gets rendered
> (from schema or catalogue fields) and how (e.g. pagination)

yes, thats pretty much it. except with the addition you can include tal expressions if the catalog fields aren't enough for you.

>
>>
>> It could be improved with some inline documentation or common api and by having many of the commonly used expressions preset for use in listing views (which we've already started doing)
>>
>
> That's a good start, indeed.
>
>>
>> For some more UI love this could be easier and less error prone still. (note the custom expression above are an optional part).
>>
>> I am a bit sceptical when people say things like "some more UI love" or "all that remains is some UI" as if that was the easy part. I think for this kind of thing to be part of making
>>
>> Plone more user friendly and not less, the UI needs to be pretty obvious.
>>
>>
>> hence why I'm bringing it to this list.
>> I'm very open to how to improve it and know that anything in the core has very well thought out and easy to use and that isn't hard.
>>
>> The model above is quite complex. I think it's great for the kind of non-developer power user you're targeting, but it may be scary to more traditional site administrators.
>>
>>
>> It's a themer tool. Since it requires daizo changes to make it look like you want it's tightly liked to your diazo theme. The themer creates a series of views which the content editors  can apply to their content.
>
>
> I think that's quite powerful. It does, however, create a dependency
> between a theme and things in content space (layout of folders, items,
> collections; assignments of portlets; assignments of custom views).
> This makes it somewhat harder to package and propagate themes (e.g.
> from dev to test to production). It may be worth thinking about how we
> solve this, probably by using the plugin points in plone.app.theming
> and packaging settings in the theme manifest (there's infrastructure
> for this already).

>
>>
>> The other reason is that separating the definition of the what attributes to list (listingview) vs how this should be laid out (diazo) allows for diazo patterns to be reused between different views and different sites (e.g. a sortable table layout). ZPT on the other hand combines presentation and attribute definition into the same file making reuse harder.
>>
>> Yes, I agree.
>>
>> One thing that strikes me is that in plone.tiles/plone.app.tiles we have a means of building lightweight, embeddable "snippets" that can have optional forms-driven configuration. These can then be included in themes by href (if plone.app.blocks or at least one of its transform is enabled), or perhaps be pulled in automatically via a ZPT looking up some configuration (say, a viewlet looking for config stored in portal_registry).
>>
>> I wonder if there's a way to extend the plone.app.theming theme editor and/or provide a control panel to allow admins to configure one or more tiles and embed them into a theme or assign them to a type's default view for incorporation via a Diazo rule.
>>
>> For example:
>>
>> - Go to the list of "theme tiles"
>> - Click "add tile"
>> - Choose "custom listing" or something else
>> - Configure (ideally, we should have a small number of common use cases in multiple tiles rather than a single uber-tile to do everything)
>> - Save: stores a reference to the tile's URL in portal_registry (with parameters embedded in the query string)
>> - A viewlet (e.g. below the footer) fetches all tiles applicable to the current page and renders them, each contained with a <div /> with a unique id that makes it easy to target in a theme
>> - In a Diazo theme, you can pull the relevant stuff through
>>
>>
>> Can you explain more what the integration with the theme editor does in the above? (there is already a listing tile that lets you pick a list template and listingviews will integrate with this).
>
>
> First of all, the thinking here is that you configure the listing in
> the tile settings, rather than referencing something that's persisted
> elsewhere. Because (transient) tiles (i.e. the good kind of tile) are
> configured entirely through the query string of the href that invokes
> them, this is lightweight and robust: if a theme or registry setting
> makes reference to a tile, the reference itself carries all the
> information requires to render it correctly and there is no need to
> sync up the reference to separate persistent configuration.
>
> Again in thinking-out-loud mode, it may be interesting to experiment
> with something like an overlay in the theming control panel that lets
> you add/remove/change tiles associated with theme. These tiles would
> then be rendered in the content (probably just one after the other in
> a viewlet at the bottom of the page) for use by a Diazo rule (which
> you could build using the point-and-click editor). The list of tiles
> itself could be saved into portal_registry (a list-of-strings field
> storing tile urls including query string parameters) or perhaps even
> be kept entirely in the manifest.cfg file (against as a list of
> strings in a section read by plugin configuration). With a bit more
> config, the tiles could be tied to specific content types or
> locations.
>
>>
>> Which problem are you trying to solve with what listing views already does? Is it that you don't want a "naked" listingview to ever be visible to an editor?
>
> Not necessarily. I'm trying to think of a way to make this
> configuration lightweight and isolated enough that it is predictable,
> doesn't depend on infrastructure that may or may not go away in the
> future, and allows for a modular style of configuration. If all we are
> doing is providing 5-7 common use cases as tiles that can be inserted
> and managed in a user-friendly way for use in a theme, it feels more
> likely to be accepted than if we're building a bunch of new
> infrastructure. I haven't looked closely at the listingviews code (at
> least not for a while) to know if this is already the case, but
> smaller, more precise things are more likely to end up in the core.
>
>> Some variants:
>>
>> - Choose a content item where the tile is going to be shown (as opposed to globally)
>> - Allow the tile to be inherited by children if the content item is a folder (note: the big mistake we made with portlets is that they opt-out inherit rather than opt-in)
>>
>>
>> are you just talking about the part of deco which replaces portlets? or maybe there is a difference I'm missing.
>> Note that listingviews already works like this with portlets (since tiles and deco isn't there yet) and it works quiet well.
>
> I think it's potentially confusing to expect people to walk around the
> content space and add portlets to things for their themes to work as
> expected. It feels more appropriate for this to be done in the context
> where you are managing the theme (i.e. the theme editor).
>
>> You create listingview template, pick a view and choose either to make it relative (uses current context) or pick a specific item to show attributes + contents of.
>> Make it trivial to the equivalent of a last published viewlet, or a news portlet that includes images, or a featured item portlet/time, or a carousel from a collection.
>> or for items (which I didn't show before)
>> but with deco it would more like portlets (except they'd be tiles).... and you'd just use the query building directly in the tile rather than point to a collection. Actually I should do the querybuilder part now in the existing listingview portlet since deco isn't coming anytime soon.
>
> Again, I'd try to make the number of concepts and moving parts as low
> as possible. So, if a use case involves adding a collection, setting
> up some stuff in the control panel (the listing view), setting a
> property on the collection (e.g. through the 'display' menu) and then
> building a Diazo rule, then that's potentially four places to go to
> get to the result you want. It works, absolutely, and it's a great
> tactical solution for a lot of sites right now. However, for this to
> be in the core of Plone, we'd likely want it to be something you do in
> only one place. My thinking above was that this "one place" is the
> theme editor (presuming the primary use case is theme building). This
> would suggest that you instantiate tiles from within that UI and that
> all the configuration required to render the thing you want (e.g. the
> query parameters for a search) live inside the configuration of that
> tile, not in some other extant UI construct (a collection) that you
> then reference.

ah ok I see where you are going now.

I agree that there is no point to having listingviews in the control panel when they are so linked to the a diazo theme.

In terms of using tile html representation, thats a clever idea esp since most of the work is already done to give us a UI to edit them. The one downside I see is that there isn't human editable data format so you can't use a code editor to cut and paste a listingview definition very easily. You have to rely on the forms.

However I don't think it's a good idea to move everything into the theme. There is always a connection between what is in the content area and the theme.
I see the themer's job is to provide a set of tools the content editor can use to do their job.

For example a "one place" solution for a blog would be hard coding the url /blog into your theme and making it do a query on all news items and then laying them out like a log with dates etc. Thats kind of a wordpress theme type solution.
A "two place" type solution might be to create a blog view in the theme and then get content editors to apply it to their particular folder or collection in the content area. Yes thats not so self contained but it also gives the content editors options like having two different blogs or different blogs areas filtered by subject.
Sometimes you are right however, the what you want to do is hard code everything since the you know exactly what the content editors want in the future. And it would be good to have a framework that makes it easy to have queries either via collections int he content area or embedded in the theme for example. Then the themer could make the choice on how much flexibility they wanted to give the editors.
Another way to think about it is you have the What (the query or collection), the How (the view or layout + the set of attributes), the Where (the path in the site). If all those choices are made my the themer we have a rigid hard-coded theme (this is like the contact-us page in plone). On the other hand if all three choices are to be made by content editors they have more flexibility but then they have to a lot of work and understand lots of things and can break layouts etc (this is like collective.easytemplate). Somewhere in between is better I think. That was what I was aiming for with listingviews. Interestingly the similar idea in Drupal called Views has the "what" and the "how" combined together whereas I left "what" to collections in content space. but being able to do either all could be very powerful.


>
>> (Disclaimer: I've not spent a huge amount of time thinking about this, so there may be some fatal flaw in what I'm suggesting)
>
> That still stands, by the way. This is a fairly complex problem to
> solve and there are many moving parts inside Plone that have to align.
> I'm sure I haven't thought of all of them. Again why smaller, more
> precise changes are preferable to sweeping ones. My first reaction
> seeing http://pypi.python.org/pypi/collective.listingviews is that
> "this thing does four or five different things". Of course they're all

Listingviews itself is trying to be like collections is, a single tool with many uses. Perhaps there things that can be cut out to make it simpler still?
You can seperate out the custom fields and listingviews from each other. One thing we've considered adding to the custom fields component is a tick box store a custom field value in the catalog, making it easy for the developers to switch between run time performance vs storage. That feature would make the custom fields be useful by itself.


> related. And of course they're all useful to a lot of people. It's
> just much harder to swallow one such thing, which potentially has
> dependencies on "legacy" stuff or perhaps slightly suboptimal
> engineering decisions, into the core of Plone at a time when people
> are pining for a lighter core.
>
> Martin


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

On 23/05/2013, at 1:58 AM, Dylan Jay <[hidden email]> wrote:

> On 21/05/2013, at 4:51 AM, Martin Aspeli <[hidden email]> wrote:
>
>> Hi,
>>
>> (Small request: can we avoid giant images to a mimum, please? The
>> horizontal width of my Gmail has gone haywire ;-)
>>
>>
>> On 20 May 2013 16:22, Dylan Jay <[hidden email]> wrote:
>>>
>>>
>>> On 20/05/2013, at 11:40 PM, Martin Aspeli <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>>
>>> On 20 May 2013 08:27, Dylan Jay <[hidden email]> wrote:
>>> Hi,
>>>
>>> I'm looking for advise on how to get something like collective.listingviews into the plone core.
>>>
>>> It would be useful to articulate "why", i.e. why is it better for this to be in core than in an add-on? I wonder if c.listingviews is analogous to PloneFormGen: perhaps a "must have" add-on for a lot of sites, but not something necessarily appropriate for core (either because it is confusing to a casual end user, as opposed to the type of power-user [but non-developer] you describe, or because of concerns around maintainability and technology choice, or simply to allow more rapid innovation). That's a genuine question, though, not an attempted put-down.
>>>
>>>
>>> because it's tightly linked to theming and collections. You can create much better themes with something like listingviews.
>>> Although I think a way to create forms in the core to replace PFG (based on dexterity schema editor) would be a good idea I think PFG doesn't have that many interactions with other components.
>>
>>
>> I can buy that. It does mean the bar for usability and "future
>> proofing" is pretty high, though. Once something goes into core, it's
>> hard to take out.
>
> agreed.
>
>
>>
>>>
>>>
>>>
>>> - Collections is a powerful tool that lets users choose what items they want to show.
>>> - Page templates is a powerful tool that lets plone developers create new custom views for folders, collections and items
>>> - Diazo is a powerful tool to for a themer with control panel access to change the layout of collections
>>>
>>> Until now there hasn't been much in between.
>>> ie, if I'm not a plone developer but a themer or site administrator and I want to display more info about items in a collection, what can I do?
>>> There is the table view for collections but to me it has always seemed a bit of a hack.
>>>
>>> This is why we created collective.listingviews was created (In fact we went beyond collection views and made it so you can display a lot more info about on any content item in plone.)
>>> So far we've found it to be very useful and have ended up using it on 4-5 different sites. Since we find it so useful, we think this with some more work, or something very similar would be a useful core feature.
>>>
>>> For example the following page was made just using eea.facetednavigation, collective.listingviews and plone.app.theming.
>>> - http://mhcs.nswgov.pretacloud.com/publicationsandresources#b_start=0
>>>
>>> <Screen Shot 2013-05-20 at 1.34.39 PM.png>
>>>
>>>
>>> <Screen Shot 2013-05-20 at 5.19.29 PM.png><Screen Shot 2013-05-20 at 5.20.12 PM.png>
>>>
>>>
>>>
>>> I realise this might not seem that useful to many of you because anyone on this list knows and loves ZPT. You might ask why do it in a more indirect and roundabout way?
>>> The main reason is that we believe the learning curve is much lower and the chance of the user creating a view that breaks the site is less since less code is involved.
>>>
>>> One question: How do people not familiar with the internals of Plone figure out what to put in the 'TAL expression' boxes?
>>>
>>>
>>> good question. The custom fields is meant to be an advanced option. listing views is still very useful without using them.
>>
>>
>> So, to check that I understand: without this, it provides
>> UI-configurable views for folders, content items, portlets or
>> collections where the administrator can choose what gets rendered
>> (from schema or catalogue fields) and how (e.g. pagination)
>
> yes, thats pretty much it. except with the addition you can include tal expressions if the catalog fields aren't enough for you.
>
>>
>>>
>>> It could be improved with some inline documentation or common api and by having many of the commonly used expressions preset for use in listing views (which we've already started doing)
>>>
>>
>> That's a good start, indeed.
>>
>>>
>>> For some more UI love this could be easier and less error prone still. (note the custom expression above are an optional part).
>>>
>>> I am a bit sceptical when people say things like "some more UI love" or "all that remains is some UI" as if that was the easy part. I think for this kind of thing to be part of making
>>>
>>> Plone more user friendly and not less, the UI needs to be pretty obvious.
>>>
>>>
>>> hence why I'm bringing it to this list.
>>> I'm very open to how to improve it and know that anything in the core has very well thought out and easy to use and that isn't hard.
>>>
>>> The model above is quite complex. I think it's great for the kind of non-developer power user you're targeting, but it may be scary to more traditional site administrators.
>>>
>>>
>>> It's a themer tool. Since it requires daizo changes to make it look like you want it's tightly liked to your diazo theme. The themer creates a series of views which the content editors  can apply to their content.
>>
>>
>> I think that's quite powerful. It does, however, create a dependency
>> between a theme and things in content space (layout of folders, items,
>> collections; assignments of portlets; assignments of custom views).
>> This makes it somewhat harder to package and propagate themes (e.g.
>> from dev to test to production). It may be worth thinking about how we
>> solve this, probably by using the plugin points in plone.app.theming
>> and packaging settings in the theme manifest (there's infrastructure
>> for this already).
>
>>
>>>
>>> The other reason is that separating the definition of the what attributes to list (listingview) vs how this should be laid out (diazo) allows for diazo patterns to be reused between different views and different sites (e.g. a sortable table layout). ZPT on the other hand combines presentation and attribute definition into the same file making reuse harder.
>>>
>>> Yes, I agree.
>>>
>>> One thing that strikes me is that in plone.tiles/plone.app.tiles we have a means of building lightweight, embeddable "snippets" that can have optional forms-driven configuration. These can then be included in themes by href (if plone.app.blocks or at least one of its transform is enabled), or perhaps be pulled in automatically via a ZPT looking up some configuration (say, a viewlet looking for config stored in portal_registry).
>>>
>>> I wonder if there's a way to extend the plone.app.theming theme editor and/or provide a control panel to allow admins to configure one or more tiles and embed them into a theme or assign them to a type's default view for incorporation via a Diazo rule.
>>>
>>> For example:
>>>
>>> - Go to the list of "theme tiles"
>>> - Click "add tile"
>>> - Choose "custom listing" or something else
>>> - Configure (ideally, we should have a small number of common use cases in multiple tiles rather than a single uber-tile to do everything)
>>> - Save: stores a reference to the tile's URL in portal_registry (with parameters embedded in the query string)
>>> - A viewlet (e.g. below the footer) fetches all tiles applicable to the current page and renders them, each contained with a <div /> with a unique id that makes it easy to target in a theme
>>> - In a Diazo theme, you can pull the relevant stuff through
>>>
>>>
>>> Can you explain more what the integration with the theme editor does in the above? (there is already a listing tile that lets you pick a list template and listingviews will integrate with this).
>>
>>
>> First of all, the thinking here is that you configure the listing in
>> the tile settings, rather than referencing something that's persisted
>> elsewhere. Because (transient) tiles (i.e. the good kind of tile) are
>> configured entirely through the query string of the href that invokes
>> them, this is lightweight and robust: if a theme or registry setting
>> makes reference to a tile, the reference itself carries all the
>> information requires to render it correctly and there is no need to
>> sync up the reference to separate persistent configuration.
>>
>> Again in thinking-out-loud mode, it may be interesting to experiment
>> with something like an overlay in the theming control panel that lets
>> you add/remove/change tiles associated with theme. These tiles would
>> then be rendered in the content (probably just one after the other in
>> a viewlet at the bottom of the page) for use by a Diazo rule (which
>> you could build using the point-and-click editor). The list of tiles
>> itself could be saved into portal_registry (a list-of-strings field
>> storing tile urls including query string parameters) or perhaps even
>> be kept entirely in the manifest.cfg file (against as a list of
>> strings in a section read by plugin configuration). With a bit more
>> config, the tiles could be tied to specific content types or
>> locations.
>>
>>>
>>> Which problem are you trying to solve with what listing views already does? Is it that you don't want a "naked" listingview to ever be visible to an editor?
>>
>> Not necessarily. I'm trying to think of a way to make this
>> configuration lightweight and isolated enough that it is predictable,
>> doesn't depend on infrastructure that may or may not go away in the
>> future, and allows for a modular style of configuration. If all we are
>> doing is providing 5-7 common use cases as tiles that can be inserted
>> and managed in a user-friendly way for use in a theme, it feels more
>> likely to be accepted than if we're building a bunch of new
>> infrastructure. I haven't looked closely at the listingviews code (at
>> least not for a while) to know if this is already the case, but
>> smaller, more precise things are more likely to end up in the core.
>>
>>> Some variants:
>>>
>>> - Choose a content item where the tile is going to be shown (as opposed to globally)
>>> - Allow the tile to be inherited by children if the content item is a folder (note: the big mistake we made with portlets is that they opt-out inherit rather than opt-in)
>>>
>>>
>>> are you just talking about the part of deco which replaces portlets? or maybe there is a difference I'm missing.
>>> Note that listingviews already works like this with portlets (since tiles and deco isn't there yet) and it works quiet well.
>>
>> I think it's potentially confusing to expect people to walk around the
>> content space and add portlets to things for their themes to work as
>> expected. It feels more appropriate for this to be done in the context
>> where you are managing the theme (i.e. the theme editor).
>>
>>> You create listingview template, pick a view and choose either to make it relative (uses current context) or pick a specific item to show attributes + contents of.
>>> Make it trivial to the equivalent of a last published viewlet, or a news portlet that includes images, or a featured item portlet/time, or a carousel from a collection.
>>> or for items (which I didn't show before)
>>> but with deco it would more like portlets (except they'd be tiles).... and you'd just use the query building directly in the tile rather than point to a collection. Actually I should do the querybuilder part now in the existing listingview portlet since deco isn't coming anytime soon.
>>
>> Again, I'd try to make the number of concepts and moving parts as low
>> as possible. So, if a use case involves adding a collection, setting
>> up some stuff in the control panel (the listing view), setting a
>> property on the collection (e.g. through the 'display' menu) and then
>> building a Diazo rule, then that's potentially four places to go to
>> get to the result you want. It works, absolutely, and it's a great
>> tactical solution for a lot of sites right now. However, for this to
>> be in the core of Plone, we'd likely want it to be something you do in
>> only one place. My thinking above was that this "one place" is the
>> theme editor (presuming the primary use case is theme building). This
>> would suggest that you instantiate tiles from within that UI and that
>> all the configuration required to render the thing you want (e.g. the
>> query parameters for a search) live inside the configuration of that
>> tile, not in some other extant UI construct (a collection) that you
>> then reference.
>
> ah ok I see where you are going now.
>
> I agree that there is no point to having listingviews in the control panel when they are so linked to the a diazo theme.
>
> In terms of using tile html representation, thats a clever idea esp since most of the work is already done to give us a UI to edit them. The one downside I see is that there isn't human editable data format so you can't use a code editor to cut and paste a listingview definition very easily. You have to rely on the forms.
>
> However I don't think it's a good idea to move everything into the theme. There is always a connection between what is in the content area and the theme.
> I see the themer's job is to provide a set of tools the content editor can use to do their job.
>
> For example a "one place" solution for a blog would be hard coding the url /blog into your theme and making it do a query on all news items and then laying them out like a log with dates etc. Thats kind of a wordpress theme type solution.
> A "two place" type solution might be to create a blog view in the theme and then get content editors to apply it to their particular folder or collection in the content area. Yes thats not so self contained but it also gives the content editors options like having two different blogs or different blogs areas filtered by subject.
> Sometimes you are right however, the what you want to do is hard code everything since the you know exactly what the content editors want in the future. And it would be good to have a framework that makes it easy to have queries either via collections int he content area or embedded in the theme for example. Then the themer could make the choice on how much flexibility they wanted to give the editors.
> Another way to think about it is you have the What (the query or collection), the How (the view or layout + the set of attributes), the Where (the path in the site). If all those choices are made my the themer we have a rigid hard-coded theme (this is like the contact-us page in plone). On the other hand if all three choices are to be made by content editors they have more flexibility but then they have to a lot of work and understand lots of things and can break layouts etc (this is like collective.easytemplate). Somewhere in between is better I think. That was what I was aiming for with listingviews. Interestingly the similar idea in Drupal called Views has the "what" and the "how" combined together whereas I left "what" to collections in content space. but being able to do either all could be very powerful.

so in summary. if we
- took listingviews (ie named set of fields to show for content + for each item in a list)
- put it into the themeeditor with a UI (with some corresponding file format) such as using tiles with attribute encoding like you suggest.
- had more help and nicer widgets,
- included the querystring builder such that listingview can be a self contained view, or the query can be left out so that the list comes from folders or collections
- some way to hard code them into a theme or alternatively let them be used in deco tiles, portlets or dynamic views.
How does that sound?



>
>
>>
>>> (Disclaimer: I've not spent a huge amount of time thinking about this, so there may be some fatal flaw in what I'm suggesting)
>>
>> That still stands, by the way. This is a fairly complex problem to
>> solve and there are many moving parts inside Plone that have to align.
>> I'm sure I haven't thought of all of them. Again why smaller, more
>> precise changes are preferable to sweeping ones. My first reaction
>> seeing http://pypi.python.org/pypi/collective.listingviews is that
>> "this thing does four or five different things". Of course they're all
>
> Listingviews itself is trying to be like collections is, a single tool with many uses. Perhaps there things that can be cut out to make it simpler still?
> You can seperate out the custom fields and listingviews from each other. One thing we've considered adding to the custom fields component is a tick box store a custom field value in the catalog, making it easy for the developers to switch between run time performance vs storage. That feature would make the custom fields be useful by itself.
>
>
>> related. And of course they're all useful to a lot of people. It's
>> just much harder to swallow one such thing, which potentially has
>> dependencies on "legacy" stuff or perhaps slightly suboptimal
>> engineering decisions, into the core of Plone at a time when people
>> are pining for a lighter core.
>>
>> Martin
>


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

Hi,

On 23 May 2013 13:51, Dylan Jay <[hidden email]> wrote:

>>> Again, I'd try to make the number of concepts and moving parts as low
>>> as possible. So, if a use case involves adding a collection, setting
>>> up some stuff in the control panel (the listing view), setting a
>>> property on the collection (e.g. through the 'display' menu) and then
>>> building a Diazo rule, then that's potentially four places to go to
>>> get to the result you want. It works, absolutely, and it's a great
>>> tactical solution for a lot of sites right now. However, for this to
>>> be in the core of Plone, we'd likely want it to be something you do in
>>> only one place. My thinking above was that this "one place" is the
>>> theme editor (presuming the primary use case is theme building). This
>>> would suggest that you instantiate tiles from within that UI and that
>>> all the configuration required to render the thing you want (e.g. the
>>> query parameters for a search) live inside the configuration of that
>>> tile, not in some other extant UI construct (a collection) that you
>>> then reference.
>>
>> ah ok I see where you are going now.
>>
>> I agree that there is no point to having listingviews in the control panel when they are so linked to the a diazo theme.
>>
>> In terms of using tile html representation, thats a clever idea esp since most of the work is already done to give us a UI to edit them. The one downside I see is that there isn't human editable data format so you can't use a code editor to cut and paste a listingview definition very easily. You have to rely on the forms.

A (transient) tile is saved entirely as a URL, with query string
parameters for configuration. That's relatively easy to move around.

>> However I don't think it's a good idea to move everything into the theme. There is always a connection between what is in the content area and the theme.
>> I see the themer's job is to provide a set of tools the content editor can use to do their job.

I agree with that philosophy.

>> For example a "one place" solution for a blog would be hard coding the url /blog into your theme and making it do a query on all news items and then laying them out like a log with dates etc. Thats kind of a wordpress theme type solution.
>> A "two place" type solution might be to create a blog view in the theme and then get content editors to apply it to their particular folder or collection in the content area. Yes thats not so self contained but it also gives the content editors options like having two different blogs or different blogs areas filtered by subject.

There are some ways to make choices:

 - The 'display' menu
 - Tags/keywords
 - Content types (or 'categories' as Deco would call them)

These are all valid. Personally, I think perhaps the content type
option is most logical. You choose what type you want before you
insert the item, as we can use per-folder type restrictions to
constrain the site's information architecture.

The basic implementation of categories in Deco simply creates new
types in portal_types when a (super)user saves a new category of page.

>> Sometimes you are right however, the what you want to do is hard code everything since the you know exactly what the content editors want in the future. And it would be good to have a framework that makes it easy to have queries either via collections int he content area or embedded in the theme for example. Then the themer could make the choice on how much flexibility they wanted to give the editors.

I think there are three roles here:

 - Editors
 - Site admins
 - Themers

I think site admins are the ones who decide what content can go where.
A themer will make a theme that is as generic as necessary to support
what editors do within the confines created by the site admins.

In general, a theme matching a path sucks. A theme mathing a body
class, say, indicating a content type or some other metadata, is much
more flexible.

>> Another way to think about it is you have the What (the query or collection), the How (the view or layout + the set of attributes), the Where (the path in the site). If all those choices are made my the themer we have a rigid hard-coded theme (this is like the contact-us page in plone). On the other hand if all three choices are to be made by content editors they have more flexibility but then they have to a lot of work and understand lots of things and can break layouts etc (this is like collective.easytemplate). Somewhere in between is better I think. That was what I was aiming for with listingviews. Interestingly the similar idea in Drupal called Views has the "what" and the "how" combined together whereas I left "what" to collections in content space. but being able to do either all could be very powerful.

I think leaving Collections is content space is right for Plone. It's
an editor/"section admin" type task. I do think we want listing tiles
that use collection-like query building as well for insertion into a
global layout, but that's more the 'nav tree' or 'recent changes' type
use case than a listing of content for navigation purposes.

> so in summary. if we
> - took listingviews (ie named set of fields to show for content + for each item in a list)
> - put it into the themeeditor with a UI (with some corresponding file format) such as using tiles with attribute encoding like you suggest.
> - had more help and nicer widgets,
> - included the querystring builder such that listingview can be a self contained view, or the query can be left out so that the list comes from folders or collections
> - some way to hard code them into a theme or alternatively let them be used in deco tiles, portlets or dynamic views.
> How does that sound?

I think I'd need to see a more detailed design to pass judgement, but
the principles of smaller, more focused and lighter components are
right IMHO.

Martin

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

On 23/05/2013, at 11:31 PM, Martin Aspeli <[hidden email]> wrote:

> Hi,
>
> On 23 May 2013 13:51, Dylan Jay <[hidden email]> wrote:
>
>>>> Again, I'd try to make the number of concepts and moving parts as low
>>>> as possible. So, if a use case involves adding a collection, setting
>>>> up some stuff in the control panel (the listing view), setting a
>>>> property on the collection (e.g. through the 'display' menu) and then
>>>> building a Diazo rule, then that's potentially four places to go to
>>>> get to the result you want. It works, absolutely, and it's a great
>>>> tactical solution for a lot of sites right now. However, for this to
>>>> be in the core of Plone, we'd likely want it to be something you do in
>>>> only one place. My thinking above was that this "one place" is the
>>>> theme editor (presuming the primary use case is theme building). This
>>>> would suggest that you instantiate tiles from within that UI and that
>>>> all the configuration required to render the thing you want (e.g. the
>>>> query parameters for a search) live inside the configuration of that
>>>> tile, not in some other extant UI construct (a collection) that you
>>>> then reference.
>>>
>>> ah ok I see where you are going now.
>>>
>>> I agree that there is no point to having listingviews in the control panel when they are so linked to the a diazo theme.
>>>
>>> In terms of using tile html representation, thats a clever idea esp since most of the work is already done to give us a UI to edit them. The one downside I see is that there isn't human editable data format so you can't use a code editor to cut and paste a listingview definition very easily. You have to rely on the forms.
>
> A (transient) tile is saved entirely as a URL, with query string
> parameters for configuration. That's relatively easy to move around.

not sure what you mean by move around.
My concern is if something like a listingview is to be included in a theme, currently everything in a theme can be downloaded as a zip and edited in a code editor. That is very handy.
Editing a querystring is possible but not nice. Instead it might be better to have some kind of xml or yaml format? With listingviews you conceivably store it in the form of generated zpt which could be downloaded and used in fs code. However then you get into mixing generated code with custom code and it rarely seems to work out well.


>
>>> However I don't think it's a good idea to move everything into the theme. There is always a connection between what is in the content area and the theme.
>>> I see the themer's job is to provide a set of tools the content editor can use to do their job.
>
> I agree with that philosophy.
>
>>> For example a "one place" solution for a blog would be hard coding the url /blog into your theme and making it do a query on all news items and then laying them out like a log with dates etc. Thats kind of a wordpress theme type solution.
>>> A "two place" type solution might be to create a blog view in the theme and then get content editors to apply it to their particular folder or collection in the content area. Yes thats not so self contained but it also gives the content editors options like having two different blogs or different blogs areas filtered by subject.
>
> There are some ways to make choices:
>
> - The 'display' menu
> - Tags/keywords
> - Content types (or 'categories' as Deco would call them)
>
> These are all valid. Personally, I think perhaps the content type
> option is most logical. You choose what type you want before you
> insert the item, as we can use per-folder type restrictions to
> constrain the site's information architecture.
>
> The basic implementation of categories in Deco simply creates new
> types in portal_types when a (super)user saves a new category of page.

so in deco there is no dymamic views? so you want to change from one layout to another you have to delete and start again?
I suppose that makes sense since you can add text tiles which is like adding schema fields, but then again, if you have a few variations on the layout with the same text tiles then it's pretty inflexible if there isn't an easy way to switch between them.

But thats off topic. You seem to be suggesting that we should limit to the way listingviews can be picked by the siteadmin to just catagory/type of page which seems limiting to me.
For example lets say we are trying to have a page with a listing of the last weeks news items.

If I understand you correctly you are saying it should work something like this.
- site admin creates a new content type/category for the purpose of having this new listing called "news" and adds a listingtile and defines query for last weeks news. The generic listing tile would just list the default fields (kind of like a summary view).
- themer creates "news" listing that includes the title of the current item + the title, link and publication date of all the content items. Specifies that it is shown only on "news" types/categories. Themer uses diazo to style the listing how they want.
- content editor creates a news page and the listing part is styled.


However listingviews in it's current form works like this (assuming it's moved into the theme editor)
- themer creates "news" listing that includes the title of the current item + the title, link and publication date of all the content items.
- the site admin drags a listingview tile onto an item, selects "news" from the list of views and defines the query to be the last week of news items.
- the themer can target the tile class and make it look pretty.

architecture 1 is more like contenttype overrides of a ZPT. architecture 2 is more like an inbuilt tile creator for a restricted kinds of tiles.

I'm not sure I've got what you said right but if so I think it's too restrictive. For example then you can't have two different kinds of listings on a single page. Also the fact that the type has to be created before the themer can target it seems problematic.

>
>>> Sometimes you are right however, the what you want to do is hard code everything since the you know exactly what the content editors want in the future. And it would be good to have a framework that makes it easy to have queries either via collections int he content area or embedded in the theme for example. Then the themer could make the choice on how much flexibility they wanted to give the editors.
>
> I think there are three roles here:
>
> - Editors
> - Site admins
> - Themers
>
> I think site admins are the ones who decide what content can go where.
> A themer will make a theme that is as generic as necessary to support
> what editors do within the confines created by the site admins.
>
> In general, a theme matching a path sucks. A theme mathing a body
> class, say, indicating a content type or some other metadata, is much
> more flexible.
>
>>> Another way to think about it is you have the What (the query or collection), the How (the view or layout + the set of attributes), the Where (the path in the site). If all those choices are made my the themer we have a rigid hard-coded theme (this is like the contact-us page in plone). On the other hand if all three choices are to be made by content editors they have more flexibility but then they have to a lot of work and understand lots of things and can break layouts etc (this is like collective.easytemplate). Somewhere in between is better I think. That was what I was aiming for with listingviews. Interestingly the similar idea in Drupal called Views has the "what" and the "how" combined together whereas I left "what" to collections in content space. but being able to do either all could be very powerful.
>
> I think leaving Collections is content space is right for Plone. It's
> an editor/"section admin" type task. I do think we want listing tiles
> that use collection-like query building as well for insertion into a
> global layout, but that's more the 'nav tree' or 'recent changes' type
> use case than a listing of content for navigation purposes.
>
>> so in summary. if we
>> - took listingviews (ie named set of fields to show for content + for each item in a list)
>> - put it into the themeeditor with a UI (with some corresponding file format) such as using tiles with attribute encoding like you suggest.
>> - had more help and nicer widgets,
>> - included the querystring builder such that listingview can be a self contained view, or the query can be left out so that the list comes from folders or collections
>> - some way to hard code them into a theme or alternatively let them be used in deco tiles, portlets or dynamic views.
>> How does that sound?
>
> I think I'd need to see a more detailed design to pass judgement, but
> the principles of smaller, more focused and lighter components are
> right IMHO.
>
> Martin


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

Hi,

On 25 May 2013 01:20, Dylan Jay <[hidden email]> wrote:
>> A (transient) tile is saved entirely as a URL, with query string
>> parameters for configuration. That's relatively easy to move around.

> not sure what you mean by move around.

I mean, if the tile is referenced in an HTML tag in the theme, and is
fully self-contained within the URL that describes it, then it's easy
to move it around the page, move it from one theme to another, or move
it from one server to another with the theme, e.g. in a ZIP file.

> My concern is if something like a listingview is to be included in a theme, currently everything in a theme can be downloaded as a zip and edited in a code editor. That is very handy.
> Editing a querystring is possible but not nice. Instead it might be better to have some kind of xml or yaml format?

Don't invent multiple ways to store information. You end up having to
sync. plone.app.tiles provides a forms-based GUI for editing tile
parameters, persisting to a query string.

> With listingviews you conceivably store it in the form of generated zpt which could be downloaded and used in fs code. However then you get into mixing generated code with custom code and it rarely seems to work out well.

Generating a ZPT seems like an exceptionally bad idea. I can't see why
it would be necessary.

My expectation was that we'd have a set of tiles, each of which is
effectively a view (a ZPT + some Python code), each encapsulating a
single use case with some configurable parameters. The parameters are
persisted within the URL that holds the tile reference, in the query
string. They are editable by a p.a.tiles GUI that uses this to expose
an edit form. Tiles render themselves with the relevant information,
using their configuration to decide e.g. what columns to render in a
table or what content to filter out. This is all pretty standard
plone.tiles stuff.

>> There are some ways to make choices:
>>
>> - The 'display' menu
>> - Tags/keywords
>> - Content types (or 'categories' as Deco would call them)
>>
>> These are all valid. Personally, I think perhaps the content type
>> option is most logical. You choose what type you want before you
>> insert the item, as we can use per-folder type restrictions to
>> constrain the site's information architecture.
>>
>> The basic implementation of categories in Deco simply creates new
>> types in portal_types when a (super)user saves a new category of page.
>
> so in deco there is no dymamic views? so you want to change from one layout to another you have to delete and start again?

With a Deco-managed page (which isn't the only kind of content
envisaged in a world where Plone ships with Deco, but possibly the
only out-of-the-box kind) you can change layouts by moving things
around in the Deco editor (if you have permission to do so). A
"category" is a predefined page layout with some default tiles. You do
"save as category" when editing a page, and et voilla you have a new
thing you can add in your site that will make new instances look like
this. This is how you drive consistency across the site.

> I suppose that makes sense since you can add text tiles which is like adding schema fields, but then again, if you have a few variations on the layout with the same text tiles then it's pretty inflexible if there isn't an easy way to switch between them.

Switching between layouts and preserving content is not always an easy
problem to solve, but there's no reason we can't have a UI element
that says "change category" that uses the new tile's layout. I don't
actually think it's a hugely important use case, though. Most of the
time, people will choose the category before authoring content.
Changing it after the fact is somewhat uncommon except if you make a
mistake (in which case the UI to choose the category in the first
place probably wasn't very good).

> But thats off topic. You seem to be suggesting that we should limit to the way listingviews can be picked by the siteadmin to just catagory/type of page which seems limiting to me.

Not necessarily. Per-instance is fine. I just wonder if the 'display'
menu or portlets are the right UI element to do it with. If you are
trying to package a listing view (which in my head would be a tile
with some configuration applied) into a theme, then you may want to
make that choice in the theme rules file.

So maybe as a sketch, there's a conditional Diazo rule like:

<replace
  css:theme-children="#contentListingArea"
  css:content-children="body"
  href="./@@some.listing.tile?portal_type=Page&limit=10&extraFields=Subject"
  css:if="$showsSomeListing"
  />

Here:

 - We are putting the body of the tile (remember, a tile is a full
HTML document where the `<body />` is the bit you show to the user)
into the area in the theme with id `contentListingArea`
 - We invoke the tile by URL (and here use Diazo href support to do
the rendering). Parameters are passed on the query string (I've
imagined some inputs to a catalogue query for this example). This
would actually be built up using a forms-based GUI like the one in
p.a.tiles, of course, not hand coded, but once serialised it can stay
there.
 - We only do this if a condition is true. Here, I've imagined a
parameter, which in turn may resolve to a TAL expression checking e.g.
the keywords/tags on a content item, its portal type, or something
else entirely. (Of course, for the rule to be conditional on a class
on the `<body />` of the content or some other rule condition would
also work)

All I'm trying to do is to keep things in one place. The assumption
behind this discussion seems to be that the reason someone might want
to make a "listing view" is as a complement to theming with Diazo,
where Plone on its own does not spit out the right data to make it
possible to fully implement the look and feel (or provide the specific
content) you want. That suggests to me that configuring and
associating (in general terms, e.g. by type or keyword or whatever,
not to specific content items) listing views is an activity tightly
bound into the activity of transforming and styling the rendered tile,
i.e. it's an activity that takes place with building a theme.

If that's the case, then having the configuration in "content space"
(e.g. "you must put this portlet here for this type of page to render
as intended with the theme applied") is brittle. And having one set of
controlling actions (say, a control panel) to configure an abstract
set of listing views, another to transform and style them (i.e. the
theme editor) and another to invoke it (i.e. in content space) means
it's easy to get confused and make mistakes.

If we did end up with a design like the one I'm thinking about here,
it would have the advantage that we'd have come up with a generic way
to build tiles and pull them into a Diazo theme. This use case isn't
limited to listing views. You could imagine other things like, say, a
Twitter feed of a specific hashtag or whatever. This is the kind of
stuff that isn't content and is probably today done as portlets that
are placed very carefully and specifically once by an admin and then
never touched again. If, a year later, you come back to that portlet
and don't realise it's integral to the look and feel of the site (e.g.
the theme makes assumptions about it being there) then you may move it
or delete it, and if you are trying to propagate changes from dev to
test to prod you need to make careful content-space changes, possibly
manually.

Your other explanation made me ask a few questions:

> However listingviews in it's current form works like this (assuming it's moved into the theme editor)
> - themer creates "news" listing that includes the title of the current item + the title, link and publication date of all the content items.

Can you explain how the actual listing is stored, e.g. a generated
ZPT, or some config that a generic ZPT looks at (if so, where), or?

> - the site admin drags a listingview tile onto an item, selects "news" from the list of views and defines the query to be the last week of news items.

How is the association maintained?

Are listing views usually configured once and used for a single
content item, or re-used in multiple "similar" places?

Martin

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

On 28/05/2013, at 8:56 AM, Martin Aspeli <[hidden email]> wrote:

> Hi,
>
> On 25 May 2013 01:20, Dylan Jay <[hidden email]> wrote:
>>> A (transient) tile is saved entirely as a URL, with query string
>>> parameters for configuration. That's relatively easy to move around.
>
>> not sure what you mean by move around.
>
> I mean, if the tile is referenced in an HTML tag in the theme, and is
> fully self-contained within the URL that describes it, then it's easy
> to move it around the page, move it from one theme to another, or move
> it from one server to another with the theme, e.g. in a ZIP file.
>
>> My concern is if something like a listingview is to be included in a theme, currently everything in a theme can be downloaded as a zip and edited in a code editor. That is very handy.
>> Editing a querystring is possible but not nice. Instead it might be better to have some kind of xml or yaml format?
>
> Don't invent multiple ways to store information. You end up having to
> sync. plone.app.tiles provides a forms-based GUI for editing tile
> parameters, persisting to a query string.

>
>> With listingviews you conceivably store it in the form of generated zpt which could be downloaded and used in fs code. However then you get into mixing generated code with custom code and it rarely seems to work out well.
>
> Generating a ZPT seems like an exceptionally bad idea. I can't see why
> it would be necessary.
>
> My expectation was that we'd have a set of tiles, each of which is
> effectively a view (a ZPT + some Python code), each encapsulating a
> single use case with some configurable parameters. The parameters are
> persisted within the URL that holds the tile reference, in the query
> string. They are editable by a p.a.tiles GUI that uses this to expose
> an edit form. Tiles render themselves with the relevant information,
> using their configuration to decide e.g. what columns to render in a
> table or what content to filter out. This is all pretty standard
> plone.tiles stuff.

>
>>> There are some ways to make choices:
>>>
>>> - The 'display' menu
>>> - Tags/keywords
>>> - Content types (or 'categories' as Deco would call them)
>>>
>>> These are all valid. Personally, I think perhaps the content type
>>> option is most logical. You choose what type you want before you
>>> insert the item, as we can use per-folder type restrictions to
>>> constrain the site's information architecture.
>>>
>>> The basic implementation of categories in Deco simply creates new
>>> types in portal_types when a (super)user saves a new category of page.
>>
>> so in deco there is no dymamic views? so you want to change from one layout to another you have to delete and start again?
>
> With a Deco-managed page (which isn't the only kind of content
> envisaged in a world where Plone ships with Deco, but possibly the
> only out-of-the-box kind) you can change layouts by moving things
> around in the Deco editor (if you have permission to do so). A
> "category" is a predefined page layout with some default tiles. You do
> "save as category" when editing a page, and et voilla you have a new
> thing you can add in your site that will make new instances look like
> this. This is how you drive consistency across the site.
>
>> I suppose that makes sense since you can add text tiles which is like adding schema fields, but then again, if you have a few variations on the layout with the same text tiles then it's pretty inflexible if there isn't an easy way to switch between them.
>
> Switching between layouts and preserving content is not always an easy
> problem to solve, but there's no reason we can't have a UI element
> that says "change category" that uses the new tile's layout. I don't
> actually think it's a hugely important use case, though. Most of the
> time, people will choose the category before authoring content.
> Changing it after the fact is somewhat uncommon except if you make a
> mistake (in which case the UI to choose the category in the first
> place probably wasn't very good).

It's reasonably common for users to change their minds about if they want table view, summary view or default view for a folder in plone.
Losing that would be a shame.
but anyway, thats off topic.

>
>> But thats off topic. You seem to be suggesting that we should limit to the way listingviews can be picked by the siteadmin to just catagory/type of page which seems limiting to me.
>
> Not necessarily. Per-instance is fine. I just wonder if the 'display'
> menu or portlets are the right UI element to do it with. If you are
> trying to package a listing view (which in my head would be a tile
> with some configuration applied) into a theme, then you may want to
> make that choice in the theme rules file.
>
> So maybe as a sketch, there's a conditional Diazo rule like:
>
> <replace
>  css:theme-children="#contentListingArea"
>  css:content-children="body"
>  href="./@@some.listing.tile?portal_type=Page&limit=10&extraFields=Subject"
>  css:if="$showsSomeListing"
>  />
>
> Here:
>
> - We are putting the body of the tile (remember, a tile is a full
> HTML document where the `<body />` is the bit you show to the user)
> into the area in the theme with id `contentListingArea`
> - We invoke the tile by URL (and here use Diazo href support to do
> the rendering). Parameters are passed on the query string (I've
> imagined some inputs to a catalogue query for this example). This
> would actually be built up using a forms-based GUI like the one in
> p.a.tiles, of course, not hand coded, but once serialised it can stay
> there.
> - We only do this if a condition is true. Here, I've imagined a
> parameter, which in turn may resolve to a TAL expression checking e.g.
> the keywords/tags on a content item, its portal type, or something
> else entirely. (Of course, for the rule to be conditional on a class
> on the `<body />` of the content or some other rule condition would
> also work)


Sorry for being so slow getting back to you.

So what you are seeing is that something like listingviews is a single kind of tile with parameters. The parramters being (in the case of a listing view)
- which fields or expressions displayed about the context
- which fields and expressions are displayed about each item in the list
- batching options
- which context object to use, or query to use for the listing.

the difference here is that instead of the like deco the tile being created by editor/admin person in the content space it's created by the themer in the theme editor and connected into diazo using the href style rule as above.

I can see this being useful in some usecases but it has some drawbacks. For example this is a good technique to replace "viewlets", snippets that are on every page or every content type and is in a *fixed location* on the page. e.g. last updated date, or a twitter share button that needs pull some hidden field out of the content item or context.

Where I'd like to improve this is where the editor/admin person is given choice as to how they want something displayed. Listingviews was designed with the "display menu" in mind. Themer creates the view, gives it a name and the editor/admin can choose where they want to apply it. The ability for listingviews to allow a themer to create class names that edtiors use to mark certain parts of the page as needing a certain content in a certain layout is very important.
In a deco based plone I guess this would covert to creating named tiles from preset params to more generic tiles. and then having the editor/admin place that new tile type on the pages they want.

There are few specific things about your proposal that makes it hard to let the editor/themer choose where the a themer defined tile would go.
The replace href diazo syntax doesn't allow you to replace elements from the content, only from the theme file. So the location of where on the page your tiles go essentually is precalculated. If it was possible to make rule like below then this would be different.

<replace
 css:content-children=".mytilemarker"
 css:contenthref-children="body"
 href="./@@some.listing.tile?portal_type=Page&limit=10&extraFields=Subject"
 >

If this kind of content to content transformation existed it would be very useful. It would mean a themer could replace plugins like collective.flowplayer. It would also mean you don't need that css:if="$showsSomeListing" which seems a ugly since the condition is no longer in the rules file.

Also, since the view is not editable you'll want to use diazo to change it. So you will need more than one rule. So putting the params in the href perhaps isn't a good idea.
Having listingview definitions named would make that easier
 href="./@@some.listing.tile?listing=mylisting"


Another concern I have is the mental model for the themer is more complex. They have to now combine three plus pages into one, instead of just two. Currently they just have to get the right content onto the right content pages and then rearrange it. It's simple to understand and easy to debug since you can just render a page without a theme to what you need. To make what you suggest work I think you'd need some extra tools to help them render all the tiles along with each content page to make it easier for them to write their rules. I don't think thats too hard to do.

>
> All I'm trying to do is to keep things in one place. The assumption
> behind this discussion seems to be that the reason someone might want
> to make a "listing view" is as a complement to theming with Diazo,
> where Plone on its own does not spit out the right data to make it
> possible to fully implement the look and feel (or provide the specific
> content) you want. That suggests to me that configuring and
> associating (in general terms, e.g. by type or keyword or whatever,
> not to specific content items) listing views is an activity tightly
> bound into the activity of transforming and styling the rendered tile,
> i.e. it's an activity that takes place with building a theme.

listingviews are both tightly linked to not just the diazo theme but also content types. In some ways they make sense to be stored in the collection settings. Perhaps the custom fields part of listingviews is stored there and the views part is put in the theme.
One idea we had with the custom fields was allow them to be optionally used as catalog metadata. The administrator could then choose calculation on write vs read. Thats something that can only be done if it's stored outside the theme.


>
> If that's the case, then having the configuration in "content space"
> (e.g. "you must put this portlet here for this type of page to render
> as intended with the theme applied") is brittle. And having one set of
> controlling actions (say, a control panel) to configure an abstract
> set of listing views, another to transform and style them (i.e. the
> theme editor) and another to invoke it (i.e. in content space) means
> it's easy to get confused and make mistakes.
>
> If we did end up with a design like the one I'm thinking about here,
> it would have the advantage that we'd have come up with a generic way
> to build tiles and pull them into a Diazo theme. This use case isn't
> limited to listing views. You could imagine other things like, say, a
> Twitter feed of a specific hashtag or whatever. This is the kind of
> stuff that isn't content and is probably today done as portlets that
> are placed very carefully and specifically once by an admin and then
> never touched again. If, a year later, you come back to that portlet
> and don't realise it's integral to the look and feel of the site (e.g.
> the theme makes assumptions about it being there) then you may move it
> or delete it, and if you are trying to propagate changes from dev to
> test to prod you need to make careful content-space changes, possibly
> manually.

>
> Your other explanation made me ask a few questions:
>
>> However listingviews in it's current form works like this (assuming it's moved into the theme editor)
>> - themer creates "news" listing that includes the title of the current item + the title, link and publication date of all the content items.
>
> Can you explain how the actual listing is stored, e.g. a generated
> ZPT, or some config that a generic ZPT looks at (if so, where), or?

its stored in the registry as some config that a generic ZPT looks at.
I did consider adding the ability to view a listingview definition as ZPT so you could copy and paste it as a quick way to get started with ZPT.

>
>> - the site admin drags a listingview tile onto an item, selects "news" from the list of views and defines the query to be the last week of news items.
>
> How is the association maintained?

The example above is hypothetical as it doesn't yet work with tiles.
However with portlets it stores the name of the view in the portlet configuration and looks up teh configuration from the registry.
In the case of dynamic views it registers a special browserview with the name of the view in the name.

>
> Are listing views usually configured once and used for a single
> content item, or re-used in multiple "similar" places?

both. we use it for news listings in several places such as here http://www.ses.vic.gov.au/media/news

Publications listing in combination with eea.facetednavigation. http://mhcs.nswgov.pretacloud.com/publicationsandresources#b_start=0
and things like last updated portlets. We've also used it as a carousel portlet.


>
> Martin


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: enhanced collections views

Hi,

In summary if we had the following I think it would be a pretty good solution

1. named tile instances in a theme e.g. mynewsview.tile. And extend the theme editor to let you edit a tile using a UI and via text editor.
2. custom styles in a theme. display menu selections, tinymce styles, portlet styles etc. Probably in the manifest file. It would get merged with styles already configured in the system.
3. named custom expressions in control panel. Ability to have them used as metadata in the catalog and reused by other parts of plone. Like a function library.
4. a tile type for a listingview.  Possibly a few others like a navigation tree where fields can be picked. i.e. simple predefined templates with point and click options.
5. New Diazo syntax to do content-to-content transformations. e.g. <replace css:content="#menu" css:hrefcontent="#menu" href="./@@custom-menu" />
6. A special view so all the content views that make up a themed page can be viewed together. perhaps merged into the p.a.theming rules editor. Since the syntax in #5 turns diazo into a two step process might also need a way to view the content after it's merge but before it's themed.
6. Advanced users can also create .pt based views like in plone.app.themingplugins.
7. listingview tiles instances could be auto-converted to .pt views when a themer wants more power but it would be a one way conversion.  

Hopefully I explained the reasons for most of this in my last email, except maybe #2.
#2 styles in theme. We have an existing problem now that themes come with custom styles yet the tinyMCE config has to be changed manually or via GS to let users use those styles. We use portlet-styles plugin a lot and that has the same problem. If we move listingviews to the theme then I'd still like a way to let an admin pick that view from the display menu or in a portlet. If we can define these styles in the theme once the theme is installed the display menu has these extra options. Once selected they just add an empty view but the body tag will include the special class style. The diazo rules link the style class with a .pt view or listingview tile in the theme.  

I'd say it's a more indirect than the way listingviews works now but all the bits add things that are needed anyway I think and it does integrate nicely with the themingplugins approach. And a lot more the configuration is in theme and out of the control panel.

---
Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/pretaweb | linkedin.com/in/djay75



On 22/06/2013, at 6:31 AM, Dylan Jay <[hidden email]> wrote:

> On 28/05/2013, at 8:56 AM, Martin Aspeli <[hidden email]> wrote:
>
>> Hi,
>>
>> On 25 May 2013 01:20, Dylan Jay <[hidden email]> wrote:
>>>> A (transient) tile is saved entirely as a URL, with query string
>>>> parameters for configuration. That's relatively easy to move around.
>>
>>> not sure what you mean by move around.
>>
>> I mean, if the tile is referenced in an HTML tag in the theme, and is
>> fully self-contained within the URL that describes it, then it's easy
>> to move it around the page, move it from one theme to another, or move
>> it from one server to another with the theme, e.g. in a ZIP file.
>>
>>> My concern is if something like a listingview is to be included in a theme, currently everything in a theme can be downloaded as a zip and edited in a code editor. That is very handy.
>>> Editing a querystring is possible but not nice. Instead it might be better to have some kind of xml or yaml format?
>>
>> Don't invent multiple ways to store information. You end up having to
>> sync. plone.app.tiles provides a forms-based GUI for editing tile
>> parameters, persisting to a query string.
>
>>
>>> With listingviews you conceivably store it in the form of generated zpt which could be downloaded and used in fs code. However then you get into mixing generated code with custom code and it rarely seems to work out well.
>>
>> Generating a ZPT seems like an exceptionally bad idea. I can't see why
>> it would be necessary.
>>
>> My expectation was that we'd have a set of tiles, each of which is
>> effectively a view (a ZPT + some Python code), each encapsulating a
>> single use case with some configurable parameters. The parameters are
>> persisted within the URL that holds the tile reference, in the query
>> string. They are editable by a p.a.tiles GUI that uses this to expose
>> an edit form. Tiles render themselves with the relevant information,
>> using their configuration to decide e.g. what columns to render in a
>> table or what content to filter out. This is all pretty standard
>> plone.tiles stuff.
>
>>
>>>> There are some ways to make choices:
>>>>
>>>> - The 'display' menu
>>>> - Tags/keywords
>>>> - Content types (or 'categories' as Deco would call them)
>>>>
>>>> These are all valid. Personally, I think perhaps the content type
>>>> option is most logical. You choose what type you want before you
>>>> insert the item, as we can use per-folder type restrictions to
>>>> constrain the site's information architecture.
>>>>
>>>> The basic implementation of categories in Deco simply creates new
>>>> types in portal_types when a (super)user saves a new category of page.
>>>
>>> so in deco there is no dymamic views? so you want to change from one layout to another you have to delete and start again?
>>
>> With a Deco-managed page (which isn't the only kind of content
>> envisaged in a world where Plone ships with Deco, but possibly the
>> only out-of-the-box kind) you can change layouts by moving things
>> around in the Deco editor (if you have permission to do so). A
>> "category" is a predefined page layout with some default tiles. You do
>> "save as category" when editing a page, and et voilla you have a new
>> thing you can add in your site that will make new instances look like
>> this. This is how you drive consistency across the site.
>>
>>> I suppose that makes sense since you can add text tiles which is like adding schema fields, but then again, if you have a few variations on the layout with the same text tiles then it's pretty inflexible if there isn't an easy way to switch between them.
>>
>> Switching between layouts and preserving content is not always an easy
>> problem to solve, but there's no reason we can't have a UI element
>> that says "change category" that uses the new tile's layout. I don't
>> actually think it's a hugely important use case, though. Most of the
>> time, people will choose the category before authoring content.
>> Changing it after the fact is somewhat uncommon except if you make a
>> mistake (in which case the UI to choose the category in the first
>> place probably wasn't very good).
>
> It's reasonably common for users to change their minds about if they want table view, summary view or default view for a folder in plone.
> Losing that would be a shame.
> but anyway, thats off topic.
>
>>
>>> But thats off topic. You seem to be suggesting that we should limit to the way listingviews can be picked by the siteadmin to just catagory/type of page which seems limiting to me.
>>
>> Not necessarily. Per-instance is fine. I just wonder if the 'display'
>> menu or portlets are the right UI element to do it with. If you are
>> trying to package a listing view (which in my head would be a tile
>> with some configuration applied) into a theme, then you may want to
>> make that choice in the theme rules file.
>>
>> So maybe as a sketch, there's a conditional Diazo rule like:
>>
>> <replace
>> css:theme-children="#contentListingArea"
>> css:content-children="body"
>> href="./@@some.listing.tile?portal_type=Page&limit=10&extraFields=Subject"
>> css:if="$showsSomeListing"
>> />
>>
>> Here:
>>
>> - We are putting the body of the tile (remember, a tile is a full
>> HTML document where the `<body />` is the bit you show to the user)
>> into the area in the theme with id `contentListingArea`
>> - We invoke the tile by URL (and here use Diazo href support to do
>> the rendering). Parameters are passed on the query string (I've
>> imagined some inputs to a catalogue query for this example). This
>> would actually be built up using a forms-based GUI like the one in
>> p.a.tiles, of course, not hand coded, but once serialised it can stay
>> there.
>> - We only do this if a condition is true. Here, I've imagined a
>> parameter, which in turn may resolve to a TAL expression checking e.g.
>> the keywords/tags on a content item, its portal type, or something
>> else entirely. (Of course, for the rule to be conditional on a class
>> on the `<body />` of the content or some other rule condition would
>> also work)
>
>
> Sorry for being so slow getting back to you.
>
> So what you are seeing is that something like listingviews is a single kind of tile with parameters. The parramters being (in the case of a listing view)
> - which fields or expressions displayed about the context
> - which fields and expressions are displayed about each item in the list
> - batching options
> - which context object to use, or query to use for the listing.
>
> the difference here is that instead of the like deco the tile being created by editor/admin person in the content space it's created by the themer in the theme editor and connected into diazo using the href style rule as above.
>
> I can see this being useful in some usecases but it has some drawbacks. For example this is a good technique to replace "viewlets", snippets that are on every page or every content type and is in a *fixed location* on the page. e.g. last updated date, or a twitter share button that needs pull some hidden field out of the content item or context.
>
> Where I'd like to improve this is where the editor/admin person is given choice as to how they want something displayed. Listingviews was designed with the "display menu" in mind. Themer creates the view, gives it a name and the editor/admin can choose where they want to apply it. The ability for listingviews to allow a themer to create class names that edtiors use to mark certain parts of the page as needing a certain content in a certain layout is very important.
> In a deco based plone I guess this would covert to creating named tiles from preset params to more generic tiles. and then having the editor/admin place that new tile type on the pages they want.
>
> There are few specific things about your proposal that makes it hard to let the editor/themer choose where the a themer defined tile would go.
> The replace href diazo syntax doesn't allow you to replace elements from the content, only from the theme file. So the location of where on the page your tiles go essentually is precalculated. If it was possible to make rule like below then this would be different.
>
> <replace
> css:content-children=".mytilemarker"
> css:contenthref-children="body"
> href="./@@some.listing.tile?portal_type=Page&limit=10&extraFields=Subject"
>>
>
> If this kind of content to content transformation existed it would be very useful. It would mean a themer could replace plugins like collective.flowplayer. It would also mean you don't need that css:if="$showsSomeListing" which seems a ugly since the condition is no longer in the rules file.
>
> Also, since the view is not editable you'll want to use diazo to change it. So you will need more than one rule. So putting the params in the href perhaps isn't a good idea.
> Having listingview definitions named would make that easier
> href="./@@some.listing.tile?listing=mylisting"
>
>
> Another concern I have is the mental model for the themer is more complex. They have to now combine three plus pages into one, instead of just two. Currently they just have to get the right content onto the right content pages and then rearrange it. It's simple to understand and easy to debug since you can just render a page without a theme to what you need. To make what you suggest work I think you'd need some extra tools to help them render all the tiles along with each content page to make it easier for them to write their rules. I don't think thats too hard to do.
>
>>
>> All I'm trying to do is to keep things in one place. The assumption
>> behind this discussion seems to be that the reason someone might want
>> to make a "listing view" is as a complement to theming with Diazo,
>> where Plone on its own does not spit out the right data to make it
>> possible to fully implement the look and feel (or provide the specific
>> content) you want. That suggests to me that configuring and
>> associating (in general terms, e.g. by type or keyword or whatever,
>> not to specific content items) listing views is an activity tightly
>> bound into the activity of transforming and styling the rendered tile,
>> i.e. it's an activity that takes place with building a theme.
>
> listingviews are both tightly linked to not just the diazo theme but also content types. In some ways they make sense to be stored in the collection settings. Perhaps the custom fields part of listingviews is stored there and the views part is put in the theme.
> One idea we had with the custom fields was allow them to be optionally used as catalog metadata. The administrator could then choose calculation on write vs read. Thats something that can only be done if it's stored outside the theme.
>
>
>>
>> If that's the case, then having the configuration in "content space"
>> (e.g. "you must put this portlet here for this type of page to render
>> as intended with the theme applied") is brittle. And having one set of
>> controlling actions (say, a control panel) to configure an abstract
>> set of listing views, another to transform and style them (i.e. the
>> theme editor) and another to invoke it (i.e. in content space) means
>> it's easy to get confused and make mistakes.
>>
>> If we did end up with a design like the one I'm thinking about here,
>> it would have the advantage that we'd have come up with a generic way
>> to build tiles and pull them into a Diazo theme. This use case isn't
>> limited to listing views. You could imagine other things like, say, a
>> Twitter feed of a specific hashtag or whatever. This is the kind of
>> stuff that isn't content and is probably today done as portlets that
>> are placed very carefully and specifically once by an admin and then
>> never touched again. If, a year later, you come back to that portlet
>> and don't realise it's integral to the look and feel of the site (e.g.
>> the theme makes assumptions about it being there) then you may move it
>> or delete it, and if you are trying to propagate changes from dev to
>> test to prod you need to make careful content-space changes, possibly
>> manually.
>
>>
>> Your other explanation made me ask a few questions:
>>
>>> However listingviews in it's current form works like this (assuming it's moved into the theme editor)
>>> - themer creates "news" listing that includes the title of the current item + the title, link and publication date of all the content items.
>>
>> Can you explain how the actual listing is stored, e.g. a generated
>> ZPT, or some config that a generic ZPT looks at (if so, where), or?
>
> its stored in the registry as some config that a generic ZPT looks at.
> I did consider adding the ability to view a listingview definition as ZPT so you could copy and paste it as a quick way to get started with ZPT.
>
>>
>>> - the site admin drags a listingview tile onto an item, selects "news" from the list of views and defines the query to be the last week of news items.
>>
>> How is the association maintained?
>
> The example above is hypothetical as it doesn't yet work with tiles.
> However with portlets it stores the name of the view in the portlet configuration and looks up teh configuration from the registry.
> In the case of dynamic views it registers a special browserview with the name of the view in the name.
>
>>
>> Are listing views usually configured once and used for a single
>> content item, or re-used in multiple "similar" places?
>
> both. we use it for news listings in several places such as here http://www.ses.vic.gov.au/media/news
>
> Publications listing in combination with eea.facetednavigation. http://mhcs.nswgov.pretacloud.com/publicationsandresources#b_start=0
> and things like last updated portlets. We've also used it as a carousel portlet.
>
>
>>
>> Martin
>


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers