Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
(WIP) hard to customise search/listings #239
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.
This is the use case eea.facetednavigation (and others) is designed to solve.
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
Some things that need to happen behind the scenes.
Somethings still to include
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
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.
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.
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 & plone.app.blocks. (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.