Ticket #1961 (closed enhancement: fixed)

Opened 1 year ago

Last modified 3 months ago

Improve HTML rendering of document notifications

Reported by: gracinet Assigned to: gracinet
Priority: P2 Milestone: CPS 3.5.0
Component: CPS (global) Version: TRUNK
Severity: normal Keywords: notification subscriptions html image multipart related email
Cc:

Description

For HTML rendering of document based notifications, we'd need to

  • include some widgets (e.g, link to the document) in notifications only.
  • don't include some widgets in notifications.
  • embed images and CSS in multipart/related MIME structures

The cleanest way to do that would be to define a new layout mode, say view_email. For the first two use-cases, widget visibility conditions do already depend on the layout mode.

Also, the widget is aware of the layout mode at rendering time. Image widgets could then take approriate actions to store the image content somewhere for later inclusion in the final RFC 822 message.

Caveat: we'd have to define layout_default_view_email and a few declinations. Fortunately this will produce few ZPT duplication since layout_default_view does nothing but leverage a macro.

I'm leaving "CPS (global)" as a component, because this involves CPSSchemas (Image widgets), CPSDocument (layout methods), CPSSubscriptions (trigger with view_email layout mode, collection of image and css parts) and CPSUtil (improvement of mail sending utilities).

Change History

01/25/09 15:09:54 changed by gracinet

Not suited for 3.4, because third-party products might use a custom layout style prefix, and some of their subscriptions would possibly break.

03/19/09 18:08:45 changed by gracinet

Done in trunk, waiting for live testing to clos.

More implementation details:

  • the proper API to call is the new "renderEmail" method on CPSDocument class.
  • there is a new propery on FlexibleTypeInformation class to specify nethods to generate stylesheets, with default value and method derived from document.css. DTML methods meant for http requests break in this context because there is no request
  • only Image and Photo widgets have been enhanced ; subclasses have to be upgraded to benefit from the "cid" rendering (check docstring of getImageInfo). They shoudn't break if not.
  • the html harness is provided by cpsdocument_email_render.pt (hardcoded name in renderEmail()). It is therefore easy to amend for whatever standards compliance.

Follow-ups (feel free to create separate tickets if interested):

  • do an attachment rendering based on the same principles
  • add an expression on widgets to prevent "cid" or attachment rendering (use-cases: sensitive info, too big)
  • add widget-specific style sheets (related but technically different from #837)
  • if possible, create widgets to render the notification information (including comments) that's lost when rendering as html. Widget visibility conditions should make this very flexible.

12/21/09 00:40:39 changed by gracinet

  • status changed from new to closed.
  • resolution set to fixed.

It's been working for a while, closing for 3.5.0. Other developments will occur in the near future