Hi Hanno!
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.
Agreed.
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 ;)
Great!
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'.
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.
Cheers,
Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
