Forgot your password?
New user?
Document Actions
#178: Return to using getIcon for content type icons
- Proposed by
- Michael Davis
- Seconded by
- Alexander Limi
- Proposal type
- Architecture
- Assigned to release
- Repository branch
- plip178-back-to-icons-as-images
- State
- completed
Motivation
For Plone 2.1, we switched to using CSS to display the content type images. This gave us some flexibility, but the main reason for doing so was to keep stuff outside of the portal catalog.
It has later been shown to me that our original assumptions of how this would affect the catalog were false (I thought it stored the icon itself, whereas it would only store the path to the image used as a string - a trivial addition).
The following problems exist with the current CSS-based implementation in 2.1/2.5:
- It bloats the CSS unnecessarily. In 2.1/2.5, this increased the initial page download weight of the average Plone page a lot, and although we have found ways of decreasing this, it still adds a significant amount of CSS.
- Browser bugs (Internet Explorer) requires us to us more CSS and twice the amound of markup to access the icons (we essentially need a "dead" wrapper class around the original one to avoid flickering on hover in IE6). This makes a lot of the initial attraction to this approach irrelevant.
- It's not possible to support different icons for the same content type (example: checked icon for a completed task, unchecked for an open task) with the CSS-based approach unless you do workarounds.
- Less magic - the current CSS icon approach is similar to the logo approach, where the logo is invoked via CSS in an obscure (for most people) manner. The element of least surprise is important for our integrators/customizer audience. It also removes the need to create dynamically generated CSS for this.
Proposal
This PLIP is in direct contrast to PLIP 132 - which advocates extending the current approach to work around the current deficiencies. We believe returning to the original approach is a lot more sane, and makes everything less complex.
- Remove all CSS definitions for icons for portal_types.
- Restore HTML generated icons based on getIcon method in portal_catalog (folder listings and navtree).
Implementation
When an object is cataloged within the portal, the getIcon method is called and indexed in portal_catalog with a string value in the form of: newsitem_icon.gif or portalName/newsitem_icon.gif.
Risks
Any site which has been customised to take advantage of CSS-generated icons would need to be re-customized.
This doesn't seem to be a common customization from casual observation (most people have no idea how the current approach even works in 2.1/2.5 ;), and no add-on products use the CSS-based type icons as far as we have observed.
Progress log
Done, except for a small migration step. I had to add getIconName as catalog metadata, as the existing getIcon stores the absolute ZODB path instead of just the icon file name. To prevent a restrictedTraverse call for each icon, I just added a small wrapper script. The existing getIcon metadata should probably be deleted, as it's unusable.
[fschulze]
Participants
Michael Davis
Alexander Limi
Florian Schulze
The things we spoke about
1. Originally we wanted to avoid loading inline images so the javascript onload stuff was executed earlier
- This is now not an issue anymore with the new JS trigger code that triggers once the DOM tree is loaded, before all the images have been downloaded.
2. The argument could be made that icons are style, not content, so the img tags don't belong in the markup.
- This is a bit of a "religious" statement, and the web just doesn't work this way. In any case, I don't see it as a major problem. With the current state of the browser market, some things are realistic, some things are not. ;)
Backport
This would allow:
- keep the same 'getIcon behaviour' across plone 2.0, 2.1, 2.5, 3.0. A product such as PloneExFile used to show the mimetype icon of uploaded file, this functionnality cannot be implemented under Plone 2.1/2.5
- those who wish to keep the behaviour introduced in plone 2.1/2.5 are not forced to 'switch again', they just don't install this backport product
My team would be ready to do this backport work, provided this PLIP is adopted and an implementation for plone 3.0 is available early. The latter point is specially important for ensuring consistency.
I agree
After talking to limi, I'm +1 on going back to img tags but storing the result of getIcon in the catalog.