Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

(WIP) hard to customise search/listings #239

djay opened this Issue Aug 19, 2016 · 7 comments


None yet
4 participants
Copy link

djay commented Aug 19, 2016

user problem (motivation)

There are several related use cases that can perhaps be solved collectively.

Customise listings in display views for collections/folder and collections portlet

comes from - collective/rapido.core#18

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 repeat listed. Or adding a lead image to each repeat. Most commonly people are asked to override the templates using jbot but these are very complex templates.

The is the use case collective.listingviews is designed to solve

Custom search forms

Either customising the default plone search page to add another criteria, or change the listing.
Or to create filtererable listings, or custom search pages in other parts of the site.

This is the use case eea.facetednavigation (and others) is designed to solve.

Implementation options

Mosaic forms

Idea is to replace eea.facetednavigation, collective.listingviews, plone search viewlet and advanced search pages. It could potentially be used for a forms solution to replace ploneformgen.

Scenario: Create image search page

  1. Start with empty mosaic page
  2. Drag a new search tile to the top. Select "title" as search field from drop down (comes from catalog).
    • Set a form id of "image_search" and destination of "." on title search title.
  3. Drag a new filter tile to the layouts left side.
    • Select filter by keyword. Select show totals.
    • Pick form id and destination as same as the title search tile from the list of forms on the page.
  4. Drag a new listing tile to the center.
    • select fixed criteria to be only search for images in current subpath
    • tick "accept search criteria from forms"
    • set page size to 20
    • set a tile style to be "repeating blocks"
    • listing tile is a rich text tile in edit mode and comes by default with title and summary inline field tiles. listing tile richtext is the text to repeat.
      • inline tiles use tinymce noneditmode to allow them be dragged around the rich text.
      • inline lines are just normal tiles stripped of their grid and block, instead put in a span.
      • They are edited in a popup rather than inline.
    • the listing tile provides a special fake context for the inline tiles which would be the first item in the real list so title and summary displayed appear to be real. If no default results possible, then each inline tile knows how to show a generic example data.
  5. drag a normal leadimage tile into listing tile. Configure its size. Since the folder already has images in, it displays the first image.
  6. rearrange the inline tiles so leadimage is on top, title below, and remove summary tile.
  7. Save the page layout and view. All images in the folder are repeated as blocks.

Some things that need to happen behind the scenes.

  • browser layer to add in the form tags.
  • convention to share results via a request
  • inline tiles (using tinymce noneditable mode)
  • ability to drag tiles into a richtext tile to make an inline tile
  • fake DX objects from brains. ie ability to call a tile using a brain and have it transparently use cache data in the brain without waking the object.
  • ability to reuse a fake request in subrequests to they aren't so expensive in a listing.

Somethings still to include

  • how to have lists, repeating table rows etc.
  • how to have calculated fields (probably via rapido tiles).
  • how to have validation errors prevent a listing (probably need an validation tile which displays the errors and sets stuff in the request so the result
  • how to ensure the result/listing tile is evaluated last?
  • how would "all content" display view replacement work? then you'd have grids inside grids?
  • what happens if you have different two forms on the same layout that overlap? some kind of error /warning when setting the formid perhaps?
  • what happens if you have a inline richtext tile inside a richtext tile? means we have to put tinymce into a popup? or maybe we can make inline tiles inline editable by allowing editable contents within a noneditable span? (this is possible). Would this allow inserting reusable richtext snippets like uwosh.snippets?
  • how to control the layout of paging controls? should that be a seperate tile? how does that communicate with the results listing?
  • how does the communication between tiles work if edge caching is used? Would need to replace passing things via a request with some kind of session?
  • How to replace a contact form/PFG? Generic input fields + a submission tile? Could be an email submission tile, a rapido tile for scripted submission, or a DX adapter tile to save into a content object. Thank you page is a richtext tile with readonly field tiles to display back submitted data.
  • How to make a form use AJAX? one nice thing about eea.facetednavigation is you can get it to update a listing via AJAX as soon as you change a field. Perhaps another option when you enter the fromid, destination?
  • How to make a custom laid out "alias" tile using a listing tile set to only show a single item and inline tiles.

based on ideas from @djay @datakurre @ebrehault and collective/rapido.core#18

@djay djay added this to the Mephisto Sprint 2016 milestone Aug 19, 2016


This comment has been minimized.

Copy link
Member Author

djay commented Aug 21, 2016

Made a short prototype of how easy it could be have a custom search page using mosaic.


Now need to work out how to make the listing easy to customise.


This comment has been minimized.

Copy link
Member Author

djay commented Sep 12, 2016

Made a short prototype of how inline tiles could work. You can drag a tile into a text tile, and eventually drag one out again. To make it work properly you would need to pause over the text tile before dropped to switch it from "drop next to this tile" mode, to "drop into this tile" mode.

Inline tiles are useful by themselves.

but for search purposes the final bit of the puzzle would be a listing tile which acts like a richtext tile, allowing you to drop field tiles into it, rearrange them, and edit listing criteria. It will then repeat the resulting custom layout. Combined with the search tiles, we have drag and drop to customise your search based landing pages.


This comment has been minimized.

Copy link

pigeonflight commented Oct 5, 2016

+1 I think this is the right direction, it is closer to what end users are expecting for form development nowadays.


This comment has been minimized.

Copy link
Member Author

djay commented Jan 25, 2017

@pigeonflight the scope was just search and listings, not form development.


This comment has been minimized.

Copy link
Member Author

djay commented Feb 2, 2017

I am proposing this as a GSOC topic


End goal is to provide an intuitive and flexible system for creating different kinds of listings in plone and different kinds of search/faceted navigation pages in plone. It would replace eea.facetednavigation, c.listingviews and plones inbuilt search, advanced search and collections.

The motivation is that beyond editing and laying out a page, customizing listing pages and creating new complex search pages are two of the most commonly requested tasks. This should be possible by a non technical person online with minimal training. By doing so we enhance plones reputation as being easy to customise and potentially expand its audience. For this reason this task is strategic.


The plan as outlined in #239 is to make changes to mosaic first. Namely

  1. Inline tiles. The ability to drag tiles inside (and out of again) a richtext tile. This makes tiles more flexible because tinymce layout capabilities can be used in addition to the grid making more layouts possible. Stringing together small tiles for calculated values for example todays_date or last_author become possible TTW.
  2. Rework the existing listing tile so it appears as a richtext tile for customising the repeated block by arranging inline field tiles as needed. Adding a lead images to each item is as easy as DnD.
  3. Change mosaic so it can optionally work as a form. Various form tiles similar to what eea.facetnavigation has available.
  4. Installer such that you can optionally replace plones build in search and advanced search.


jquery skills to work with the existing mosaic code base. Python skills to work on the layer changes for inline tiles (but perhaps this could be done with someone else?)


Dylan Jay, Asko Soukka (@datakurre)


PR to mosaic, p.a.tiles and associated dependencies.


This comment has been minimized.

Copy link

cewing commented Feb 3, 2017

Great write-up, @djay. I'll include this in the 2017 GSoC listing


This comment has been minimized.

Copy link

datakurre commented Mar 11, 2017

I'm sorry for being a bit late here. And was a bit surprised to be listed as a mentor. I could mentor, but based on my previous GSOC mentoring experience, I would guide the possible student to a much more limited goal instead (unless they happen to be already professional level experts in Plone and Mosaic). collective/rapido.core#18 is essential reading here. The user problem is real, but the implementation is not trivial due to technical details of Mosaic.

TL;DR; MVP for this would be a "content listing item editor" widget pattern for content listing tile edit form (Javascript). The saved "listing item layout" would be interpreted into tal and rendered in a single Python tile (Python, TAL). This MVP would scope the result to be a pull for Even better, it should also work as an additional behavior for Collection type of and would allow a PLIP for merging this into core as soon as the feature is ready and tested (no Mosaic dependency).

At first, the idea can be splitted into to separate topics: 1) TTW search forms and 2) TTW content listings. I'd propose to focus on TTW content listings at first, because forms with Mosaic have unsolved design issues: tiles should be independent by design. Interdependent tiles are something not covered by current design of plone.tiles & (That said, the Collection version could be trivially turned into a search form without the issues related to tiles.)

Then about content listings. TinyMCE based crafting UI sounds good, but making the current tiles and Mosaic editor to support tiles both inside and outside of TinyMCE might be too hard (all TinyMCE related is already quite complex in Mosaic). Then the designed repeatable item should be interpreted into TAL and rendered as a single tile (in tal:repeat block as with the current listings). I'd guide to start with a TinyMCE based widget pattern (or draft.js if the widget was written in react) for textarea field, which would work in a content listing tile edit form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.