[Zope-CMF] Re: Move CMF collector to Launchpad (redux)
Charlie Clark wrote: Am 29.10.2007 um 21:17 schrieb Wichert Akkerman: It seems that the Launchpad database is not separated by product. I was just checking the bugs fixed in the latest relase of Zope and #2339 refers to something completely different related to Ubuntu. I would have expected bugs from unrelated projects to kept separate. The fact that they are not is useful: it allows you to move a bugreport from one product to another. For any migration the loss of the bug id is pretty major. The bug id won't be lost. Launchpad has a mapping between the old bug ids from the zope.org collector to the new launchpad ids. This works well for the Zope 2 and Zope 3 collectors already. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: Accessing the "context"
robert rottermann wrote:
Charlie Clark schrieb:
Dear all,
a simple question with hopefully a simple answer! How do I access
objects from an object's context or hierarchy? Specifically I'd like to
be able to access a ZopeDA connection for a site.
I
if you know the id of the object you are looking for beforehand you can
get it by just requesting it from the context like:
da = getattr('my_da_or_what_ever', context, None)
if da:
...
minor nit:
i strongly recommend "if da is not None" rather than just "if da".
if your 'da' object was a containerish object with no contained objects, then
it would evaluate to False even though the object really existed. it's
generally unwise to assume that an object will evaluate to True just because
it exists.
-r
___
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] Accessing the "context"
Am 30.10.2007 um 18:13 schrieb robert rottermann: there are two places where you can put your code, in both cases acquisition is fully functional. Thanks very much! Now hit an error that my database connection object can't be pickled but at least I can access it! :-D 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: Accessing the "context"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Charlie Clark wrote: >> Am 30.10.2007 um 17:40 schrieb Wichert Akkerman: >> >>> __init__ is indeed the wrong place: when the instance is created it is >>> not placed in an acquisition context yet. >> That would indeed explain things!!! Is it okay to call a method which >> does this from __init__ ? > > No, since the acquisition context is only created when the object is > insert into the hierarchy somewhere (sloppy terminology here, I know). Minor nit: the acquisition wrappers are transient objects, created when the object is retrieved from the container (typically via the container's __getattr__). So, the typical pattern for a factory which needs to do something with context is: def foo_factory(container, name): foo = Foo(name) container._setObject(name, foo) wrapped = container._getOb(foo) # now we have context > And that can only happen after the instance has been fully created. > > As an example: > >obj = Object() ># obj has no acquisition context >folder.obj = obj ># folder.obj will have an acquisition context Right, but the original 'obj' doesn't magically get a context: you need to re-fecth it (via 'foo.obj'). > In other words: in __init__ and everything you call from __init__ the > instance will not have an aq context. The context does not magically > appear. Yup. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJ2ux+gerLs4ltQ4RAuWTAKDIhq+jyK7l7icmYax3HxxvZWmb2gCfU6dl vmEUq8YkT+RFbxzUFet7Ybk= =v4zr -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
Re: [Zope-CMF] Accessing the "context"
Wichert Akkerman schrieb:
> Previously Charlie Clark wrote:
>> Am 30.10.2007 um 17:04 schrieb Andrew Sawyers:
>>
>>> If it's in a content type's class, why not:
>>> id = getattr(self, 'da_id', None)
>>> Just using self as the context should be fine.
>>> -- that of course presumes that the type is wrapped properly when
>>> you call that within your method.
>> mm, currently getting None back so I guess I'm not wrapping things
>> properly.
>>
>> This is a skeleton bit of code:
>>
>> class ContentType(PortalContent):
>> """A content type with access to an external database"""
>>
>> def __init__(self, id):
>> self.id = id
>> DA = getattr(self, 'MyDA', None)
>> #self.conn = DA() # not working at the moment because DA is None
>>
>> Is it wrong to try and do this in my __init__ ? Regarding your other
>> suggestion: yes, I probably will factor this out into a utility once
>> I've worked out how to access the DA!!!
>
> __init__ is indeed the wrong place: when the instance is created it is
> not placed in an acquisition context yet.
there are two places where you can put your code, in both cases
acquisition is fully functional.
if it is ATContentTyoe based you can add a method:
#
# AT specific, called after creation of the final
# instance
#
security.declarePrivate('at_post_create_script')
def at_post_create_script(self, member_id=None):
da = getattr(self, 'MyDA', None)
or if it is a "mere" CMF content type:
def manage_afterAdd(self, item, container):
"""
Add self to the catalog.
(Called when the object is created or moved.)
"""
da = getattr(self, 'MyDA', None)
robert
begin:vcard
fn:Robert Rottermann
n:Rottermann;Robert
tel;work:++41 31 333 10 20
tel;fax:++41 31 333 10 23
tel;home:++41 31 333 36 03
x-mozilla-html:FALSE
version:2.1
end:vcard
___
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] Accessing the "context"
Previously Charlie Clark wrote: > > Am 30.10.2007 um 17:40 schrieb Wichert Akkerman: > > >__init__ is indeed the wrong place: when the instance is created it is > >not placed in an acquisition context yet. > > That would indeed explain things!!! Is it okay to call a method which > does this from __init__ ? No, since the acquisition context is only created when the object is insert into the hierarchy somewhere (sloppy terminology here, I know). And that can only happen after the instance has been fully created. As an example: obj = Object() # obj has no acquisition context folder.obj = obj # folder.obj will have an acquisition context In other words: in __init__ and everything you call from __init__ the instance will not have an aq context. The context does not magically appear. 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] Accessing the "context"
Am 30.10.2007 um 17:40 schrieb Wichert Akkerman:
__init__ is indeed the wrong place: when the instance is created it is
not placed in an acquisition context yet.
That would indeed explain things!!! Is it okay to call a method which
does this from __init__ ?
def __init__(self, id):
self.id = id
self.set_connection()
security.declarePublic('set_connection')
def set_connection(self):
DA = (self, 'myDA', None)
This is also not working. :-/
Thanks very much for your help.
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] Accessing the "context"
Previously Charlie Clark wrote: > > Am 30.10.2007 um 17:04 schrieb Andrew Sawyers: > > >If it's in a content type's class, why not: > >id = getattr(self, 'da_id', None) > >Just using self as the context should be fine. > >-- that of course presumes that the type is wrapped properly when > >you call that within your method. > > mm, currently getting None back so I guess I'm not wrapping things > properly. > > This is a skeleton bit of code: > > class ContentType(PortalContent): > """A content type with access to an external database""" > > def __init__(self, id): > self.id = id > DA = getattr(self, 'MyDA', None) > #self.conn = DA() # not working at the moment because DA is None > > Is it wrong to try and do this in my __init__ ? Regarding your other > suggestion: yes, I probably will factor this out into a utility once > I've worked out how to access the DA!!! __init__ is indeed the wrong place: when the instance is created it is not placed in an acquisition context yet. 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] Accessing the "context"
Am 30.10.2007 um 17:04 schrieb Andrew Sawyers: If it's in a content type's class, why not: id = getattr(self, 'da_id', None) Just using self as the context should be fine. -- that of course presumes that the type is wrapped properly when you call that within your method. mm, currently getting None back so I guess I'm not wrapping things properly. This is a skeleton bit of code: class ContentType(PortalContent): """A content type with access to an external database""" def __init__(self, id): self.id = id DA = getattr(self, 'MyDA', None) #self.conn = DA() # not working at the moment because DA is None Is it wrong to try and do this in my __init__ ? Regarding your other suggestion: yes, I probably will factor this out into a utility once I've worked out how to access the DA!!! 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] Accessing the "context"
Charlie Clark wrote: Am 30.10.2007 um 16:53 schrieb Wichert Akkerman: getattr(context, 'my_da_or_what_ever', None) works a bit better. Doesn't that only work within a PythonScript? I need access from within a content type, ie. real Python code? It's called acquisition and it works everywhere. Try it. Yes, but the context isn't available everywhere. How do I get hold of that? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 If it's in a content type's class, why not: id = getattr(self, 'da_id', None) Just using self as the context should be fine. -- that of course presumes that the type is wrapped properly when you call that within your method. Andrew ___ 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] Accessing the "context"
Wichert Akkerman wrote:
da = getattr('my_da_or_what_ever', context, None)
getattr(context, 'my_da_or_what_ever', None) works a bit better.
Note that getattr('foo', context, None) is wrong.
Wichert has the correct syntax; I didn't even pay attention to the
syntax originally. :)
Doesn't that only work within a PythonScript? I need access from
within a content type, ie. real Python code?
It's called acquisition and it works everywhere. Try it.
Wichert.
Andrew
___
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] Accessing the "context"
Am 30.10.2007 um 16:53 schrieb Wichert Akkerman: getattr(context, 'my_da_or_what_ever', None) works a bit better. Doesn't that only work within a PythonScript? I need access from within a content type, ie. real Python code? It's called acquisition and it works everywhere. Try it. Yes, but the context isn't available everywhere. How do I get hold of that? 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] Accessing the "context"
Wichert Akkerman wrote:
Previously Charlie Clark wrote:
Am 30.10.2007 um 16:19 schrieb robert rottermann:
da = getattr('my_da_or_what_ever', context, None)
getattr(context, 'my_da_or_what_ever', None) works a bit better.
Doesn't that only work within a PythonScript? I need access from
within a content type, ie. real Python code?
It's called acquisition and it works everywhere. Try it.
It only works if the context is wrapped properly. :)
Wichert.
Andrew
___
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] Accessing the "context"
Charlie Clark wrote:
Am 30.10.2007 um 16:19 schrieb robert rottermann:
da = getattr('my_da_or_what_ever', context, None)
Doesn't that only work within a PythonScript? I need access from
within a content type, ie. real Python code?
That will work within your content class code as well. That's probably
your easiest route; I would probably abstract it into a
tool/adapter/utility - all depending on what you're using in your stack
(i.e. five). I'm not up to speed on cmf 2 changes and the model in that
stack.
Andrew
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 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] Accessing the "context"
Previously Charlie Clark wrote:
>
> Am 30.10.2007 um 16:19 schrieb robert rottermann:
>
> >
> >da = getattr('my_da_or_what_ever', context, None)
getattr(context, 'my_da_or_what_ever', None) works a bit better.
> Doesn't that only work within a PythonScript? I need access from
> within a content type, ie. real Python code?
It's called acquisition and it works everywhere. Try it.
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] Accessing the "context"
Am 30.10.2007 um 16:19 schrieb robert rottermann:
da = getattr('my_da_or_what_ever', context, None)
Doesn't that only work within a PythonScript? I need access from
within a content type, ie. real Python code?
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] Accessing the "context"
Am 30.10.2007 um 15:41 schrieb Andreas Jung:
Dear all,
a simple question with hopefully a simple answer! How do I access
objects
from an object's context or hierarchy?
Acquisition? Traversal using restrictedTraverse()?
Yes, but I'm not sure which.
Say I have a DA, myDA, in my portal root and I have content type that
needs to access this to store some attributes in an external
database, how do I get hold of it?
import Aqcuisition
class MyContentType():
def set_connection(self):
self.connection = Acquisition.ac_aquire('myDA')
raises an AttributeError
I realise that this is probably down to me not getting Aqcuisition
but this looks like how it should work going on the description of
Aquisition.
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] Accessing the "context"
Charlie Clark schrieb:
> Dear all,
>
> a simple question with hopefully a simple answer! How do I access
> objects from an object's context or hierarchy? Specifically I'd like to
> be able to access a ZopeDA connection for a site.
I
>
if you know the id of the object you are looking for beforehand you can
get it by just requesting it from the context like:
da = getattr('my_da_or_what_ever', context, None)
if da:
...
s it correct that I
> have to register this somewhere to be able to access it from a portal
> object?
>
no
hth
robert
begin:vcard
fn:Robert Rottermann
n:Rottermann;Robert
tel;work:++41 31 333 10 20
tel;fax:++41 31 333 10 23
tel;home:++41 31 333 36 03
x-mozilla-html:FALSE
version:2.1
end:vcard
___
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] Accessing the "context"
--On 30. Oktober 2007 14:46:44 +0100 Charlie Clark <[EMAIL PROTECTED]> wrote: Dear all, a simple question with hopefully a simple answer! How do I access objects from an object's context or hierarchy? Acquisition? Traversal using restrictedTraverse()? -aj pgpXFZBCguPi5.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
[Zope-CMF] Accessing the "context"
Dear all, a simple question with hopefully a simple answer! How do I access objects from an object's context or hierarchy? Specifically I'd like to be able to access a ZopeDA connection for a site. Is it correct that I have to register this somewhere to be able to access it from a portal object? 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] CMF Tests: 11 OK
Summary of messages to the cmf-tests list. Period Mon Oct 29 13:00:00 2007 UTC to Tue Oct 30 13:00:00 2007 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: Mon Oct 29 22:20:40 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006799.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:22:11 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006800.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:23:41 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006801.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:25:11 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006802.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:26:41 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006803.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:28:11 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006804.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:29:41 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006805.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:31:12 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006806.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:32:42 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006807.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:34:12 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006808.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Oct 29 22:35:42 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-October/006809.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] Move CMF collector to Launchpad (redux)
Previously Charlie Clark wrote: > > Am 29.10.2007 um 21:17 schrieb Wichert Akkerman: > > >>It seems that the Launchpad database is not separated by product. I > >>was just checking the bugs fixed in the latest relase of Zope and > >>#2339 refers to something completely different related to Ubuntu. I > >>would have expected bugs from unrelated projects to kept separate. > > > >The fact that they are not is useful: it allows you to move a > >bugreport > >from one product to another. > > For any migration the loss of the bug id is pretty major. As for > related projects: yes, I can see the benefit of moving bugs between > say CMF, Zope 2 and Zope 3 but in this case it the bug I was looking > at was something to do with watchin DivX films using Xine on Ubuntu. > As this is completely unrelated, and something I am not interested in > the slightest, I would consider this to be a major drawback. FWIW, I don't see that as a drawback. The old URL with the old bug number will continue to work: it will redirect you to the new instance of the bug report on launchpad. 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] Move CMF collector to Launchpad (redux)
Am 29.10.2007 um 21:17 schrieb Wichert Akkerman: It seems that the Launchpad database is not separated by product. I was just checking the bugs fixed in the latest relase of Zope and #2339 refers to something completely different related to Ubuntu. I would have expected bugs from unrelated projects to kept separate. The fact that they are not is useful: it allows you to move a bugreport from one product to another. For any migration the loss of the bug id is pretty major. As for related projects: yes, I can see the benefit of moving bugs between say CMF, Zope 2 and Zope 3 but in this case it the bug I was looking at was something to do with watchin DivX films using Xine on Ubuntu. As this is completely unrelated, and something I am not interested in the slightest, I would consider this to be a major drawback. 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] ZCML import/export step registration
I completed implementation of zcml-based import and export step registration on the wichert-zcml-steps branch. The syntax for import steps is this: and for export steps: steps registered using zcml are stored in a new registry. I added some utility methods to the setup tool that look in both this registry and the in-tool registry so all the standard machinery and ZMI interfaces see all steps. Exporting only exports steps from the in-tool registries. There are several advantages to managing steps in this method: - if a product is removed its steps no longer stick in the system, which could lead to errors (it was breaking sites badly until we changed GS to ignore steps with invalid handlers) and adds a lot of unremoveable entries in its ZMI pages. - even though steps are only loaded into the registry when a profile was selected the way we have managed the step registration in the user interface and API so far this has always been a silent and trivial to trigger action. This lead to confusing behaviour: steps would appear to be registered randomly depending on which profiles a user happened to have accessed. With zcml registration the behaviour is simple and predictable: if you install a product and load its zcml its functionality becomes available. Since import steps have always needed to check for presence of XML or marker files this is harmless. Exporting should always be a safe operation. - If we deprecate profile-based registration and eventually remove it we can simplify a lot of code. I intend to merge this branch into trunk next week. 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
[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 tseaver - "CMF needs View-based TypeInformation", [Accepted] http://www.zope.org/Collectors/CMF/437 - "CachingPolicyManager awareness of File and Image does not work", [Accepted] http://www.zope.org/Collectors/CMF/496 yuppie - "purge_old in runAllImportSteps not working", [Accepted] http://www.zope.org/Collectors/CMF/455 Pending / Deferred Issues - "workflow notify success should be after reindex", [Deferred] http://www.zope.org/Collectors/CMF/389 - "Discussions broken", [Pending] http://www.zope.org/Collectors/CMF/493 - "components handler: export of placeless utilities is broken", [Pending] http://www.zope.org/Collectors/CMF/498 - "CatalogTool._listAllowedRolesAndUsers() returns wrong result ", [Pending] http://www.zope.org/Collectors/CMF/502 - "Spinning browser when running a snapshot", [Pending] http://www.zope.org/Collectors/CMF/503 - "GenericSetup import onto existing skins fails when adding new layers relative to old ones", [Pending] http://www.zope.org/Collectors/CMF/505 - "DirectoryView always registers subdirectories in development mode", [Pending] http://www.zope.org/Collectors/CMF/506 Pending / Deferred Features - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "iCal support for CMFCalendar", [Pending] http://www.zope.org/Collectors/CMF/487 - "components handler: support for sub-sites", [Pending] http://www.zope.org/Collectors/CMF/500 - "components handler: support removing items", [Pending] http://www.zope.org/Collectors/CMF/501 - "components handler: make 'interface' attribute optional", [Pending] http://www.zope.org/Collectors/CMF/499 ___ 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
