Ticket #9270 (closed PLIP: wontfix)
Stop using fill-slot column_one_slot and two in standard templates like (login_form, sitemap, search )
Reported by: | maartenkling | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Templates/CSS | Version: | |
Keywords: | Cc: | benglynn, plip-advisories@… |
Description (last modified by maartenkling) (diff)
Motivation
Let users decide for them selfs if they want a column-one or two or not in the default templates.
Proposal
Remove:
<metal:block fill-slot="column_one_slot" /> <metal:block fill-slot="column_two_slot" />
From templates:
author, default_error_message, join_form, logged_out, login_failed, login_form, personalize_form, search_form, search, sitemap, and all the rest
Implementation
Remove 2 lines from default templates.
Risks
Column one or two shows up when people are now used to not seeing the column on the above templates.
Change History
comment:2 Changed 7 years ago by benglynn
- Cc benglynn added
I completely agree that the templates described above should not simply wipe out the columns with empty fill-slot elements. There are two global variables, sl and sr, which predict whether a column is needed, and these are useless on these pages.
I found this particularly frustrating when implementing table-less layouts (for phone friendly pages for example). Here, it helps to indicate the number of columns in a body class so the variables sl and sr need to always be accurate. If lower templates wish to force a column to disappear, they should influence the values of these variables.
There is a workaround which I use that means that none of the page templates described above need to be customised. While a more tidy fix should be found going forward, this works with the current templates and may help inform a more permanent solution.
In short, define two initially false, global booleans; for example show_l and show_r. The slots column_one_slot and column_two_slot no longer wrap columns; instead, they each wrap one tal:define, respectively setting show_l to sl and show_r to sr. Each column now has a tal:condition of show_l or show_r.
This set up means that wiping out the slots in lower templates has the affect of setting show_l or show_r to false. This is true of course for the templates mentioned above, or for any you go on to make or customise yourself. You can now render an accurate body class for your CSS, confident that it will always be correct.
comment:3 Changed 7 years ago by pupq
I actually think it probably makes strong sense, UI-wise, to hide those portlets on search, sitemap, and other places.
It's good to have some places where we hide them--this provides an important example of "discoverability"--people notice "the columns are hidden on the sitemap; I wonder how they did that, cause I want that same feature on my page... ah!". This is one of the most pleasant and positive ways people learn, so we should try to reward it if we can.
Of course, we should do it in a way that doesn't hurt tableless themes, so perhaps the implementation of how this done should change.
comment:4 Changed 7 years ago by limi
I would be -0 on doing this. It's a dangerous things to say "everything will change in an upcoming release anyway" — but I do think that is the case here. We're moving away from the whole column/slots approach in Plone 5, and introducing this in Plone 4 seems to have the potential for unexpected consequences for people upgrading.
I think it's too little gain a little bit too late to do this in Plone 4 — but I'm happy to be proven wrong.
(Please note that I am not on the framework team, so my vote doesn't really count :)
comment:5 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:7 Changed 7 years ago by MatthewWilkes
While I agree with Ben Glynn that this causes problems for tableless themes, it's not a good enough reason to just remove this part of the UI.
To be honest, I think Ben's code would be a good bug fix for 4.x, but it might need its own PLIP.
But, to be clear, on this PLIP, FWT Vote: -1
comment:8 Changed 7 years ago by alecm
I'm in agreement with Joel that there are good UI reasons for the current behavior and simply adding back that column would be a mistake. If addressed correctly, as Matthew says, this could be considered a bug fix.
FWT vote: -1
comment:10 Changed 7 years ago by davisagli
FWT vote: -1
comment:11 Changed 7 years ago by raphael
FWT vote: -1 for the reasons stated above
comment:12 Changed 7 years ago by calvinhp
FWT Vote: -1
comment:13 Changed 7 years ago by esteele
- Status changed from new to closed
- Resolution set to wontfix
Rejected by FWT vote.