Re: [Zope-dev] Referring to same interface using zope.schema.Object
On 2011-07-22 13:26, Brian Sutherland wrote: This would be my first guess: class INode(Interface): pass INode.parent = Object( title=uParent node, schema=INode ) INode.children = List( title=u'Child nodes', value_type=Object(schema=INode) ) And that guess would be wrong. You can't add fields to an existing schema like that (not sure if you can in other ways). You *can* change an existing field however, so a working solution would be: class INode(Interface): parent = Object( title = u'Parent node', schema = Interface, # set to INode later ) children = List( title = u'Child nodes', value_type = Object(schema=Interface), # set to INode later ) INode['parent'].schema = INode INode['children'].value_type.schema = INode Hope this helps - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BlueBream] Referring to same interface using zope.schema.Object
On 2011-07-22 14:32, Joshua Immanuel wrote: Hello, On Fri, 2011-07-22 at 13:41 +0200, Jacob Holm wrote: On 2011-07-22 13:26, Brian Sutherland wrote: This would be my first guess: class INode(Interface): pass INode.parent = Object( title=uParent node, schema=INode ) INode.children = List( title=u'Child nodes', value_type=Object(schema=INode) ) The method suggested by Brian works without any issues. :) It works only in the the sense that it doesn't throw an exception. It does not define the desired schema. And that guess would be wrong. You can't add fields to an existing schema like that (not sure if you can in other ways). You *can* change an existing field however, so a working solution would be: class INode(Interface): parent = Object( title = u'Parent node', schema = Interface, # set to INode later ) children = List( title = u'Child nodes', value_type = Object(schema=Interface), ) INode['parent'].schema = INode INode['children'].value_type.schema = INode I thought this also should work without any issues. Trust me, it does. But when I ran the debug shell to list out the attributes of INode using dir(INode) I couldn't find the 'parent' and 'children' attributes in it. The fields of the schema are not *supposed* to show up in dir(). Despite the use of the class statement to define them, interfaces are *not* classes. They are instances of zope.interface.interface.InterfaceClass, and act like (read-only) containers of their fields. Try using 'list(Inode)' for testing and you will see that my method works as expected. Even worse part is, if there is another field say name = TextLine(title=u'Node name') This 'name' attribute is also is not visible along with 'parent' and 'children' attributes. Can someone explain why is this so? Right. As explained above, it isn't supposed to. (Even though the problem gets solved by Brian's method, just curious to know) I hope to have convinced you by now that it really isn't solved by Brian's method, but by mine. (Although I wouldn't call it my method as such. I'm sure I have taken it from somewhere else) - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
Hi Michael, Tres I agree a new major version is required due to the new feature of having new permission names, but there is no reason to break compatibility with code using the old names. IIRC the redefinePermission/ zcml-directive is there exactly to provide backwards compatibility when renaming permissions. Use like: redefinePermission from = no longer defined permisison id to = existing permission id / It is defined in zope.security:meta.zcml along with the permission/ directive, so should be usable with any code that uses that. Best regards - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
Hi Tres Tres Seaver wrote: Assuming we put the 'redefinePermssion' directives in place on the trunk, why shouldn't we leave the version number as is? I consider the rename a bugfix, not a feature, and if we make it backwared compatible, there is no reason to bump the major version. It's a (minor) public API change. IIRC we don't allow that in minor versions, even if it is just an addition. This goes back to the whole discussion of what kinds of version requirements to allow in setup.py. - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IAbsoluteURL for browser view should contain @@?
Marius Gedminas wrote: Are you sure that most views provide IBrowserView these days? URL traversal looks them up as multi-adapters providing just Interface. True and you will almost never see a view class using implements(IBrowserView) directly. Still, if you use the browser:view or browser:page zcml directives from zope.browserpage (used to live in zope.app.publisher.browser) to register your views, then the magic class that they create for you and that is *actually* registered is a descendant of zope.publisher.browser.BrowserView which *does* implement IBrowserView. In short, all views registered using the classic zcml directives *do* provide IBrowserView. I don't (yet) know enough about Grok to say if something similar applies there. - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
Martijn Faassen wrote: I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. I would love to eventually have IFoo(x,y) be the equivalent of getMultiAdapter((x,y), IFoo), but I am -1 on using IFoo((x,y)) for this as that would break currently working code. (Not just theoretically, I have code in production that does this). I am +1 on using a __future__+frame hack to get IFoo(x,y) working now, but also +1 on using IFoo.adapt(x,y) or IFoo(some_keyword_arg=(x,y)) if that is more acceptable. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. +1 on deprecating us of the second positional argument as default, even if the signature is otherwise unchanged. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. I disagree, breaking backwards compatibility in this particular way would hurt several projects I am involved in. - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: Problem validating file uploads
Michael Howitz wrote: Am 12.04.2009 um 15:12 schrieb Michael Howitz: Hi, I'm using a trunk version of z3c.form and have the following situation: In my interface I have a zope.schema.Bytes field. z3c.form.converter.FileUploadDataConverter.toFieldValue returns z3c.form.interfaces.NOT_CHANGED when I do not upload a file. z3c.form.validator.SimpleFieldValidator.validate fails later on as the value (z3c.form.interfaces.NOT_CHANGED) is not of type str (which is required by the Bytes field). I created a branch in svn to show the behavior. (z3c.form/branches/ icemac_validate_NOT_CHANGED) I'm not sure how to fix this generally, some possible solutions come to my mind, but each idea has its own problems: 1) Create a special validator for zope.schema.Bytes + z3c.form.interfaces.IFileWidget which knows how to handle NOT_CHANGED. This does not seem to be a really general solution and might have the same problems like the following ideas. 2) When z3c.form.validator.SimpleFieldValidator.validate is called with NOT_CHANGED as value, try to look up the value on the context object. This fails on AddForms as the context there is the parent object. 3) When z3c.form.validator.SimpleFieldValidator.validate is called with NOT_CHANGED as value, do not validate hoping the previous value was valid. This approach fails with AddForms, too, when the Bytes field is required. (The missing-value-error does not get raised.) Anyone having an idea for a possibly working solution? As I got no responsed, I'd like to put this issue into z3c.form's bugtracker. But which is the correct one? https://bugs.launchpad.net/zope3/ ? I don't know about the right tracker for this, but I think the right solution is 2) except that when widget.ignoreContext is True the default value should be looked up and validated instead. In other words, change z3c.form.validator.SimpleFieldValidator.validate to something like this (untested): def validate(self, value): See interfaces.IValidator context = self.context request = self.request view = self.view field = self.field widget = self.widget if context is not None: field = field.bind(context) if value is interfaces.NOT_CHANGED: if (interfaces.IContextAware.providedBy(widget) and not widget.ignoreContext): # get value from context value = zope.component.getMultiAdapter( (context, field), interfaces.IDataManager).query() else: value = interfaces.NO_VALUE if value is interfaces.NO_VALUE # look up default value value = field.default adapter = zope.component.queryMultiAdapter( (context, request, view, field, widget), interfaces.IValue, name='default') if adapter: value = adapter.get() return field.validate(value) Unless I am missing something, the above code should compute the same value as z3c.form.widget.Widget.update would when ignoreRequest is True. Thus effectively converting NOT_CHANGED into the existing value before validating, Hope this helps - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.annotation/trunk/setup.py Whitespace fixes
Michael Howitz wrote: Am 01.04.2009 um 23:44 schrieb Jacob Holm: Hi Baiju If this whitespace fix is based on the current style guide, I think the guide needs to be fixed. I find the fixed version much less readable. A function that takes this many arguments should have an exception to the PEP 8 rule of no whitespace around the equals sign used for keyword arguments. I *think* a reasonable rule is that if you split the call over multiple lines with one argument per line, you should add single spaces before and after the equals sign. What does anyone else think? What about defining the version number in front of the setup call as a variable and using it in the call like: version = '3.5.0dev' setup( name='zope.annotation', version=version, ... ) This way no exception from the rule is necessary. I like the idea of putting the version string up front like that, but that was not what I meant. I was not complaining about the version keyword argument specifically, but about the removal of whitespace for *all* the keyword arguments to setup. Cheers - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
Jim Fulton wrote: On Apr 2, 2009, at 2:31 PM, Chris Withers wrote: For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing. For write access I completely agree. For read-only unauthenticated access it would be nice to be able to use http(s). It may be possible to have it all at the same time. - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.annotation/trunk/setup.py Whitespace fixes
Hi Baiju
If this whitespace fix is based on the current style guide, I think the
guide needs to be fixed. I find the fixed version much less readable. A
function that takes this many arguments should have an exception to the
PEP 8 rule of no whitespace around the equals sign used for keyword
arguments. I *think* a reasonable rule is that if you split the call
over multiple lines with one argument per line, you should add single
spaces before and after the equals sign. What does anyone else think?
- Jacob
Baiju M wrote:
Log message for revision 98773:
Whitespace fixes
Changed:
U zope.annotation/trunk/setup.py
-=-
Modified: zope.annotation/trunk/setup.py
===
--- zope.annotation/trunk/setup.py2009-04-01 21:02:33 UTC (rev 98772)
+++ zope.annotation/trunk/setup.py2009-04-01 21:13:34 UTC (rev 98773)
@@ -23,14 +23,14 @@
return open(os.path.join(os.path.dirname(__file__), *rnames)).read()
setup(
-name = 'zope.annotation',
-version = '3.5.0dev',
-url = 'http://pypi.python.org/pypi/zope.annotation',
-license = 'ZPL 2.1',
-description = 'Object annotation mechanism',
-author = 'Zope Corporation and Contributors',
-author_email = 'zope-dev@zope.org',
-classifiers = [
+name='zope.annotation',
+version='3.5.0dev',
+url='http://pypi.python.org/pypi/zope.annotation',
+license='ZPL 2.1',
+description='Object annotation mechanism',
+author='Zope Corporation and Contributors',
+author_email='zope-dev@zope.org',
+classifiers=[
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'License :: OSI Approved :: Zope Public License',
@@ -40,23 +40,23 @@
'Topic :: Internet :: WWW/HTTP',
'Topic :: Software Development',
],
-long_description = \
+long_description= \
read('src', 'zope', 'annotation', 'README.txt')
+ '\n\n' +
read('CHANGES.txt'),
-packages = find_packages('src'),
-package_dir = {'': 'src'},
-namespace_packages = ['zope',],
-install_requires = ['setuptools',
-'zope.interface',
-'zope.component',
-'zope.location',
-'zope.proxy',
-],
-extras_require = dict(
-test = ['zope.testing',
-'ZODB3'],
+packages=find_packages('src'),
+package_dir={'': 'src'},
+namespace_packages=['zope',],
+install_requires=['setuptools',
+ 'zope.interface',
+ 'zope.component',
+ 'zope.location',
+ 'zope.proxy',
+ ],
+extras_require=dict(
+test=['zope.testing',
+ 'ZODB3'],
),
-include_package_data = True,
-zip_safe = False,
+include_package_data=True,
+zip_safe=False,
)
___
Checkins mailing list
check...@zope.org
http://mail.zope.org/mailman/listinfo/checkins
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Chris Withers wrote: Jacob Holm wrote: Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do: adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB) In general, using context=a should give the same result as context=siteA. Why? What actually makes this work? If you provide a context in the zope.component.getAdapter call, it is used with zope.component.getSiteManager to find the site manager to use for the actual lookup. In this case getSiteManager does the actual lookup by adapting context to zope.component.interfaces.IComponentLookup using the global registry. In a normal setup, this will find the SiteManagerAdapter from zope.site.site (used to be in zope.app.component). This adapter simply traverses __parent__ pointers until it finds an object providing zope.location.interfaces.ISite. Depending on your setup it may actually be a different implementation of getSiteManager that is used, since it is marked with @hookable. The common replacement is zope.site.hooks.getSiteManager, which in this case does exactly the same global IComponentLookup adapter lookup I described above. If you are not using zope.site, you need to provide your own global IComponentLookup adapter to get it working. (Or hook the getSiteManager function yourself) This is a bit more complex than I remembered, but the result is that in a normal setup passing context=A will give the same result as context=siteA, assuming that siteA can be found from A by following __parent__ pointers. Hope this helps - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setting missing minimum version in setup.py
Wichert Akkerman wrote: Previously Martijn Faassen wrote: Hey, Stephan Richter wrote: [snip] There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? -1 still If I install a package I want to have a guarantee all aspects of that package work correctly. With this compromise that is not possible. Wichert. I am not quite sure what you mean... Are you saying that the proposal does not go far enough, and we should allow the full =x.y.z? Or are you against any and all versions in setup.py? I think the best policy is to use versions specs for base packages (minimum, as well as maximum), but only when it is *known* that not meeting the requirements means the derived package is useless. This is most likely to happen when the API of the base package is changed (which is only allowed in a major version), but could in rare cases happen for other reasons. To me the important thing is not the major/minor version distinction, but rather the degree of uselessness. Of course there may be broad guidelines such as only use major versions, but the way I see it this really calls for a decision on a case-by-case basis. Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Chris Withers wrote: [snip] It's interesting, this use case sound pretty close to what I'm talking about in the very last part of this message: http://mail.zope.org/pipermail/zope-dev/2009-March/035220.html ie: adapter context based on object traversal rather than notion of current site. Not quite, since this was about principal annotations and principals cannot be found by object traversal. It was specifically about letting the adapter know the context, not about finding a different adapter based on context. Can someone confirm to me whether or not manually specifying the context as I have in the example above would work, or would I need to do: adapter1 = getAdapter(a,ISomething,context=siteA) adapter2 = getAdapter(b,ISomething,context=siteB) In general, using context=a should give the same result as context=siteA. In the particular case of principalannotations, this would not help. There the adapter is the same globally, but needs to know the context so it can find the proper utility to use. To make it work you'd need to register a different adapter for each utility. This is certainly doable, but probably not worth the effort. Hope this helps Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Hi Dan Dan Korostelev wrote: Hi there! While looking at the zope.app.principalannotation package, I discovered that both zope.annotation and zope.app.principalannotation register their IAnnotations adapters twice: fisrt, as a simple adapter and second, as a multi adapter for some additional context object. The zope.annotation doesn't use that additional context at all - it just allows to get annnotations by multi-adapter lookup. The zope.app.principalannotation uses the additional context object as context argument for getSiteManager, which I believe is not needed and/or used in most cases, because application components, like zope.site provide their hooks to get the right site manager. There's no documentation or any tests for that behaviour neither in zope.app.principalannotation, nor in zope.annotation, so I made an assumption that these registrations are there just to support some very old annotation pattern, that was deprecated ages ago. If it's like that, I'd like to remove that registration for zope.principalannotation that is about to born as well as for zope.annotation. Can someone clarify this point? I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). In both cases it is important that the annotations are looked up in some context rather than in whatever the current site happens to be. Hope this helps Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
Hi Malthe Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. IIRC, the C extension is needed to make messageids truly immutable. This guards against certain kinds of errors and also means they don't need to be security proxied, which probably gives a good speedup somewhere. +1 to documenting why this is a good idea. -1 on removing the extension. HTH - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] misterious btree issue
Hi Adam Adam GROSZER wrote: Hello, I've run into a misterious issue while evolving generations from an old DB. Quick fact is that it seems like a BTree kept an object reference to an object which was deleted from it. [snip] Yes, the BTree implementations we use may keep a reference to a deleted key. I think I have seen this documented somewhere but don't have the time to look it up now. It saves some bookkeeping to do it that way, and I think it also reduces the risk of conflict errors. What helped was to recreate both IntId BTrees from scratch, like at #recreate intid trees. That and packing made the utility finally go away. Anybody noticed something like this Yes, I ran into this a few weeks ago when I needed to delete the code for an obsolete content type. IIRC you only really need to recreate the mapping from keyreferences to intids (the ids attribute of the default IIntIds utility). Hope this helps - Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/src/zc/sourcefactory/browser/token.txt as it seems impossible to upload umlauts in long_description to pypi using distutils, so I had to replace t
This looks like a bad idea. You are weakening the test by removing non-ascii chars here. A better approach would have been to rewrite the non-ascii chars using \N (or \u or \U) escapes. Regards - Jacob Michael Howitz wrote: Log message for revision 90434: as it seems impossible to upload umlauts in long_description to pypi using distutils, so I had to replace the umlauts Changed: U zc.sourcefactory/trunk/src/zc/sourcefactory/browser/token.txt -=- Modified: zc.sourcefactory/trunk/src/zc/sourcefactory/browser/token.txt === --- zc.sourcefactory/trunk/src/zc/sourcefactory/browser/token.txt 2008-08-27 11:44:57 UTC (rev 90433) +++ zc.sourcefactory/trunk/src/zc/sourcefactory/browser/token.txt 2008-08-27 11:49:47 UTC (rev 90434) @@ -18,8 +18,8 @@ === zc.sourcefactory.browser.token.fromUnicode( - ... u'somestring with umlauts öäü') - '45dadc304e0d6ae7f4864368bad74951' + ... u'somestring with strange chars #*_;)') + 'f33b8a6b56403c9d560e2ef772336798' Integer === ___ Checkins mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/checkins ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: zope.component/ Merge wichert-utility-factories branch to trunk
Hello This checkin contains the following change to zope.component/trunk/src/zope/component/registry.py which looks wrong to me (it's a noop). It looks to me as if the [:2] should move outside the ) following it. I am surprised that this doesn't break any tests, as it means that reregistrations are not detected as such. -if (self._utility_registrations.get((provided, name)) +if (self._utility_registrations.get((provided, name)[:2]) Wichert Akkerman wrote: Log message for revision 88794: Merge wichert-utility-factories branch to trunk Changed: D zope.component/branches/wichert-utility-factories/ U zope.component/trunk/README.txt U zope.component/trunk/src/zope/component/interfaces.py U zope.component/trunk/src/zope/component/registry.py U zope.component/trunk/src/zope/component/registry.txt U zope.component/trunk/src/zope/component/zcml.py -=- Modified: zope.component/trunk/README.txt === --- zope.component/trunk/README.txt 2008-07-24 16:00:26 UTC (rev 88793) +++ zope.component/trunk/README.txt 2008-07-24 16:17:58 UTC (rev 88794) @@ -14,6 +14,10 @@ 3.5.0 (unreleased) == +Support registration of utilities via factories through the component registry +and return factory information in the registration information. This fixes +https://bugs.launchpad.net/zope3/+bug/240631 + Optimized un/registerUtility via storing an optimized data structure for efficient retrieval of already registered utilities. This avoids looping over all utilities when registering a new one. Modified: zope.component/trunk/src/zope/component/interfaces.py === --- zope.component/trunk/src/zope/component/interfaces.py 2008-07-24 16:00:26 UTC (rev 88793) +++ zope.component/trunk/src/zope/component/interfaces.py 2008-07-24 16:17:58 UTC (rev 88794) @@ -512,6 +512,7 @@ Information about the registration of a utility +factory = interface.Attribute(The factory used to create the utility. Optional.) component = interface.Attribute(The object registered) provided = interface.Attribute(The interface provided by the component) @@ -583,9 +584,12 @@ Register components -def registerUtility(component, provided=None, name=u'', info=u''): +def registerUtility(component=None, provided=None, name=u'', info=u'', factory=None): Register a utility +factory + Factory for the component to be registerd. + component The registered component @@ -602,10 +606,11 @@ An object that can be converted to a string to provide information about the registration. +Only one of component and factory can be used. A Registered event is generated with an IUtilityRegistration. -def unregisterUtility(component=None, provided=None, name=u''): +def unregisterUtility(component=None, provided=None, name=u'', factory=None): Unregister a utility A boolean is returned indicating whether the registry was @@ -614,6 +619,9 @@ None and is not registered, then the function returns False, otherwise it returns True. +factory + Factory for the component to be unregisterd. + component The registered component The given component can be None, in which case any component registered to provide @@ -629,6 +637,7 @@ name The utility name. +Only one of component and factory can be used. An UnRegistered event is generated with an IUtilityRegistration. Modified: zope.component/trunk/src/zope/component/registry.py === --- zope.component/trunk/src/zope/component/registry.py 2008-07-24 16:00:26 UTC (rev 88793) +++ zope.component/trunk/src/zope/component/registry.py 2008-07-24 16:17:58 UTC (rev 88794) @@ -65,12 +65,17 @@ lambda self, bases: self._setBases(bases), ) -def registerUtility(self, component, provided=None, name=u'', info=u'', -event=True): +def registerUtility(self, component=None, provided=None, name=u'', info=u'', +event=True, factory=None): +if factory: +if component: +raise TypeError(Can't specify factory and component.) +component = factory() + if provided is None: provided = _getUtilityProvided(component) -if (self._utility_registrations.get((provided, name)) +if (self._utility_registrations.get((provided, name)[:2]) == (component, info)): # already registered return @@ -81,7 +86,7 @@ subscribed = True break -
Re: AW: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale extraction concept
Hi,
Roger Ineichen wrote:
Note, if you run the i18nextract script, all module must be there like in a running application. You can't only use the files which will
contain locales. Also modules which this packages import from must be there.
That should not be necessary I think. At least I am not used to it.
When I use i18ndude for making pot/po files for a Plone
product/package and I have from Products.CMFPlone import something
in a file, then this import does not really take place. I
expect in the case of python files it simply looks for lines like:
_(uMy message to the world.)
Probably it works in some ues case but for sure not in all.
Let's give a sample. If you define a interface like
foo = zope.schema.Choice(
title=_('Title'),
vocabulary=foo.bar.myVocabularyFromPackageFoo
)
Then the foo.bar package must be available.
That sounds suspiciously like you are trying to import the
modules/packages that you want to extract from. I think that is neither
necessary nor desirable. The extraction should work on the source code
only. For zcml extraction, that might be an issue because knowing which
strings to extract requires processing the meta directives included from
the file. For python source code and page templates there is no such
problem.
Hope this helps,
Jacob
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
