hard to customise listings

[djay]

User problem

If there is a listing of items such as search results, summary view, etc it's not easy to make simple change to this, such as adding a publish date to each content item listed. The current way would be create a diazo rule to replace the whole listing and rebuild it in rapido. This could be tricky if the search is coming out of collection for example.

Options

context arguments

Somehow make it easy to pass in an id or actual object into a rapido block so it can get data out of the and display it in the desired place in the listing.

e.g.

<append-after content:css="li.contentitem"  href="@@rapido/block/publishdate?item=${../@id} /> 

Not super efficient since you have to traverse the object again but at least its applicable to a large range of modifications as long as there some kind of url or id that can be used.

repeating tiles

idea from @ebrehault which is for a way to get tiles repeat so each tile still has the context of a single object. Then you can override a single tile instead of the whole listing.

It wouldn't help with replacing a single line in a tile because diazo doesn't get applied to tiles by themselves but to the whole page.

Could work in a few ways

A listing(view) tile

!. on a mosaic layout, click "a listing tile"

2. edit listing criteria
3. select a presaved listing style, or create a new one.
4. creating a new one lets you select a list of tiles to repeat and a lay them out. Could use tinymce and inline tiles directly dragged from the tinymce toolbar.

This is similar to https://github.com/collective/collective.listingviews except that instead of reinventing another set of small components that can pull data out of a result list, or object, it would use a tile for each field. (tiles might have to be adjusted to use a Brain instead of an object).

To override you copy that style of repeat tile and add, remove or change the subtiles. You can add a rapido tile write some python code.

meta-tile repeat settings

Similar to http://doc.orbeon.com/form-builder/repeated-grids.html. Where a repeat is a property of a row or tile. A repeat would have to be a new concept in mosaic, similar to a tile but instead is specifies how repeat a title or row, what html goes before and after. It would have to have some visual signal in the UI that a repeat has been applied. Repeats could be horizontal or vertical.

for example, to create a summary view:

1. User creates a row with a title tile, and a row with a description tile.
2. User selects both rows and clicks repeat.
3. User enters criteria for folder contents

The page would be similar to the old summary view. If too many items a paging bar would appear.

This allows for listings with editor customisable layouts per item.

Risks

repeating tiles

the current way tiles are called is via a subrequest to the actual object. Subrequests are expensive. Also waking up whole objects is expensive. Most listings use brains instead. To get around this, tiles that participate in listings would be need a lighter api that takes a dict like argument rather than a full object.

[datakurre]

Discussion at https://twitter.com/djay75/status/740419642771054592

The main disagreement between me and @djay seems to be that Dylan would like repeat to be native concept in Mosaic and I'd like this kind of behavior to be implemented as a configurable listing tile. The UX for both of these might be equal.

Some of my technical concerns about native repeat:

• "repeat" would add one more layer into Blocks transform (probably a new transform between panel and tile transforms, to expand repeat into the final paged listing of rows with tiles); while this complicates the transform chain, it's probably still the easiest part
• the current tile merge does not scale for this; even if we managed merge to fetch tiles in parallel, it might still be slow if rendering a page would require fetching hundreds of tiles; possibly a new "adapter lookup" based rendering is required for tiles within "repeat", but it would add even more complexity into transform and make the same tiles to be rendered with different ways in different context
• requiring to lookup and instantiate a unique view object for each field of each item in each row would have significant performance cost (when compared to current listing templates); especially the current plone.app.standardtiles.field would become a bottleneck

[datakurre]

@djay About the user story

1. User creates a row with a title tile, and a row with a description tile.
2. User selects both rows and clicks repeat.
3. User enters criteria for folder contents

Why this order? Why we should not require the user to start with 3., place a placeholder for the listing, and only add item representation into the listing. That would remove the requirement for multi-selecting items.

[djay]

@datakurre, I'll update details risks to show your concerns about performance and complexity. I'm more coming at it from a UX standpoint. Whats going to easiest to understand, and what is doing give the ability to create the most useful layouts. I think some of the performance issues can be fixed with some tweaks to tiles so they don't have to be called from a subrequest and expect an actual context object, but could instead get a dict like object via a more direct api. These things can be optimised and its probably a good idea anyway as it would make normal page loads faster. What if a page has 50 images on? Might be a good idea to load the view once and change params instead.

As for which is a better UX, I'm not sure. A listing tile has the advantage it can replace something like a news portlet, a small vertical list. But even with a listingview like tile, I'd like to replace the concept of custom field types with tiles since it would be weird to have two sets of things to display all teh fields on an object, in two different parts of the UI. A user might ask "if I install a tile which displays a facebook share link for an item, why can't I put that share link for each item in a listing?"

[djay]

@datakurre the reason I have the use case in that order is because you can select multiple rows. You could be a placeholder down first as long as it was clear you could put many rows and/or cells into that placeholder, or put it outside too.

The advantage of this option btw is that you can have a mixture of vertical and horizontal layout within the item that repeats. The editor gets to control that. Putting that flexabilty inside a listing tile means redoing mosaics inside a tile. Alternatively you could say layout of a listing item is always done via diazo (same as c.listingview), but thats not always what you want.

[datakurre]

@djay I'd suggest to do "mosaic inside a tile" for customizable content listing tile and save that "sub-layout" into a tile date instead of the more generic "repeat" abstraction. It's much easier and less risky to implement the repeat with optimized tile rendering inside a tile code, and that would not require any changes to the current transformchain.

Of course, any option would require work on Mosaic Editor anyway, so work to make its "WYSIWYG" editing more pluggable would be great. So, in this case user could at first drop a content listing tile with possibly customized query and then start dragging tiles into it directly in Mosaic Editor. Inside the tile there would be a new grid, so any item layout should be possible.

[djay]

You are right. Thats another way to think of it. Where mosaic allows you to drag a tile inside a richtext tile. Still not sure how grids inside grids would work though.

On Thu, 9 Jun 2016, 12:00 AM Asko Soukka notifications@github.com wrote:

@djay https://github.com/djay I'd suggest to do "mosaic inside a tile" for customizable content listing tile and save that "sub-layout" into a tile date instead of the more generic "repeat" abstraction. It's much easier and less risky to implement the repeat with optimized tile rendering inside a tile code, and that would not require any changes to the current transformchain.

Of course, any option would require work on Mosaic Editor anyway, so work to make its "WYSIWYG" editing more pluggable would be great. So, in this case user could at first drop a content listing tile with possibly customized query and then start dragging tiles into it directly in Mosaic Editor. Inside the tile there would be a new grid, so any item layout should be possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/plomino/rapido.core/issues/18#issuecomment-224657746, or mute the thread https://github.com/notifications/unsubscribe/AACi5F2upmtVveZ3kfsILowVM9BRNHzdks5qJvUbgaJpZM4IuDqj .

[ebrehault]

I do not know if we need to manage this tile repeatition thing using the Mosaic interface. It might be too complex. My point of view is we could use the tile approach into loops, but the loop would be implemented by code (in a template that could be edited TTW, for instance in Rapido, but also maybe in Mosaic layout editor). So something like:

<li tal:repeat="brain view/mysearch">
    <strong tal:content="brain/@@tile/title" />
    <p tal:content="brain/@@tile/description" />
</li>

[djay]

@ebrehault how does rapido replace the view? How does rapido access the underlying view code?

[ebrehault]

Rapido allows to implement an element that would return an array of items.

[djay]

@ebrehault not sure about that solution. It implies that if you have a listing preexisitng in plone somewhere then to change some aspect of it, you have to both recreate the query and that the listing in rapido. If you want the editor to specify the query similar to collections then this won't work. If you have complex code in the listing you are trying to modify, this is a lot of work to recreate this.

I think its worth exploring the idea that most listings in plone could be implemented with a kind of repeating richtext tile that @datakurre describes which has inline tiles. The editor can then edit the tile to change both what goes into each item and what the query is. And anything custom could be handled by a rapido tile. It would still require an efficient way to render tiles based on brains and without subrequest however otherwise it would be too slow.

[djay]

A motivating case from irc

Daniel Kraft (wam) BOT [2:03 AM]  
Hi, I know how to change the theme ttw for my plone 5 sites. But is it also possible to change the news-template ttw?

Adium User (cmcneill) BOT [2:05 AM]  
@wam What changes would you like to make?

Daniel Kraft (wam) BOT [2:06 AM]  
I'd like to have the lead image large and in full width

[2:06]  
so i think I'll need to change the template, because per default the mini image is shown.