[Zope-CMF] Re: [dev] content factories and events - a proposal
Hi! Wichert Akkerman wrote: Previously yuppie wrote: Here are my assertions: a) The right place for calling notifyWorkflowCreated() and indexObject() is the event handler for IObjectAddedEvent. _setObject() sends this event by default. b) Oldstyle factory methods are not responsible for setting the portal type. They call _setObject() to early for sending IObjectAddedEvent because the portal type might be wrong at that moment. Proposed changes: 1.) Let's get rid of _finishConstruction(): Using newstyle factories we should set the portal type *before* calling _setObject(). notifyWorkflowCreated() and reindexObject() should be called by the event handler. 2.) Fix *all* oldstyle factories: They don't finish content creation, so they should not send the events. Since ScriptableTypeInformation factory methods don't call _setObject() directly, this affects only file system code. self._setObject(id, o) Has to be replaced by: self._setObject(id, o, suppress_events=True) In each factory of each third party content type. I don't like that, but it is the only solution I see that allows us to use the events correctly. 3.) For oldstyle factories, set the portal type after calling the factory and send events after that. Unfortunately We can't send the IObjectWillBeAddedEvent because we don't know the object before it is added. 4.) For newstyle factories, also set the portal type, but let _setObject() send the events. 5.) Modify handleContentishEvent(): Add the notifyWorkflowCreated() call for IObjectAddedEvent. indexObject() is already called. Any comments? Questions? Objections? This change broke Plone: Plone has a routine that constructs new content objects while bypassing parts of CMF which now breaks when it tries to call _finishConstruction. There is no BBB code because _finishConstruction is an internal underscore method. If we agree that factory methods should not send events this change is not sufficient: http://dev.plone.org/plone/changeset/18899 1.) suppress_events=True has to be used in oldstyle factories 2.) your code has to send the IObjectAddedEvent as well If you think that change needs better documentation or BBB code, please let me know. 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
Re: [Zope-CMF] [dev] content factories and events - a proposal
Previously yuppie wrote: > Hi! > > > We still have no easy way to use add views for CMF content. I tried to > figure out what needs to be done to make CMF content creation more > generic and to avoid duplicate notifyWorkflowCreated and (re)indexObject > calls. > > > CMF uses two kinds of factories: > > Oldstyle factories are used by FactoryTypeInformation if 'product' is > specified and by ScriptableTypeInformation. They are black box factory > methods that create unfinished content (no portal type set) and add it > to the container. > > Newstyle factories are used by FactoryTypeInformation if 'product' is > not specified. They are zope 3 style factories. The code using these > factories is responsible for setting the portal type and adding the > content object to its container. > > Both currently depend on the _finishConstruction() process that sets the > portal type and calls notifyWorkflowCreated() and reindexObject(). > > > Here are my assertions: > > a) The right place for calling notifyWorkflowCreated() and indexObject() > is the event handler for IObjectAddedEvent. _setObject() sends this > event by default. > > b) Oldstyle factory methods are not responsible for setting the portal > type. They call _setObject() to early for sending IObjectAddedEvent > because the portal type might be wrong at that moment. > > > Proposed changes: > > 1.) Let's get rid of _finishConstruction(): Using newstyle factories we > should set the portal type *before* calling _setObject(). > notifyWorkflowCreated() and reindexObject() should be called by the > event handler. > > 2.) Fix *all* oldstyle factories: They don't finish content creation, so > they should not send the events. Since ScriptableTypeInformation factory > methods don't call _setObject() directly, this affects only file system > code. > self._setObject(id, o) > Has to be replaced by: > self._setObject(id, o, suppress_events=True) > In each factory of each third party content type. I don't like that, but > it is the only solution I see that allows us to use the events correctly. > > 3.) For oldstyle factories, set the portal type after calling the > factory and send events after that. Unfortunately We can't send the > IObjectWillBeAddedEvent because we don't know the object before it is added. > > 4.) For newstyle factories, also set the portal type, but let > _setObject() send the events. > > 5.) Modify handleContentishEvent(): Add the notifyWorkflowCreated() call > for IObjectAddedEvent. indexObject() is already called. > > > Any comments? Questions? Objections? This change broke Plone: Plone has a routine that constructs new content objects while bypassing parts of CMF which now breaks when it tries to call _finishConstruction. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
Re: [Zope-CMF] Re: Decode for Record objects
Am 10.01.2008 um 13:13 schrieb Hanno Schlichting:
ZPT uses Unicode internally in Zope 2.10 and newer, so you need to
decode your non-unicode values before passing them into a Page
Template.
... using something like CMFDefault.utils.decode() assuming it knows
how to handle the particular object it is receiving.
My current bugbear is that {result/lastname}"> behaves differently to (result['firstname'], result['lastname'])">
I think this is a ZPT bug but haven't been able to delve deep enough
to confirm this and provide a test and posible fix. It looks like I
might have some time next week.
Plone hacks the TAL engine in horrible ways so you can still use
utf-8 encoded strings as well, but I wouldn't recommend this
approach for a small application.
While I'm currently working on a Plone site most of my work is Zope +
CMF
However, I think the error is raised because utils.decode simply
returns any values untouched it doesn't know what to do with which
is why I think it might be worth extending. OTOH it might
something that is better fixed in the Shared.RDBMS.Results module
The database connection layer is the I/O boundary in this case and
the decoding to Unicode should happen here. Pretty much all code in
Zope2's SQL or database layers doesn't do this and I haven't seen
much interest from anyone to fix this.
No, there isn't much interest in fixing anything on the Shared.RDBMS
side which is a pity because Zope is really good for RDBMS
integration. Personally I'm very interested in improving this side of
things like using positional parameters. Is
Shared.RDBMS.Results.Results a good place to start so that the
various DAs don't need to worry about it.
I'd highly recommend using one of the approaches based on
sqlalchemy, as otherwise you'll probably end up fixing a number of
bugs and adding missing features to the various products
responsible for Zope2's current DB interconnection features.
As I said, the mxODBC Zope DA actually has the methods to do this
but, because of missing security declarations, you currently can't
call them from restricted code but this is going to change in the
next release.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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: Decode for Record objects
Charlie Clark wrote: If I have non-ASCII data in an RDBMS that I wish to use in a CMF site or even straight ZPT's you get a UnicodeError when accessing the non-ASCII Values which you get around using the decode utility. ZPT uses Unicode internally in Zope 2.10 and newer, so you need to decode your non-unicode values before passing them into a Page Template. Plone hacks the TAL engine in horrible ways so you can still use utf-8 encoded strings as well, but I wouldn't recommend this approach for a small application. However, I think the error is raised because utils.decode simply returns any values untouched it doesn't know what to do with which is why I think it might be worth extending. OTOH it might something that is better fixed in the Shared.RDBMS.Results module The database connection layer is the I/O boundary in this case and the decoding to Unicode should happen here. Pretty much all code in Zope2's SQL or database layers doesn't do this and I haven't seen much interest from anyone to fix this. I'd highly recommend using one of the approaches based on sqlalchemy, as otherwise you'll probably end up fixing a number of bugs and adding missing features to the various products responsible for Zope2's current DB interconnection features. Hanno ___ 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] CMF Tests: 11 OK
Summary of messages to the cmf-tests list. Period Wed Jan 9 12:00:00 2008 UTC to Thu Jan 10 12:00:00 2008 UTC. There were 11 messages: 11 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:31:51 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007586.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:33:21 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007587.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:34:51 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007588.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:36:22 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007589.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:37:52 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007590.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:39:22 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007591.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:40:52 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007592.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:42:22 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007593.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:43:52 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007594.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:45:23 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007595.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Wed Jan 9 21:46:53 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-January/007596.html ___ 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
Re: [Zope-CMF] Decode for Record objects
Am 10.01.2008 um 11:59 schrieb Andreas Jung: Consider working with SQLAlchemy. SA works nicely with unicode e.g. when you're using a Postgres DB with Unicode as internal DB encoding. Thanks for the tip but that's not really a solution to the problem. I normally use mxODBC and, although we can set all kinds of parameters on the client side, we're still dependent on the Zope results object which sometimes means manually coercing the conversion in an ExternalMethod. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Decode for Record objects
Am 10.01.2008 um 11:54 schrieb Jens Vagelpohl: It may be helpful if you describe what you were trying to do and what failure you're seeing so everyone has a little context for this request, which AFAIK has never come up anywhere. :oops: Sorry, I thought this was a known issue. If I have non-ASCII data in an RDBMS that I wish to use in a CMF site or even straight ZPT's you get a UnicodeError when accessing the non- ASCII Values which you get around using the decode utility. ie. <- or from **options This will raise Error Type: UnicodeDecodeError Error Value: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) For something coming from a UTF-8 database to a UTF-8 site with zpublisher-default-encoding set to UTF-8 NB. content="result/name" doesn't raise the error Actually this might not be anything to do with the CMF but simply the ZPT bug that I have discussed a bit with Andreas but lost the bug id. Which I've now found again: https://bugs.launchpad.net/zope2/+bug/143932 However, I think the error is raised because utils.decode simply returns any values untouched it doesn't know what to do with which is why I think it might be worth extending. OTOH it might something that is better fixed in the Shared.RDBMS.Results module Clearer or muddier now? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Decode for Record objects
--On 10. Januar 2008 11:41:49 +0100 Charlie Clark <[EMAIL PROTECTED]> wrote: A happy 2008 to everyone! Currently it's not really possible to use ZSQL with CMF because CMFDefault.utils.decode does not know how to handle Shared.DC.ZRDB.Results.Results or Record.Record instances I think that the decode could be extended to be able to work with Results and Records returning lists of dictionaries and dictionaries respectively. Alternatively it might be best to enforce unicode in Shared.DC.ZRDC.Results Consider working with SQLAlchemy. SA works nicely with unicode e.g. when you're using a Postgres DB with Unicode as internal DB encoding. -aj pgpmUe2OT89qO.pgp Description: 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
Re: [Zope-CMF] Decode for Record objects
On Jan 10, 2008, at 11:41 , Charlie Clark wrote: A happy 2008 to everyone! Currently it's not really possible to use ZSQL with CMF because CMFDefault.utils.decode does not know how to handle Shared.DC.ZRDB.Results.Results or Record.Record instances I think that the decode could be extended to be able to work with Results and Records returning lists of dictionaries and dictionaries respectively. Alternatively it might be best to enforce unicode in Shared.DC.ZRDC.Results Any ideas? It may be helpful if you describe what you were trying to do and what failure you're seeing so everyone has a little context for this request, which AFAIK has never come up anywhere. jens ___ 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] Decode for Record objects
A happy 2008 to everyone! Currently it's not really possible to use ZSQL with CMF because CMFDefault.utils.decode does not know how to handle Shared.DC.ZRDB.Results.Results or Record.Record instances I think that the decode could be extended to be able to work with Results and Records returning lists of dictionaries and dictionaries respectively. Alternatively it might be best to enforce unicode in Shared.DC.ZRDC.Results Any ideas? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
