[Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal
y.2006_ at wcm-solutions.de
Thu Feb 23 09:45:25 EST 2006
Hanno Schlichting wrote:
> 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.
CMF 2.0 does the same (at least for about 90% of the messages) and will
ship with automatically extracted pot files.
But I don't understand what this has to do with the statusmessages
product. As long as we just want to mark the message strings we can
still use the old machinery.
> 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 ;)
> 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
This sounds quite useful to me and I'd like to see that in CMF too.
> Second: It's possible two add more than one portal status
> message at the same time.
I'm not sure if this is an advantage. IMHO the status message should
provide a summary.
> 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?
I agree with your goals and I did consider similar solutions myself. But
the CMF 2.0 beta is scheduled for this weekend, so I did focus on what
can be done in that short time.
Besides the translate function everything I propose is done in the
CMFDefault skin and therefor not used in CPS or Plone. For now I don't
plan to add any API.
I'd love to see a more frameworkish solution in CMF 2.1 that uses the
query string implementation by default, but allows to use statusmessages
or a session based solution alternatively.
More information about the Zope-CMF