#178: Return to using getIcon for content type icons

Contents
  1. Motivation
  2. Proposal
  3. Implementation
  4. Risks
  5. Progress log
  6. Participants
by Alex Limi — last modified Jan 21, 2010 07:27 AM

Aka. as "the un-PLIP", this proposal advocates changing back to the earlier approach used for content type icons in Plone.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

Comments (4)

Florian Schulze Aug 28, 2006 09:02 PM
After talking to limi, I'm +1 on going back to img tags but storing the result of getIcon in the catalog.
Alex Limi Aug 29, 2006 12:35 AM
The following two things were discussed:

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. ;)
Bertrand Mathieu Aug 31, 2006 04:39 PM
When this PLIP will be implemented for Plone 3.0 I consider useful to create a backport for Plone 2.1 and 2.5, as a 3rd-party product.

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.
Geir Baekholt Nov 23, 2006 10:26 AM
This is going to break Right-to-Left language support, right ?