collective.listingviews allows a Plone site administrator to quickly create a new display
view their content types, folders, collections and eea.facetnavigation. It will also let you create
- Go to Site Setup > Listing Views.
- Select the fields you want to display and give your view a name and class tag. Pick which content types this view will be available to.
- Once you've added your view definition you can use the "Display Menu" or "Listing view portlet" to apply this view where you want. If you use it on a folder or collection it display a list items with just the fields you defined. If you use your view on a single item, it will display a list with a single set of fields. If you use a portlet, you can either point it to a fixed item, folder or collection, or it will display the content of the current context.
- If you require further customisation: use diazo to customise the layout/html of your fields or you can use custom fields via "Site setup" if you need combine field values, format a value or access plone api's.
For example you could
- create a news listing which displays the first sentance and publish date of each news item
- create a footer portlet for each page which displays the last updated date of the current content
- create a portlet which grabs a random image from a folder
- create a listing of folders which contain pdfs of different languages and display links to each version of the pdf.
This plugin is very flexible and can be used to:
- create custom views of folders or collections that include metadata and content from contained or matching items;
- create custom listing portlets with additional information such as lead images, publication dates or authors;
- create listing views with subqueries or python via TAL expressions;
- create additional views of non-folderish content items, showing other aspects of the content;
- create portlets to display information about the current item such as last updated date, or even the whole content replacing plugins like ItemViewPortlet;
- create custom listings for
Listing Views are designed to be simple to create quickly on a Plone site and avoid the complexity of creating custom page templates or overridden views for many common cases.
View definitions are created inside the Plone Site setup by TTW developers.
Content editors can apply the views to content items via the
Display Menu for content or in a
Listing View Portlet for portlets
(and in the future in a
Content Listing Tile).
The HTML markup used by the view is simple and designed to be easily adapted to your needs using CSS or Diazo. Each view consists of:
- a definition list of fields of the target or context content item;
- a list of definition lists of fields for each the listed items if the target or context is a folder, or collection;
- unique CSS classes for the lists and each field type.
By default Fields that can make up a ListingView are :
- Any Metadata fields stored in the catalog (e.g. Title, Effective Date)
- Some Metadata fields with formatting applied (e.g. Title (Link), Effective Date (Date & Time))
- Any custom TAL expressions
There is a known issue which breaks widgets when editing listing views. This is due to a regression bug in z3c.form 3.2.3 which ships with Plone 4.3.5 and 4.3.6.
You will need to pin a different version of z3c.form. Add the following to versions:
[versions] ... z3c.form = 3.2.4
(If for some reason you need to pin an older version of z3c.form you should be fine. Just stay away from the 3.2.3 version)
See the `doctests for a worked example`_
Development is at http://github.com/collective/collective.listingviews
Initial development was funded by PretaWeb.
We have some ideas on where this could go:
- Nicer GS import/export. Currently uses plone.app.registry.
- Safe HTML filtering for all fields. Currently not implemented.
- Support plone.app.contentlistingtile for Deco or
contentlistingtileallows custom views to be selected so this should be simple.
- Preview/export as ZPT. This provides a way to learn ZPT and a base to start from when more complex views are needed.
- Debug custom fields. Allow selection of content to test fields quickly.
- Migration of views. Provide a way to make bulk changes in content from one listingview to another listingview. This would allow a new "template" to be created and tested and then switched in production.
- Support customisation of batching settings.
- Allow GET requests so that the list can act as a custom search listing page.
- Support grouping.
- Support hierarchical listing. Allow navigation portlets, sitemaps with additional fields. Maybe different kind of views? Maybe allow views to be used as fields within other views?
- Support AJAX batching and infinite lists (auto-load next when scrolled down).
- Reuse TAL on different fields. The TAL becomes a formatter function instead of a field; e.g. convert date or turn Title into link. Functions let you select with fields they apply to, or apply to whole item (i.e. custom field).
- Pre-calculate custom fields, i.e. add them to catalog metadata.