Ticket #9934 (closed PLIP: wontfix)
Add a text field to folders
Reported by: | davisagli | Owned by: | davisagli |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | Cc: |
Description (last modified by davisagli) (diff)
Adding a text field to folders is a simple improvement that will reduce the need for assigning default pages, which is currently a difficult thing to master in Plone from a usability standpoint.
Proposer: David Glick
Seconder: Alex Clark
Proposal
I propose adding a rich text field called 'text' to folders (identical to the one used for documents). The contents of this field would be rendered above the folder listing.
Motivation
Users often want to take a page and turn it into a section that contains other pages. This can currently be accomplished using the default page mechanism, but it is a multi-step and not-well-understood process to turn a page into a folder + contained default page. Adding a text field to pages would allow users to simply add a Folder in most cases, and decide later if it should contain anything.
In addition, this would provide the ability to give a rich text introduction to a folder listing, which is a commonly requested feature (already available for collections).
Assumptions
This proposal does not try to achieve a full unification of the page and folder types (which is assumed to be too invasive to happen before Plone 5), but attempts to make a simple, low-risk change with some clear benefits.
Implementation & Deliverables
- New field added to the folder schema in plone.app.folder
- Unit tests for getting/setting the field value
- Integration tests for viewing the text in folder listings
- Localization
- Documentation
No modifications to the folder listing templates should be required, as they already render a field called 'text' if it is present on the context object.
Risks
The addition of the 'text' field may be unexpected by add-ons that copy and extend the folder schema from plone.app.folder.
Participants
Alex Clark has expressed willingness to work on the implementation, with assistance from David Glick.
Progress
Not started.
Change History
comment:1 Changed 6 years ago by davisagli
- Description modified (diff)
- Milestone changed from 4.x to 4.1
comment:2 Changed 6 years ago by davisagli
- Owner set to davisagli
- Status changed from new to assigned
comment:3 follow-up: ↓ 4 Changed 6 years ago by eleddy
As a mega customizer of archetypes based on copying the base folder schema I am not a fan of this. I don't think the majority of people will use this but I understand the complications since I've addressed this a few times. There has to be a better way to enable this.
What happens to the description and what's the point of it if we add a text field? What about making description a rich text widget instead of a plain text field? I assume there is some catalog specifics doing something like that though...
Maybe this is better handled as a new content type which is based on a page but has a listing of contents at the bottom by default. These contents could be customizable like a collection/topic perhaps in the future even.
Another approach is to just add a new default view to either a page or a folder and make that work. A page can easily be templated to display siblings.
I'm throwing out lots of things because I really don't think this is required, although perhaps this opinion is too biased towards my own development needs (I like folder is fine as it is). I'm happy to brainstorm/discuss to find a non-schema change based way to solve the problem.
comment:4 in reply to: ↑ 3 Changed 6 years ago by davisagli
Thanks for your feedback, Elizabeth.
First, let me say that a large part of my motivation for submitting this PLIP comes from Joel Burton's comment here (and the one 2 below that one), where he claims that it would be a killer feature for many beginning integrators.
Replying to eleddy:
As a mega customizer of archetypes based on copying the base folder schema I am not a fan of this. I don't think the majority of people will use this but I understand the complications since I've addressed this a few times. There has to be a better way to enable this.
If the framework team supports this PLIP but doesn't want the text field to get applied to schemas that extend ATFolderSchema, the field could be added by a schema extender that only affects the Folder type.
What happens to the description and what's the point of it if we add a text field? What about making description a rich text widget instead of a plain text field? I assume there is some catalog specifics doing something like that though...
The description (now called 'summary' where it appears in the UI) is really intended for use where items appear in a listing in some other context. There has been some discussion of removing it's appearance on an item's main view altogether.
Maybe this is better handled as a new content type which is based on a page but has a listing of contents at the bottom by default. These contents could be customizable like a collection/topic perhaps in the future even.
I don't like that...a large part of the motivation for this PLIP is to reduce the need for people to think carefully about which content type they need to add up front...we want fewer content types, not more.
Another approach is to just add a new default view to either a page or a folder and make that work. A page can easily be templated to display siblings.
I'm afraid I don't quite understand how this would address the same problem?
I'm throwing out lots of things because I really don't think this is required, although perhaps this opinion is too biased towards my own development needs (I like folder is fine as it is). I'm happy to brainstorm/discuss to find a non-schema change based way to solve the problem.
Since this is a proposal for a .x release, I think the backwards-compatibility consideration for developers extending ATFolderSchema isn't something we can just ignore. As I said above, I think this could be implemented in a way that doesn't cause that problem.
comment:5 Changed 6 years ago by davisagli
I forgot to paste the link to Joel's comments: http://dev.plone.org/plone/ticket/9210#comment:12
comment:6 follow-ups: ↓ 7 ↓ 9 Changed 6 years ago by kleist
Quoting Joel: "Folder+DefaultPage is the same as this the page-ish folder?, but it's *very* confusing for many people to use default pages"
So: What if we simply made it easier to create Folder+DefaultPage? No change to the content types, but just a more streamlined workflow with fewer clicks and hand-holding of the user.
comment:7 in reply to: ↑ 6 Changed 6 years ago by davisagli
Replying to kleist:
What if we simply made it easier to create Folder+DefaultPage? No change to the content types, but just a more streamlined workflow with fewer clicks and hand-holding of the user.
Do you have a particular suggestion in mind?
comment:8 Changed 6 years ago by hannosch
One of the things we talked about for Plone 5, was to make all pages folderish to solve the "attachments" problem. Instead of having explicit fields for images or files referenced from a page, you would simply store them inside them.
Maybe the best option forward is indeed to create such a new folderish page content type now and leave both the existing page and folder as they are today. The main problem with this, is coming up with a good name for such a construct.
comment:9 in reply to: ↑ 6 Changed 6 years ago by elvix
Replying to kleist:
Quoting Joel: "Folder+DefaultPage is the same as this the page-ish folder?, but it's *very* confusing for many people to use default pages"
So: What if we simply made it easier to create Folder+DefaultPage? No change to the content types, but just a more streamlined workflow with fewer clicks and hand-holding of the user.
The default page construct is incredibly complex for users to grasp. The path out of that is already defined for Plone 5, tiles and Deco.
IMO a text field for folders would be a good addition. A lot of people using that (by customisations) alerady. It doesn't solve all scenarios, but it makes a few simple usecases much simpler.
comment:10 Changed 6 years ago by robgietema
I'm in favor of extending the current page to be folderish and not the other way around (let a folder have a textfield). This way you can create a basic text website by using pages only and use folders when you really want a container (like a photo gallery for example). The "view" method of the page can then be either "Document view" or any of the listing views a folder has (summary, tabular etc). This functionality is already build in the add-on: http://svn.plone.org/svn/collective/collective.folderishpage which we have been using for our clients for quite some time with success.
comment:11 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to wontfix
This PLIP has been declined for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +.5 Craig +0 Elizabeth -.5 Laurence +0 Martijn +0 Matthew -1 Rob +.5 Ross +1
The Framework Team was in disagreement over whether or not this is the best solution to the problem, particularly in light of the proposed Deco functionality being considered for Plone 5. collective.folderishpage was suggested as an interim solution for integrators looking to change the existing functionality.