[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - Wrong cache association for FSObject, [Pending] http://www.zope.org/Collectors/CMF/255 - CMFSetup: Windows exports contain CR/LF, LF and even CR newlines, [Pending] http://www.zope.org/Collectors/CMF/266 - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - CMFSetup: Workflow Tool export fails with workflows which have scripts, [Pending] http://www.zope.org/Collectors/CMF/373 - CMFCore.Skinnable.SkinnableObjectManager can merge skin data, [Pending] http://www.zope.org/Collectors/CMF/375 - Proxy Roles does't work for a Script using portal_catalog.searchResults, [Pending] http://www.zope.org/Collectors/CMF/380 - WorkflowAction deprecated warning should not printed for WorkflowMethod, [Pending] http://www.zope.org/Collectors/CMF/388 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - path criteria on Topic should honor VHM, [Pending] http://www.zope.org/Collectors/CMF/111 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - Add condition for transition's action like other action, [Pending] http://www.zope.org/Collectors/CMF/207 - Major action enhancement, [Pending] http://www.zope.org/Collectors/CMF/232 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 - First Day of Week, [Pending] http://www.zope.org/Collectors/CMF/400 ___ 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
[Zope-CMF] Re: using GenericSetup to add non-content objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi Rob! Rob Miller wrote: i'm trying to use GenericSetup to add tool-like objects to my site at creation time. i say tool-like because the objects in question (RAM and HTTP cache managers) act as tools, but they have constructors that require additional arguments... the current tool.py importer assumes that the constructor for a tool doesn't take any arguments. neither is the content importer appropriate, since these aren't content objects. is there some straightforward way to add arbitrary objects to the root of the site that i'm missing? if not, how would folks feel about some slight changes to the tool.py to allow for additional constructor arguments to be specified? on a related note, i'd also like to allow tool titles to be specified in toolset.xml. anyone have a problem w/ this being added to tool.py? RAM and HTTP cache managers just require the object id as argument. +1 for fixing this id issue in the toolset handler. But everything else like titles are properties of the tool itself that have nothing to do with the container and might need tool-specific setup code. Allowing to set arbitrary arguments in 'toolset.xml' violates the current structure of the profiles. So -1 for supporting other arguments than id. Agreed. I think there is support for an optional tool ID lying around somewhere in there; maybe I dropped it on the floor? As a workaround for tools which require extra arguments, but for which several possible stock configurations are possible, one could register a factory other than the class itself (this won't scale against large numbers of arguments or possible values, obviously). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/aOl+gerLs4ltQ4RAvSnAJ9lHOG5l1lcvTsQIoOF3lISQ2CyEACfV3eK +pMbl+rfh1Pq2NCX5p4IgYc= =qivj -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal
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
Re: [Zope-CMF] [dev] Portal status messages and i18n: a proposal
On 2/23/06, yuppie [EMAIL PROTECTED] wrote: 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. Afaik, using MessageIds solves this. If it doens't, that's a bug. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
[Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal
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
