[Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal

[Hanno Schlichting]

Hi yuppie.

As the creator of the mentioned statusmessages product and the current
Plone i18n team lead I'm most interested in a general or at least
extensible solution to this.

The number one reason for the whole approach of the statusmessages
product was, that I wanted to use MessageID's (Messages) to mark all
portal status messages so they get automatically extractable. In Plone
there are dozens of these messages and time has taught us that nobody
updates any pot files just because he adds a missing dot in some message.

The second reason was indeed the same you mentioned: The problem of
third party products which currently have to use the domain of the
main_template. Message(ID)s are always translated in their own domain
thus eliminating this problem too.

Now the third thing the statusmessages product tries to solve is a
usability problem. Consensus in the Plone community has been that adding
portal status messages to the query string is bad as the URL should be
simple and bookmarkable and reloading a page which does not trigger an
action (like object deletion) should also not mention any message for
its success.

I think the third goal is something CMF should not enforce and is a
Plone specific detail, but the two aforementioned goals are general
valid ones.

So what I would like to see for CMF is a in the Zope3-way extensible
solution, meaning a very simple interface that I could adapt or overwrite.

The statusmessages product introduces a global utility to add portal
status messages to, but your implementation sounds a lot more like a
case for an adapter for the REQUEST and RESPONSE.

I had implemented the statusmessages product in this way first but
switched to a utility later as I needed a place to store the messages.

Of course I'm willing to help or relicense / integrate anything from the
statusmessages product in CMF if anyone should want this ;)

This is the interface for IMessage:

class IMessage(Interface):
    """A single status message.
    """

    message = Attribute('The text of this message. Usally a Message
object.')

    type = Attribute('The type of this message. Used to differentiate
messages by css styles.')

A short snippet of one of my older tests looked like this:

from Products.statusmessages.interfaces import IStatusMessage
from Products.statusmessages.statusmessage import STATUS_KEY

def testAdapter(self):
    request = self.app.REQUEST
    status = IStatusMessage(request)

    # the second parameter is a type argument
    status.addStatusMessage('test', 'info')
    self.failUnless(request[STATUS_KEY]==status.getStatusMessages())

    status.addStatusMessage('test2', 'warn')

    # show returns and implictly deletes the messages
    messages = status.showStatusMessages()
    self.failUnless(len(messages)==2)
    self.failUnless(len(status.getStatusMessages())==0)

The whole never really polished code is at:
http://svn.plone.org/svn/collective/statusmessages/branches/initial-implementation-as-adapter/

It enhances the current implementation in two ways: first status
messages have an additional type argument which can be used to
differentiate them by css styles. Typical values are 'info', 'warn' and
'error'. Second: It's possible two add more than one portal status
message at the same time.

Of course the above mentioned code stored the messages directly in the
REQUEST instead of the query string and was only implemented as a
fallback mode where the usual way would have been to use sessions but it
should mainly show the approach using an adapter for the BrowserRequest.

Both additional features don't have to be implemented for CMF but could
be added through the Plone specific add-on module.

Now what's your opinion on encapsulating the translate/charset mangling
in such a way?

Yours,
Hanno

yuppie wrote:
> Hi!
> 
> Currently the portal status message is always translated in the i18n
> domain of main_template if sent through a redirect. This makes it
> impossible to use different domains (and mappings or defaults).
> 
> Add-on products might want to use their own i18n domain. CMFCalendar
> demonstrates that use case. "Event changed." is currently not translated
> because of that issue.
> 
> There are more sophisticated approaches than using the query string for
> status messages. Depending on your needs sessions or the statusmessages
> product (http://dev.plone.org/collective/browser/statusmessages) might
> be more appropriate.
> 
> But I'd like to keep the solution used in CMF simple and don't want to
> create any dependencies on third party products. So I propose to resolve
> the issue like this:
> 
> 1.) Translate portal status messages and encode them with
> default_charset before they are added to the query string. To make this
> easier I'd like to add a translate function to CMFDefault utils.
> 
> 2.) Decode the messages again before they are passed to the
> main_template. No longer use i18n:translate="" in the template.
> 
> Comments are welcome! If there are no objections I'll implement this on
> the trunk before the 2.0 beta release.
>