Ticket #10887 (closed PLIP: wontfix)
folder listing entry adapters
Reported by: | thet | Owned by: | thet |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | Cc: |
Description (last modified by thet) (diff)
Proposer: Johannes Raggam
Seconder: None as yet
The idea to this plip came up as a comment from Carsten Senger in PLIP #9327.
Motivation
The folder listing templates are among the most customized templates of Plone - especially when custom content types are used. When dealing with different packages which customize a folder listing, an integration (policy) package has to provide an overriding folder listing template to integrate all the features of those other packages.
There should be a way to provide overview templates for content types to be used in folder listings. This way, customizing folder listing templates should become unnecessary.
Proposal & Implementation
When rendering folder listings, for each brain IFolderListingEntry(brain) should be called - respectively the same for objects. If an adapter is found it will be used to render the folder listing entry for that brain/object. Otherwise an default fallback will be used, using standard fields and metadata (title, description, author, etc.). Overriding the IFolderListingEntry adapter should be as easy as unconfiguring and configuring it in zcml.
Deliverables
- Changing folder listings (folder_summary_view, folder_tabular_view, etc.) to be BrowserViews
- Creating an default fallback folder-listing-entry template
- Unit tests
- Localization
- Documentation
Participants
Johannes Raggam / thet
Progress
No progress until now.
Change History
comment:2 in reply to: ↑ 1 Changed 6 years ago by hannosch
Replying to vincentfretin:
Creating an adapter to write an entire table row is IMHO not a good idea. You should be able to just add a column to the table.
The PLIP is not about folder_contents, which is an entirely different beast, but about folder listing templates.
comment:3 follow-up: ↓ 4 Changed 6 years ago by hannosch
This PLIP sounds like it overlaps or is a duplicate of #9327, which has been almost finished. It should be clarified how these two relate to each other.
comment:4 in reply to: ↑ 3 Changed 6 years ago by thet
Replying to hannosch:
This PLIP sounds like it overlaps or is a duplicate of #9327, which has been almost finished. It should be clarified how these two relate to each other.
When reading #9327 and the code in https://svn.plone.org/svn/plone/plone.app.contentlisting/trunk/ it doesn't seem to me that it focuses on customizing folder listing entries. But the idea to this PLIP idea was discussed in #9327.
But davisagli pointed me yesterday to the folder_full_view and folder_full_view_item templates. I'm not 100% sure, but it seems that those can be used to provide a functionality as proposed in this plip. folder_full_view calls for every brain it gets getObject().folder_full_view_item(). It seems that in this context, folder_full_view_item() is the folder_full_view_item template itself. But if an object provides a method folder_full_view_item which returns a rendered template, that way folder listings entries could be customized. But it feels a bit like a hack. Lacking some interfaces which standardize that behavior and so.
comment:6 Changed 6 years ago by ldr
Perhaps folder_full_view could be made to work with views as well, by changing getObject().folder_full_view_item() to something like:
obj = brain.getObject() view = obj.restrictedTraverse('folder_full_view_item') return view()
At least if view lookup beats acquisition (which I'm not absolutely certain of).
comment:7 Changed 6 years ago by esteele
This PLIP has been declined for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +0 Craig +1 Elizabeth -1 Laurence -1 Martijn -1 Matthew -1 Rob +1 Ross --
The Framework Team had a lack of consensus over whether the proposed implementation is the best way forward, and over whether this should be in core. There was also some concern over performance implications. The recommendation is that discussion be opened to the developer community to help clarify the best path for solving the issue.
comment:8 Changed 6 years ago by esteele
- Status changed from new to closed
- Resolution set to wontfix
Creating an adapter to write an entire table row is IMHO not a good idea. You should be able to just add a column to the table.
I use z3c.table in my projects, it allows you to add a column with 7 lines of code in an existing table.
Here an example of a Modified Date column you can add to the folder_contents view only for ATFile:
The example is with grok, but you do it with zcml only of course.
Ah I wish the folder_contents was a z3c.table, customizations will be so much easier.