Re: [Zope-dev] Relative path support for z3c.recipe.paster?
Hi Jonathan Betreff: [Zope-dev] Relative path support for z3c.recipe.paster? Hi, Since zc.recipe.egg 1.2.0, there's an option to generate scripts which contains relative paths to eggs installed in the eggs/ directory [1] This is very handy if you want to move your buildout around, without needing to relaunch the whole buildout process. What do maintainers of z3c.recipe.paster think if I propose a patch which add this option (or something else) to support the same thing for this recipe? Actually, this can be a relatively minor change, since the recipe already use zc.recipe.egg, which means it only has to pass the corresponding option to this one. Thoughts? In general any improvment is welcome as long as there is no bad sideffect. I do not know this option and do not understand what you mean with moving buildout around. I guess this is nothing which is needed in a productive setup. Anyway, if there is no sideffect like larger processing time in prodction use just for provide a fancy feature, you are very welcome to improve and implement usefull things ;-) Regards Roger Ineichen Cheers, Jonathan [1] : http://pypi.python.org/pypi/zc.recipe.egg#relative-egg-paths ___ 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 ) ___ 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] proposal: Custom schema properties
Hi Adam Betreff: [Zope-dev] proposal: Custom schema properties Hello, Custom schema properties proposal = The problem is that we have a baseline project. This baseline project gets customized for each client. Each client has different (usually just a little bit) needs in terms of field titles and field required. The real problem is, to achieve this we have to create a new interface with the overridden field. This starts the domino effect, we have to create a new class, this new class needs to be instantiated, new add form, new edit form and register those. A hell lot of code to support that tiny change. The solution would be to have default schema properties defined as usual (depending on the implementation the field object would come from a different package). Those defaults can be overridden by Interface.fieldName and site (by utility or adapter lookup). Seems like fields that are not overridden in the interface subclasses might not be overridden. Further goal could be to have these customizations easily modified TTW. That somehow suggest that an adapter registration for each property customization is a no-go. Performance Performance needs to be as close as possible to the plain schema implementation. I guess field properties get evaluated quite often per request, an adapter/utility lookup per property evaluation is a no-go. I'd say zope.schema classes should stay as they are, the custom schema will be done using subclasses. Dependencies If no additional dependencies will be added to zope.schema the implementation could go into zope.schema.custom if yes z3c.schema.custom could be the place. Opinions? Anyone suffering the same problems? If we implement a generic solution which allows to manipulate all field properties, we should probably add an option for mark customizable fields for define some minimal requirements e.g. min=2 can get overriden with min=1 but not with min=0 etc. We should also make sure that we can change a field default='foo' to default='bar' but not required=True to required=False etc. This probably means that we should have one or more customization properties for each existing field property. Based on the complexity of this implementation we should implement this concept as a z3c package. This package will probably also depend on other z3c.schema fields e.g. z3c.schema.email if we need to implement special customization properties for each field. Regards Roger Ineichen ___ 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] ZODB Competing read/writes: How to find out which attribute?
Hi Hermann Betreff: Re: [Zope-dev] ZODB Competing read/writes: How to find out which attribute? Hermann Himmelbauer wrote: Hi, I once in the while get the following warning in my Zope 3 log, which I'd like to resolve: 2009-10-07T14:35:41 WARNING ZopePublication Competing writes/reads at /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/c/acc/booklis t/index.html: database conflict error (oid 0x7a5d, class BTrees.OOBTree.OOBTree, serial this txn started with 0x0381388ca6804966 2009-10-07 12:28:39.023700, serial currently committed 0x03813893b087d0cc 2009-10-07 12:35:41.374343) That URL looks like it should only be reading the database, but the fact that you get a conflict error suggests that the code behind that URL is writing to the database. If I were you, I would first ensure that read operations never write to the database. just a hint, sometimes session get accessed with session[key] wich will force a write operation. If so, you can prevent creating a new session by using session.get(key, someDefaultValue) Regards Roger Ineichen Shane ___ 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 ) ___ 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: Need to register SimpleFieldValidator in localsite - how?
Hi Hermann Betreff: [Zope-dev] z3c.form: Need to register SimpleFieldValidator in localsite - how? Hi, I currently have the following simple validator: --- snip -- class ActEmailValidator(SimpleFieldValidator): Validates ACT E-Mail Addresses for customers def validate(self, value): super(ActEmailValidator, self).validate(value) if getattr(getSite(), 'bank_specifics', None) == u'act': if not re.match(r'^...@[0-9]+?.uebungsfirmen.at$', value): raise NotValidActEmail WidgetValidatorDiscriminators(ActEmailValidator, context = ICustomer, field = IFpFlat['email']) --- snip - Normally, I simple did a provideAdapter(ActEmailValidator), which registered the above adapter in the global site registry. Unfortunately, this adapter should not be global, instead I need it site-specific. Therefore I tried the following, as I do with various utilities: sm = mySite.getSiteManager() sm.registerAdapter(ActEmailValidator) This does not work and generates the following traceback: snip - File /home/dusty/prog/bsp/buildout/eggs/ZODB3-3.8.1-py2.4-linux-x8 6_64.egg/ZODB/serialize.py, line 416, in _dump self._p.dump(state) PicklingError: Can't pickle InterfaceClass z3c.form.util.IGeneratedForObject_43371984: attribute lookup z3c.form.util.IGeneratedForObject_43371984 failed - snip From this point I'm stuck - does somebody know what to do here? I yesterday thought z3c.baseregistry could help, but it seems that it would not, as I need this registration persistent and not during Zope startup only. It should be possible to add such sites during runtime, whereas their configuration (and registration of this adapter) has to be persistent. Any hints? I guess this adapter is persistent (local) but not global because during startup there is no site involved. There is no way to have a local adapter involved for global schemas. If there is no global validation druing startup, and you need a local site validation then it's fine to use the baseregistry. but take care you can't use the adapter during adding the site itself. Then the adapter is only available if the site is added. Not during adding. Regards Roger Ineichen Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 ) ___ 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 )
[Zope-dev] Apache rewrite - HTTP_Host redirect issue
Hi Dan
I have an issue with the latest changes in
zope.publisher.http.py
The redirect method in HTTPResponse http.py line: 880
forces a ValueError. Because the Apache HTTP_HOST
and the target_host to not compare.
def redirect(self, location, status=None, trusted=False):
location = str(location)
if not trusted:
scheme, target_host, path, query, fragment = (
urlparse.urlsplit(location))
if target_host and target_host != self._request.get('HTTP_HOST'):
raise ValueError(
Untrusted redirect to host %r not allowed. % target_host)
Apache uses DOMAIN in HTTP_HOST like expected
and the method used with urlparse.urlsplit(location)
returns DOMAIN:PORT as target_host value.
I'm not sure if this is an issue or a bad Apache rewrite
configuration.
As far as I see we should remove the PORT part from the
target_host value. right?
I'm not sure if remove the port info from the value
if this is contra productive for security. If so
what is the correct concept for make the Apache
rewrite work? I guess there is no way to support both.
btw, I'll run into this problem after a redirect during
authentication login form to the cameform url. This
should be reproducable by any other apache (port) rewrite setup.
Regards
Roger Ineichen
_
Projekt01 GmbH
www.projekt01.ch
Boesch 65
6331 Hünenberg
phone +41 (0)41 781 01 78
mobile+41 (0)79 340 52 32
fax +41 (0)41 781 00 78
email roger.ineic...@projekt01.ch
_
END OF MESSAGE
___
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] official release policy ZTK is still not changed
Hi Betreff: Re: [Zope-dev] official release policy ZTK is still not changed -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Tuesday 15 September 2009, Reinout van Rees wrote: On 2009-09-11, Martijn Faassen faas...@startifact.com wrote: Jim Fulton wrote: but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1 -1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing. If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right? I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. I propose to delete the CHANGES.txt file after we tagged the trunk. This will force people to carefully read all the revisions till they will find the removed CHANGES.txt file for restore them. And of corse we should add a comit hook in subversion which will not allow to tag a trunk without a CHANGES.txt file. Hard enough? just kidding, Roger Ineichen ___ 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.app.security/trunk/ keep trunkversion at 0. Update changes
Hi Benji Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunkversion at 0. Update changes On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2009-9-10 22:23, Benji York wrote: 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Every newer release is the newest release independent from the version number. The latest release is the current which the index points to. PYPI doesn't know about a version (number) order. I'm not sure how buildout can handle that. I just remember that we run into a problem as we released an older bugfix version once and didn't use a KGS. Anyway, this doesn't matter if 1.2.3dev or 0 is used as next dev version. I'm fine with 0 too. Regards Roger Ineichen Doesn't it break all versioned dependencies on that package? I don't understand the question, so I'll say no. ;) -- Benji York Senior Software Engineer Zope Corporation ___ 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 ) ___ 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] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Gary Betreff: Re: AW: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else. It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. Whatever gets done needs to leave the existing test in place:: self.assertEqual(dict(request.form), dict(x='1', y='2')) for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Ah, this sounds good. We often use query string urls for simulate a post request e.g. foo.html?form.action.remove=1id=123 which forces to process the button action in z3c.form within a value 123 for the id field etc. I was afraid that this isn't working anymore if such query values will not longer work as request.form key/values But as far as I understand it's only a problem with POST and query strings and does not affect the above usecase. Maybe http://bugs.python.org/issue1817 gives you the information you want? Thanks a lot Roger Ineichen Gary ___ 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] Proposal: zope.app.publisher refactoring
Hi Michael Betreff: Re: AW: [Zope-dev] Proposal: zope.app.publisher refactoring Am 24.08.2009 um 22:55 schrieb Roger Ineichen: [...] Everything which has to do with login has nothing to do in z3c.layer.pagelet. z3c.layer.pagelet should only offer a working setup for pagelet based traversal stuff and error handling. Until we find a better place for it I'd like to keep it there as it is a basic implementation (ported from zope.app.security) of login/logout using pagelets/viewlets. It is the pagelet version of login/logout as the other parts are the pagelet version of error handling and traversal. I was looking another time at the z3c.layer.pagelet package. I agree that the added authentication support is usefull and was missing in the first releases. The loginForm.html pagelet should stay there. But we should move the viewlets to another package since this is optional and another concept which is not really needed by pagelets. e.g. z3c.authviewlet or so. Another reason for moving this viewlets is that this login/ logout viewlets are usfull too without using pagelets. Regards Roger Ineichen Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] Proposal: zope.app.publisher refactoring
Hi Dan Betreff: Re: [Zope-dev] Proposal: zope.app.publisher refactoring 2009/8/22 Michael Howitz m...@gocept.com: Am 21.08.2009 um 21:06 schrieb Dan Korostelev: [...] ILogin, ILogout from zope.app.publisher.interfaces.http - looks like these don't really mean anything and are used only in zope.app.security. I'd move them to zope.app.security even without BBB imports (not to make zope.app.publisher dependent on zope.app.security), but maybe I just don't know something about them? :) z3c.layer.pagelet also uses these interfaces to re-implement login/logout like zope.app.security but by using pagelets and viewlets. So it would be nice to have a better place for these interfaces, so z3c.layer.pagelet does not need to depend on zope.app.security. Are these interfaces used for anything else than just declaring them as implemented? :-) I don't see much sense in them, because they are too abstract and it's hard to understand what they are for, so I'd get just rid of them in z3c.layer.pegelet. Everything which has to do with login has nothing to do in z3c.layer.pagelet. z3c.layer.pagelet should only offer a working setup for pagelet based traversal stuff and error handling. Regards Roger ineichen -- WBR, Dan Korostelev ___ 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 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.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else. It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? Whatever gets done needs to leave the existing test in place:: self.assertEqual(dict(request.form), dict(x='1', y='2')) for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? Regards Roger Ineichen Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKkwXA+gerLs4ltQ4RAhVKAKDY5LuTUshFf1ihKTQXpJjyxvIeeACglpu8 FZSMcnQjaiOyax9ziOAlFNE= =qJS/ -END PGP SIGNATURE- ___ 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 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] Optional integration need not introduce dependencies
Hi Jim Betreff: [Zope-dev] Optional integration need not introduce dependencies In discussing dependencies, as we try to clean up dependencies of Zope (especially ZTK) projects, I've noticed a pattern that I think deserves some special handling. Often, a module (including a ZCML file) within a project provides an implementation of an interface defined by an external package or an adapter of a class or interface defined in the external package. If the module is optional and exists solely to integrate with the external API, then the external project need not be a dependency. Why? Because an application won't use this module unless it already uses the external project. For example, lots of projects provide publisher views or zcml configuration directives. As long as these are in optional modules or ZCML files, then dependencies on zope.publisher or zope.configuration aren't necessary, as no one will use these modules or zcml files unless they're already using zope.publisher or zope.configuration. Again, this assumes that these modules are optional. For example, if a project's configuration file, configure.zcml registers views or includes a configuration file that registers views, then the dependency on zope.publisher is not optional. Let's look at a more specific example. zope.app.publisher provides some xmlrpc view registrations for zope.container in xmlrpc/configure.zcml. If the xmlrpc module was optional, or if these container registrations were conditedl [1]_ on zope.container having been installed, then zope.app.publisher wouldn't need to depend on zope.container [2]_. As it stands though, one can't include the main configuration for zope.app.publisher without also configuring the container xmlrpc views, so zope.container is required. Jim .. [1] We can make these registrations conditional on zope.container like this: configure condition=installed zope.container view for=zope.container.interfaces.IItemContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ItemTraverser permission=zope.Public / view for=zope.container.interfaces.IReadContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ContainerTraverser permission=zope.Public / /configure .. [2] This assumes we could get rid of the zope.container import in browser/tests/test_directoryresource, which I strongly suspect we can.) I think XML-RPC just belongs to an own package e.g. zope.xmlrpc. It doesn't make sense to have XML-RPC in a package other then an own. If we move the XML-RPC part out of other packages, then we have the question should the zope.xmlrpc package depend on IContainer? Probably not and the new zope.xmlrpc package should use your suggested conditional configuration. Such an own zope.xmlrpc package whould depend on the publisher as much as the XML-RPC implementation does. This allows to use a custom XML-RPC implementation based on something else then the publisher concept. (custom xmlrpc package) Does this make sense? btw, I think XML-RPC should be an optional package like z3c.jsonrpc. The same belongs to FTP and WebDav support. (Not sure if WebDav is optional, at least FTP is optional configurable at zope.conf level) Regards Roger Ineichen -- Jim Fulton ___ 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 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] z3c.recipe.i18n and zope.app.locales.extract
Hi Yuppie Betreff: Re: z3c.recipe.i18n and zope.app.locales.extract Hi Roger! 1.) running tests - Proposal: Remove those two lines in test.py. Done. 2.) looking up the product version -- Proposal: Catch the error. Return an empty string if version is not found. The problem was somewhere different: Caused by wrong dependencies zope.app.applicationcontrol was not available. After fixing the dependencies the method works without error and 'Development/Unknown' is returned with Zope 2. That's sufficient for me. 3.) customizing the .pot header --- Proposal: The easiest and most flexible way to customize this seems to be an option that allows to specify a file that contains the pot_header template. This is still missing. I plan to subclass POTMaker in z3c.recipe.i18n instead of modifying zope.app.locales.extract. 4.) looking up basePath --- Proposal: Use the 'if' code for all packages. Done. (At least if nobody complains.) 5. writing makers - Proposal: Pass in the additional arguments and fall back to the old signature for BBB. Done. I also added site_zcml as argument. What about wrapping py_strings, zcml_strings and tal_strings in functions that implement the new interface? This would make it possible to add them to the makers list and call them in the same loop. Yes, why not. Probably we should do this together with a refactoring and change/enhance the method signature for the pot makers. Regards Roger Ineichen _ END OF MESSAGE ___ 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] z3c.recipe.i18n and zope.app.locales.extract
Hi yuppie
-Ursprüngliche Nachricht-
Von: zope-dev-bounces+dev=projekt01...@zope.org
[mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im
Auftrag von yuppie
Gesendet: Mittwoch, 15. Juli 2009 21:04
An: Zope-Dev List
Betreff: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi!
I plan to use z3c.recipe.i18n for some Zope 2 CMF products.
But to get things working I did have to modify z3c.recipe.i18n a bit.
It would be nice if I could get some feedback regarding the
issues I found:
1.) running tests
-
test.py tries to install 'zodbcode' and 'zope.app.interface'.
That doesn't work for me. AFAICS those two eggs are no longer
indirect testing dependencies. After removing those two lines
all tests pass.
Proposal: Remove those two lines in test.py.
That's fine
2.) looking up the product version
--
POTMaker._getProductVersion() doesn't work for me.
zope.app.applicationcontrol is not used by Zope 2 and is not
part of the specified dependencies. This raises an error.
Proposal: Catch the error. Return an empty string if version
is not found.
Sounds good to me as a workarround
Probably we should try to use the package version of the egg
which uses the i18n recipe?
3.) customizing the .pot header
---
POTMaker.write() uses a harcoded Zope 3 specific pot_header template.
Proposal: The easiest and most flexible way to customize this
seems to be an option that allows to specify a file that
contains the pot_header template.
Yeah, that's a nice option
4.) looking up basePath
---
i18nextract.main() contains these lines:
# add maker for each given path
for pkgName, path in eggPaths:
srcIdx = path.rfind('src')
if srcIdx == -1:
# this is an egg package, strip down base path
basePath = path
moduleNames = pkgName.split('.')
moduleNames.reverse()
for mName in moduleNames:
mIdx = path.rfind(mName)
basePath = basePath[:mIdx]
pkgPath = path[len(basePath):]
else:
# this is a package linked in as externals
basePath = path[:srcIdx]
pkgPath = path[len(basePath):]
I don't understand why we need different code for packages
linked in as externals. The egg package code works
actually better for linked in packages that don't follow the
'src' convention.
Proposal: Use the 'if' code for all packages.
I was fighting several times with this part during coding.
The only thing which this part has to make sure is that
we do not use anything outside of the package in our path.
The reason for not including everything outside the package
in our path is that such a path whould be depend on the
local setup e.g.
D:\foo\dev\zope\session:3
We only have to make sure that this never will happen and that
we for each use case generate path like:
zope/session.py:3
It could be that the if part is working for all usecases.
but I'n not sure without debugging.
5. writing makers
-
I'd like to specify additional makers. This is a nice hook,
but why are only these three arguments passed to custom poMakers?
maker.add(poMaker(path, basePath, exclude_dirs),
basePath)
I miss 'domain' and 'include_default_domain'.
Proposal: Pass in the additional arguments and fall back to
the old signature for BBB.
Does all that make sense? Any objections or better ideas?
Should changes for POTMaker go into zope.app.locales.extract
or should
z3c.recipe.i18n use a customized version?
I think it's probably the best idea to enhance the
method signature in zope.app.locales.extract if this
is possible without to break compatibiliy.
Yes, everything makes sense to me.
Thanks a lot yuppie,
this are very good improvments for z3c.recipe.i18n
Regards
Roger Ineichen
___
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] z3c.recipe.i18n and zope.app.locales.extract
Hi Yuppie
Betreff: Re: z3c.recipe.i18n and zope.app.locales.extract
Hi Roger,
Thanks for your feedback!
Roger Ineichen wrote:
-Ursprüngliche Nachricht-
2.) looking up the product version
--
POTMaker._getProductVersion() doesn't work for me.
zope.app.applicationcontrol is not used by Zope 2 and is
not part of
the specified dependencies. This raises an error.
Proposal: Catch the error. Return an empty string if
version is not
found.
Sounds good to me as a workarround
Probably we should try to use the package version of the egg which
uses the i18n recipe?
Not every buildout is itself an egg. So in any case we need a
fallback.
In my use case I plan to set the version manually in the
pot_header template. So I don't need the version lookup.
Agreed, sound good to me.
i18nextract.main() initializes POTMaker this way:
# setup pot maker
maker = POTMaker(output_file, '')
The second argument is the path that is used by
POTMaker._getProductVersion() to look up a 'version.txt'
file. Maybe we could use a better path than ''. But I'll
leave it to someone else to figure that out.
I'm not sure and didn't look at the code but I guess
the existing zope implementation depends on subversion
get version info or something like that. This pattern is
probably totaly out of date since we use buildout and eggs.
4.) looking up basePath
---
i18nextract.main() contains these lines:
# add maker for each given path
for pkgName, path in eggPaths:
srcIdx = path.rfind('src')
if srcIdx == -1:
# this is an egg package, strip down base path
basePath = path
moduleNames = pkgName.split('.')
moduleNames.reverse()
for mName in moduleNames:
mIdx = path.rfind(mName)
basePath = basePath[:mIdx]
pkgPath = path[len(basePath):]
else:
# this is a package linked in as externals
basePath = path[:srcIdx]
pkgPath = path[len(basePath):]
I don't understand why we need different code for
packages linked in
as externals. The egg package code works actually better for
linked in packages that don't follow the 'src' convention.
Proposal: Use the 'if' code for all packages.
I was fighting several times with this part during coding.
The only thing which this part has to make sure is that we
do not use
anything outside of the package in our path.
The reason for not including everything outside the package in our
path is that such a path whould be depend on the local setup e.g.
D:\foo\dev\zope\session:3
We only have to make sure that this never will happen and
that we for
each use case generate path like:
zope/session.py:3
It could be that the if part is working for all usecases.
but I'n not sure without debugging.
Debugging doesn't help much if we don't know all use cases.
Yes, that's true
What about testing it like this:
We remove the 'else' part and wait until someone complains.
In that case we have a scenario for testing and fixing the
issue. If nobody complains, the 'else' part was indeed useless.
The current code doesn't work for me because 'src' is found
but not the right place to split the path.
I'm fine with that. I can test the changes with the project
which I used as base when I wrote the path cleanup code.
Agreed, using src as a hard coded name can end in a bad
result.
Regards
Roger Ineichen
___
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] z3c.form pass context to multi widgets in MultiConverter
Hi Gerhard Betreff: [Zope-dev] z3c.form pass context to multi widgets in MultiConverter Hi, some widgets may require a valid context to work properly. one such widget is z3c.formquery. The attached patch passes the current widget's context to the sub widgets during data conversion in z3c.form.converter.MultiConverter. The patch handles this the same way as passing the form property is implemented. (The patch is against current trunk). Sorry, but I was not sure how to add a test for this. (However, there is also no explicit test for passing the form property). I ran the current test suite with python2.4 and it did not cause any additional issues :) . The second patch here was required on my system. It seems, that zope.app.component is a missing dependency for z3c.form. (at least for now). cheers, Gerhard -- Index: src/z3c/form/converter.py === --- src/z3c/form/converter.py (revision 101721) +++ src/z3c/form/converter.py (working copy) @@ -359,6 +359,10 @@ #form property required by objecwidget widget.form = self.widget.form zope.interface.alsoProvides(widget, interfaces.IFormAware) +if interfaces.IContextAware.providedBy(self.widget): +# context property may be required by objectwidget +widget.context = self.widget.context +zope.interface.alsoProvides(widget, + interface.IContextAware) converter = zope.component.getMultiAdapter((field, widget), interfaces.IDataConverter) @@ -377,6 +381,10 @@ #form property required by objecwidget widget.form = self.widget.form zope.interface.alsoProvides(widget, interfaces.IFormAware) +if interfaces.IContextAware.providedBy(self.widget): +# context property may be required by objectwidget +widget.context = self.widget.context +zope.interface.alsoProvides(widget, + interface.IContextAware) converter = zope.component.getMultiAdapter((field, widget), interfaces.IDataConverter) Much thanks for your improvments! There is a form property called ignoreContext. If this property is set, the context is ignored explicit. You can set the ignoreContext property on selected widgets or in a form. I'm not sure but it looks to me that the ignoreContext property should also be a part of this patch. My question, The following line in the code will set/dispatch the context: widget.context = self.widget.context Are I'm right, the context of the self.widget.context could be an ignored context but the widget.context should not ba an ignored context? Is this a valid usecase? At least I think this was also not supported without your patch. If this makes sense, the patch should probably do soemthing like: if not widget.ignoreContext widget.context = widget.form.context This whould prevent to set an ignored context from self.widget.context to the widget.context. I'm really not sure if this is working, but does this make sense to you? Regards Roger Ineichen ___ 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] z3c.form pass context to multi widgets in MultiConverter
Hi Gerhard Betreff: Re: AW: [Zope-dev] z3c.form pass context to multi widgets in MultiConverter [...] If this makes sense, the patch should probably do soemthing like: if not widget.ignoreContext widget.context = widget.form.context This whould prevent to set an ignored context from self.widget.context to the widget.context. I'm really not sure if this is working, but does this make sense to you? Regards Roger Ineichen Thanks for the comment. For this particular use case it won't work without the context,. The context is used to look up further objects in the containment hierarchy. At this particular part in the code it is just about converting from/to widget/field value. So ignoreContext/ignoreRequest are not used anyway. (at least not to retrieve widget values). However, maybe it would be better to pass ignoreContex and ignoreRequest to the sub-widget, and let the sub-widget decide whether to ignore the context/request or not. This could especially be useful in other parts of the muti-widget code. Yes good idea, this makes sense to me. Can you commit this to the trunk with a test? Regards Roger Ineichen _ END OF MESSAGE ___ 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] Making PersistentList satisfy zope.schema.List
Hi Paul -Ursprüngliche Nachricht- Von: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] Im Auftrag von Paul Carduner Gesendet: Dienstag, 30. Juni 2009 21:18 An: zope-dev Betreff: [Zope-dev] Making PersistentList satisfy zope.schema.List I noticed that PersistentList and PersistentDict do not satisfy zope.schema.List or zope.schema.Dict, which is rather annoying. For example: class IBlogPost(Interface): tags = zope.schema.List(title=u'Tags', value_type=zope.schema.TextLine) class BlogPost(Persistent): implements(IBlogPost) tags = FieldProperty(IBlogPost['tags']) def __init__(self): super(BlogPost, self).__init__() self.tags = persistent.list.PersistentList() #aaah, WrongType error... will throw a WrongType: ([], type 'list') error, which is especially confusing because the repr for PersistentList makes it look an awful lot like a regular list. same thing happens with PersistentDict. I would like to modify zope.schema._bootstrapfields by changing the _type attribute of the List class to (list, UserList), and do the same for Dict with (dict, UserDict). Then anything inheriting from UserList (including PersistentList) will satisfy the schema. Can anyone think of a reason why this would be bad? I think it's different. If you use a zope.schem.List field the widgets will store the list at once. This whould replace the initial created PeristentList. (or not?) In general if you store a simple list as attribute on a persistent class it's fine, everything is stored. If you like to append or pop from this list, then yes, you will need a PersistentList otherwise the changes in the list are not stored back to the DB. (right?) Fazit, the zope.schema.List field and the Sequence widget is not compatible with initial PersitentList beause the widget will probably replace the list with a simple list. Note, I'm not 100% sure if I'm correct. But it is at least something which we have to make sure that this is working. Regards Roger Ineichen -- Paul Carduner http://www.carduner.net ___ 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 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.app.publisher/trunk/ To makebrowsers update their caches of resources immediately when the
Hi all Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.publisher/trunk/ To makebrowsers update their caches of resources immediately when the On Tuesday 09 June 2009, Wolfgang Schnerring wrote: To make browsers update their caches of resources immediately when the resource changes, the absolute URLs of resources can now be made to contain a hash of the resource's contents, so it will look like /++noop++12345/@@/myresource instead of /@@/myresource. - Implemented an AbsoluteURL adapter that computes a hash of the resource's contents and inserts that into the URL. - Content hashes will be cached in memory, except when in developer mode - Introduced a ++noop++ traverser that simply throws away the path segment - Wrote a bit of documentation about resources Mmmh, this looks like a lot of extra code to get behavior that is served better with different tools. Have you looked at z3c.versionedresource and z3c.traverser? Both of those should solve these type of use cases well. Serving resources from a Zope server and caching them for speedup is not the best pattern. I recommend to use a content delivery network concept and off load the resource traffic from zope at all. And as stephan suggested, using the same name for a changed resource is a bad thing. This implementation seems to me like a workarround for serving the same url for changed resources. I also recommend to use different resource names for different resource versions. z3c.versionedresource offers such a concept. anyway, I whould be happy if we do not implement such high level feature in zope core packages. Because there are 1000 different concepts to do it right. Why did you not use an additional package? Regards Roger Ineichen ___ 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.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hi Martijn Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports Hey, Stephan Richter wrote: [snip] I have been following this discussion and just want to mention that I fully agree with Roger. If you release a final version of Zope or a package that spews deprecation warnings or has not fixed the imports, then this should be considered bad releasing. I'm not sure I understand this. If you are releasing a final version of zope.app.component, do you want it *not* to spew deprecation warnings? My fear is that deprecated imports will pull in packages and act as the single point of an egg declaration. If someone removes a dependency during a deprecation import cleanup lets say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then it's possible that a custom project didn't fix the zope.formlib depndency in his setup.py because there is no need to do so. Good luck if the last egg cleans up the zope.formlib dependency and you didn't fix it in your project for your self. This will end in loosing the dependency at all and you don't know why. Of corse you can fix this lost dependency and add it to your setup.py. But you still don't know why. You also can't find information about why in the zope.formlib package is not needed anymore because another package is responsible for not using the zope.formlib package. I''m pretty sure that at this moment you like to know if you should still like to depend on zope.formlib or not and also change to something else, but to what? What get refactored and is not using zope.formlib anymore? With deprecation warnings, you get very early informed and you will see which package are using newer versions. This will give you the required information that you also should switch a to another better concept. The deprecation message is a very important information and can keep you informed on what's going on and about new better concepts. Regards Roger Ineichen Or do you mean you require someone to go through all packages that may depend on zope.app.component and change the imports there before zope.app.component is released? But if so, you'd need to release zope.app.component with deprecation warnings. I'm absolutly sure you should not release packages in a KGS with deprecation warnings or deprecated imports. Of corse there could be a package which uses deprecated imports because another package get refactored. but not in a KGS. I think this is an important point. We agree that there could be packages with deprecated imports. but the release manager of the KGS has to do all the work for a clean deprecation free KGS release. That's a pain for them. Several times in the previous discussion I heard people talk about wanting to support multiple releases of a single package and not wanting indirect deprecation warninsg. I'm not going to defend their view here myself, but I must note we've been spending some months now moving away from zope.deprecation. I highly doubt that this will hurt us seriously in the coming years. And if it does, at least we'll be using Python imports amenable by analysis by any Python programmer, with records in the CHANGES.txt that can be read by anyone, and not our own home-grown import system using module proxies. The current situation without deprecation warnings requires to read and follow 100 - 115 CAHNGES.txt files for some of our projects. That's just a pain. And I'm pretty sure nobody which proposes to skip deprecation messages and uses such an amount of packages is reading every CHANGES.txt file. I'm 100% sure nobody not invloved in the core development is happy with reading such an amount of CHANGES.txt files. And as more as I think about our concept I think it's totaly wrong. It's just bad to officialy recommend that everybody should read the CHANGEs.txt or he get lost in working with Zope packages. Note if you will loose a dependency(egg) you can't read the CHANGES.txt file of the lost package, you have to find out why you lost the dependency an consult all CHANGES.txt files from all of your used packages. Regards Roger Ineichen Regards, Martijn ___ 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 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] RFC: Site - Locus
Hi Martjin, Christian Betreff: [Zope-dev] RFC: Site - Locus [...] The second plan is my favorite if it is possible dependency-wise and zope.component doesn't take on new dependencies. I think support for local components could very well be part of zope.component conceptually. It would allow us to eliminate one package (zope.site) without introducing any new packages (the other plan increases the amount of packages by one, trading zope.site for zope.locuscontainer). What do people think about: * the idea of renaming Site to Locus Oh my god, many -1 * the plan for refactoring? I think we have other things to cleanup in zope.site befor we think about to split something out as the same as before. What I like to see is that we remove the default Folder container and simplify the hole implementation. Since Jim and Stephan refactored the component registry we are able to skip the half setup we use today. There is no need to support a default Folder for our utilities since we can registrer utilities everywhere. Such registered component will get found, doesnt' matter where they are located etc. I think a dependency cleanup and split the same old bad concept into different packages is not usefull right now. Are you aware of all the overhead we have in zope.site right now? We also have a bad/broken registry. I think Christian Theuni also knows about it. Not sure if this is fixed or if some utility registrations still hang arround in the local registry but shouldn't. If so, we have to take care if we touch the existing implementation and find out what could happen on all our production systems. And we need to support a fix for this broken registrations befor we touch or move something. Chistian, are I'm correct that you run itno that too. Did you fix something in zope.app.site once or did you add an issue on launchpad? I remember something but not sure if I'm correct. Regards Roger Ineichen ___ 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.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hi Martjin Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports Hey, Roger Ineichen wrote: [snip] My fear is that deprecated imports will pull in packages and act as the single point of an egg declaration. If someone removes a dependency during a deprecation import cleanup lets say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then it's possible that a custom project didn't fix the zope.formlib depndency in his setup.py because there is no need to do so. I'm not sure I understand, but if you directly use zope.formlib you should have a direct dependency on it in your setup.py. should is the right word for this ;-) Good luck if the last egg cleans up the zope.formlib dependency and you didn't fix it in your project for your self. This will end in loosing the dependency at all and you don't know why. Of corse you can fix this lost dependency and add it to your setup.py. But you still don't know why. You also can't find information about why in the zope.formlib package is not needed anymore because another package is responsible for not using the zope.formlib package. If you don't use zope.formlib, there isn't a problem. If you do use it, you should declare it. I'm not sure I understand the problem here. Of course the dependency refactoring will cause breakages here and there, but I don't think they're intractable (especially if we do provide a KGS for the toolkit packages). The deprecation message is a very important information and can keep you informed on what's going on and about new better concepts. I think you should be reading the CHANGES.txt of the packages you depend on when you upgrade the dependency. If you *don't* depend on a package directly, you normally shouldn't have to be concerned when it disappears. Of course there might be bugs introduced in this process: packages you do somehow indirectly depend on disappear. That's something we'll have to live with if we want to move forward at all. I don't see how zope.deprecation is going to make any difference in this in any way however - you won't see any deprecation warnings either as the underlying package is simply gone. The point is that the deprecation message informs you for upcomming work. Which is a good information. I do not read the CHANGES.txt files ever night. A CHANGES.txt can contain much much better information than the deprecation warnings ever could. It can detail what happened, why it did, and what you should be doing. I've been rather confused with a what now? feeling when confronted with deprecation warnings in the past, and there was nothing else but these messages that I could investigate. Of corse should we have CHANGES.txt files. A deprecation warning should show a link where vi and emac users can write script which points directly to the CHANGES.txt at pypi if they click on the deprecation warning link ;-) Regards Roger Ineichen Regards, Martijn ___ 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 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] RFC: Site - Locus
Hi Martjin Betreff: Re: [Zope-dev] RFC: Site - Locus Hey, Roger Ineichen wrote: [snip] What do people think about: * the idea of renaming Site to Locus Oh my god, many -1 Motivations beyond oh my god? My first motivation was the same as Jens had. Lokus is such a unique word in german that you defently think this is a typo if you read Locus But I think right now we have: - a well known pattern with the ISite - the concept is not bad or wrong - the site is not a page (in web terms) - the site is a kind of root (in web terms) - the site map is an overview of what a site includes (in web terms) I can't think there could be a better name for what the site pattern does right now. There is absolutly no reason why we should use another name for the same concept we use the last 5 years. Probably I missed something in your proposal, but as far as I can see you don't propose to change something in the concept of the site pattern? right? One reason Locus might be a bad word is because it's easily confused with Location, a concept we already have. What I like to see is that we remove the default Folder container and simplify the hole implementation. I'm proposing we separate the folder implementation from the basic site functionality. It will then become easier for people to ignore the folder implementation and not use it, while we retain backwards compatibility for those who do need it. Probably a good idea [snip] I think a dependency cleanup and split the same old bad concept into different packages is not usefull right now. What is the same old bad concept? Details? Are you aware of all the overhead we have in zope.site right now? Since I actually assembled these things into zope.site, I have some awareness of what is in there. Could you actually point to specific points in the zope.site code? It's not a lot of code, after all. I'm proposing we move some of this code into zope.component, and the rest into zope.container (or we could leave it in zope.site for now). Where is the overhead we can safely remove? The site offers a SiteManagementFolder, SiteManagerContainer and a LocalSiteManager. The SiteManagementFolder by default installed as ['default'] is absolutly useless and obsolate since the last refactoring. It's just a container, earlier it was a kind of namespace. Also the lookup concept for this default container should get reviewed. I also think since we do not offer a Zope 3 application server the hole default setup which is not needed for a working local component registry shuld probably go to a own package. I think the hard part of refactoring the ISite and local utility concept is to moe the right concept how this pakage get used into diefferent packags and not the components. My first step whould be to write down the differen usecase of zope.site, global and local utilities, location, component and the registry which brings everything together. Just refactoring zope.site and move the same packages arround because of dependencies is in my point of view the wrong thing. We need to define wich package will offer which parts of the hole site concept. otherwise it could be useless if at the end all packages get used together in 99% of all Zope projects. What do you like to use independently from each other which is now assembled as a unit in zope.site? Regards Roger Ineichen Regards, Martijn ___ 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 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] RFC: Site - Locus
Hi Martjin Betreff: Re: [Zope-dev] RFC: Site - Locus I think if we really need a better naming, we should think about how everyting will fit together. e.g. application, root, site, registry, local, global component, location, container, item, etc. I don't think locus is the right missing part for a better understanding if you need to explain the zope world. Regards Roger Ineichen ___ 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] RFC: Site - Locus
Hi Jim Betreff: Re: [Zope-dev] RFC: Site - Locus A few high-level comments. 1. I admire your desire to make this clearer. :) 2. I think local configuration address use cases that most people don't have but introduce complexity that I bet a lot of developers trip over. 3. I think the right word here is local registry. I think the whole concept should be labeled as advanced and we should discourage people from even pondering it unless they have a strong use case, like wanting to host multiple web sites with different configs in the same application. :) 4. I think we should step back (re)think how we handle the goals that drive this. If we do, we might come up with something so different that we'd make this discussion moot. probably we can also find a simpler concept for make local configuration available with global configration files like we have done in z3c.baseregistry. This could have the benefit of both local and global done with the same pattern e.g. zope.configuration. I think global and local ist not so confusing, but the need to define global and local configuration in a totaly different way is complex to explain and understand. Regards Roger Ineichen ___ 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] RFC: Site - Locus
Hi Martjin Betreff: Re: [Zope-dev] RFC: Site - Locus Roger Ineichen wrote: [snip] The site offers a SiteManagementFolder, SiteManagerContainer and a LocalSiteManager. The SiteManagementFolder by default installed as ['default'] is absolutly useless and obsolate since the last refactoring. It's just a container, earlier it was a kind of namespace. Yes, with Grok we've been installing directly in the SiteManagementContainer (which contains the folder, if I got my terminology right). We can't just get rid of this though, as it would break a lot of existing ZODBs. [snip] Just refactoring zope.site and move the same packages arround because of dependencies is in my point of view the wrong thing. We need to define wich package will offer which parts of the hole site concept. otherwise it could be useless if at the end all packages get used together in 99% of all Zope projects. Of course if we make such a separation each end needs to be useful for something. What do you like to use independently from each other which is now assembled as a unit in zope.site? One use case I have is that I want to be able to write tests that just deal with site management without pulling in a lot. I have done this with hacked up code now in both z3c.saconfig and hurry.custom. I don't know this packages, but I agree, simpler testing setup is a great use case The other use case I have is that I want to write packages that just need to be able to set the site or get the site and shouldn't need to care about, or depend on, zope.container at all. Probably a rare use case or could become imporant if we use other patterns then the container traversal pattern. Do you have some ideas of using a contianer less traversal pattern? Regards Roger Ineichen Regards, Martijn ___ 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 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] refactoring site functionality
Hi Wichert -Ursprüngliche Nachricht- Von: zope-dev-bounces+dev=projekt01...@zope.org [mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im Auftrag von Wichert Akkerman Gesendet: Donnerstag, 28. Mai 2009 17:21 An: Martijn Faassen Cc: zope-dev@zope.org Betreff: Re: [Zope-dev] refactoring site functionality Previously Martijn Faassen wrote: * often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed. That sounds like a complicated workaround for not having a mutable global configuration. Or the right concept if a Server restart is not an option ;-) btw, you are pointing to a good direction. Didn't we talk about reload global configuration during runtime years ago? Regards Roger Ineichen Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 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.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi Reinout Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports On 2009-05-26, Roger Ineichen d...@projekt01.ch wrote: Some people think it's better to have a nice clean log then deprecation warnings on server startup. I still don't understand the reason if there is any. Probably others can explain why we skip the deprecation warnings which is a hugh win for migration tasks. Main reason: often you get buried in deprecation warnings which then drown out potentially more important warnings. When migrating: yes, such deprecation warnings are handy. But in 99% of the cases you'll just be *using* the various libraries and you still get a load of warnings. Complaints/questions about the huge list of deprecation warnings in earlier plone versions were a regular occurrence on the mailinglists. So: yes, there's a reason. Perhaps not the best one, but still. I think there is something else wrong if someone is using code with deprecation warnings in a production setup. The deprecation warning should never show up on a production server because you have to make sure that you don't use deprecated code. That's the only goal of the deprecation system. Your reason says that you like to use packages with deprecated code in a production setup. On the other side developer which take care on deprecated code can't be sure that we use deprecateded code or not. That's not nice. I was afraid excatly of this use case. Skiping deprecation warnings is a workarround for official release and use deprecated code instead of update everything. A good solution whould prevent to use deprecated code in a production setup and not only skip the deprecation warnings because we as developer know that this will also works. btw, I also think indirect imports are not the same as deprecated imports. Of corse a deprecated import is a indirect import but a indirect import is not implicit a deprecated import. That's just a very ugly pattern for do something which should be done in another way. Parsing # BBB comments whould be a better solution for find deprecated imports. Regards Roger Ineichen Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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 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.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi Martijn Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports Hi there, Before we have this discussion yet again, I will record the official stance in the zope toolkit decisions document, and I'll quote it here: * When code moves to a new location to import it from (in the same or another package), use a ``from foo import bar`` statement, with a ``#BBB`` comment to indicate the import is only there to support backwards compatibility. In the CHANGES.txt of a package, state that an import location got deprecated and where the new location is (making this a feature release, not a bugfix release). Reasons: * it avoid a dependency on zope.deprecation, which is quite involved in its implementation, using proxies. * A ``from .. import ..`` is immediately comprehensible to any Python programmer as well as tools. * Deprecation warnings make it hard to write a library that supports multiple versions of another library; a change in an indirect dependency can create deprecation warnings that the original developer does not care about. * We are in the process of developing a testrunner extension that will report on indirect imports, and a ZODB upgrade procedure. Feel free to discuss it, either to add arguments to refine this, or to attempt to overthrow this decision entirely. The only thing I could say about this concept is that we didn't start to remove #BBB marked imports. Just wait till we start remove the BBB imports and the packages from install_requires ... Regards Roger Ineichen Regards, Martijn ___ 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 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.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hi Paul Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports On Wed, May 27, 2009 at 02:06:03PM +0200, Roger Ineichen wrote: I think there is something else wrong if someone is using code with deprecation warnings in a production setup. Do you not use any third-party code? No not really, just python, zope and z3c libraries, on windows some win32 or ctypes. Often, the deprecation warnings are emitted by code not under your control. I think using packages with deprecated code is just a workarround if someone needs to use new features which is built in a newer version of a package and can't use all the newer versions of the packages this package depends on. (BBB) The better way is to use the old package or the new set of packages. I agree that this is not always possible. But we should not excuse us and tink that this is correct. It still has a hugh potential of problems because the set of versions is based on BBB and this part is not well tested or test are removed. Most the time if you will run into unexpected problems, some untested old BB code is involved. Take a look at the old registry code in our zope packages as a sample. Regards Roger Ineichen - PW -- Paul Winkler http://www.slinkp.com ___ 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 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.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports
Hi Stephan -Ursprüngliche Nachricht- Von: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] Im Auftrag von Stephan Richter Gesendet: Dienstag, 26. Mai 2009 02:33 An: zope-dev@zope.org Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports On Monday 25 May 2009, Shane Hathaway wrote: +- Replaced the dependency on zope.deprecation with BBB imports As a general question, how will people know that an import location changed? Some people think it's better to have a nice clean log then deprecation warnings on server startup. I still don't understand the reason if there is any. Probably others can explain why we skip the deprecation warnings which is a hugh win for migration tasks. Regards Roger Ineichen _ END OF MESSAGE ___ 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.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports
Hi Tres Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 25 May 2009, Shane Hathaway wrote: +- Replaced the dependency on zope.deprecation with BBB imports As a general question, how will people know that an import location changed? - - By reading changelogs. - - By running the indirect imports checker script on their code. Sound interesting, what's an indirect imports checker script? Regards Roger Ineichen _ END OF MESSAGE ___ 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] z3c.recipe.i18n tests break on unix
Hi Christian
Betreff: [Zope-dev] z3c.recipe.i18n tests break on unix
Hi,
the tests of z3c.reipce.i18n break on unix systems, for instance with:
Failed example:
ls('bin')
Expected:
- buildout-script.py
- buildout.exe
- i18ncompile-script.py
- i18ncompile.exe
- i18nextract-script.py
- i18nextract.exe
- i18nmergeall-script.py
- i18nmergeall.exe
- i18nstats-script.py
- i18nstats.exe
Got:
- buildout
- i18ncompile
- i18nextract
- i18nmergeall
- i18nstats
What's the general way of testing those things in both
environments? I don't have a windows box to test this. I also
see most recipes are tested only for unix (which would be
fine for me).
How should we proceed in this special case? Actually there is
a bug which I'm going to fix w/o having passing tests now.
I'm fine if you switch the tests that they pass on linux and
will break on windows. I can catchup the tests later and try
to make them running again on windows and linux.
Thanks a lot for help improve missing parts or fix issues!
Regards
Roger Ineichen
Regards,
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale)
· germany http://gocept.com · tel +49 345 1229889 4 · fax +49
345 1229889 1 Zope and Plone consulting and development
___
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 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.app.publication dependencies (volunteersneeded!)
Hi Michael Betreff: Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!) Am 13.05.2009 um 19:55 schrieb Martijn Faassen: [...] From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib. I can merge this branch in the next days and cut a release. As long as z3c.template depends on chameleon, lxml etc. I think this is a no go for core zope packages. We need to get rid of z3c.pt and offer a better optional implementation for z3c.pt support. note; I like z3c.pt very much and think this is a great package. But the built in compatibility layer is a very bad thing. Regards Roger Ineichen _ END OF MESSAGE ___ 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] zope.testing broken!
Hi all The latest zope.testing is broken on windows. It uses subprocess with a not supported argument on windows (close_fds). Traceback (most recent call last): File C:\Python25\lib\threading.py, line 486, in __bootstrap_inner self.run() File C:\Python25\lib\threading.py, line 446, in run self.__target(*self.__args, **self.__kwargs) File d:\home\.buildout\eggs\zope.testing-3.7.4-py2.5.egg\zope\testing\testrunner \runner.py, line 406, in spawn_layer_in_subprocess stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True) File C:\Python25\lib\subprocess.py, line 552, in __init__ raise ValueError(close_fds is not supported on Windows ValueError: close_fds is not supported on Windows platforms Regards Roger Ineichen _ END OF MESSAGE ___ 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.publisher/trunk/ Added some BBB code to setDefaultSkin
Hi Hanno Regards Roger Ineichen _ END OF MESSAGE -Ursprüngliche Nachricht- Von: Hanno Schlichting [mailto:hanno...@hannosch.eu] Gesendet: Montag, 27. April 2009 09:16 An: d...@projekt01.ch Betreff: Re: AW: [Checkins] SVN: zope.publisher/trunk/ Added some BBB code to setDefaultSkin Hi. Roger Ineichen wrote: Log message for revision 99518: Added some BBB code to setDefaultSkin to allow IBrowserRequest's to continue to work without configuring any special adapter for IDefaultSkin. Lot's of code inside Zope2 relying on using the request object without tons of CA setup I don't comment this. but, You broke my hole refactoring. My refactoring was making it possible to use IDefaultBrowserLayer less IBrowserRequest. Your changes apply now to every IBrowserRequest an IDefaultBrowserLayer where explicit was no default layer configured for. This is bad because and makes the previous refactoring obsolate. Can you revert this changes? Then there's some tests and description missing proving that intent. All I could read in the changelog and the skinnable tests was pointing in the other direction: Making it possible to use the Skinnable concept without relying on IBrowserRequest. The whole JSONRequest (which is not a BrowserRequest) tests inside skinnable.txt continue to work. Yes, I think everything was tested, but probably future ideas are not documented. There where some discussion about to split each request into it's own packages. All I did here was to move two constructs from ZCML into direct code. The lines I added do exactly the same as the default adapter registered as: Uhh, this is call hard coded and makes it impossible to exclude the adapter with the exclude directive. adapter name=default factory=.skinnable.getDefaultSkin for=zope.publisher.interfaces.browser.IBrowserRequest provides=zope.publisher.interfaces.IDefaultSkin / Unless I got something wrong, no behavior was changed if you load zope.publisher's configure.zcml. For Zope2 it is now just possible to continue to ignore that configure.zcml as it had done before. I see two things which are bad. Skinnable depends now on IBrowserRequest. I moved the skinnable concept out of the browser request part. This allows us to separate the skinnable and all different request types into own packages if we do future refactoring. And each IBrowserRequest will get typed by a IDefaultBrowserLayer which doesn't allow to have a default skin less browser request. I still think we should revert this changes. The skinnable concept is a base pattern which should not know about the different request types. Regards Roger Ineichen Hanno ___ 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.publisher/trunk/ Added some BBB code to setDefaultSkin
Hi Hanno Betreff: Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Added some BBB code to setDefaultSkin Hi. Roger Ineichen wrote: Roger Ineichen wrote: Then there's some tests and description missing proving that intent. All I could read in the changelog and the skinnable tests was pointing in the other direction: Making it possible to use the Skinnable concept without relying on IBrowserRequest. The whole JSONRequest (which is not a BrowserRequest) tests inside skinnable.txt continue to work. Yes, I think everything was tested, but probably future ideas are not documented. There where some discussion about to split each request into it's own packages. Where did that discussion happen? All I have heard of was discussions at PyCon, where nobody quite seemed to see any point in the whole different request types story at all anymore. I don't mind if the skinnable story gets less intermingled with the request story in a new zope.skinnable package and breaks some backwards compatibility at that point. Right now that mix of the two concepts is so prevalent in all kinds of places, that I'd rather stay on the backwards compatible side. Can you tell me what was not backward compatible? All ZCML browser directives by default register everything for IDefaultBrowserLayer and expect those resources to be available on normal browser requests. The test helpers in zope.app.testing to get browser resources set up rely on the same mix of concerns. This stuff is used all over the place without caring about loading zope.publisher's ZCML right now. Did my refactoring break anything? If so what? All I did here was to move two constructs from ZCML into direct code. The lines I added do exactly the same as the default adapter registered as: Uhh, this is call hard coded and makes it impossible to exclude the adapter with the exclude directive. I call that retaining sensible defaults. You can opt-out of the IDefaultBrowserLayer for browser requests by providing your own specialized adapter. I prefer no configuration for the most common case with an opt-out scenario instead of the everything is opt-in behavior. Do you understand the impact of your changes? I see what you are trying to do but I don't know which package or application you are trying to fix with your changes. Can you give me some hints about what you are trying to fix with your changes? I see two things which are bad. Skinnable depends now on IBrowserRequest. I moved the skinnable concept out of the browser request part. This allows us to separate the skinnable and all different request types into own packages if we do future refactoring. zope.publisher is the package that defines the IBrowserRequest interface. It might make sense to split those concerns off into different packages and then straighten out the dependencies. At that point I can see having a setDefaultSkin method inside zope.skinnable with a different behavior. But the one inside zope.publisher ought to play nicely with IBrowserRequest. Any improvements are very welcome. Do you think we should move the skinnable concept into zope.skinnable? Sorry if I'm bother you about this details but I spent a full day with this refactoring and one of my apps depends on this deault browser layer less concept. You just reverted the hole refactoring with 3 lines of code. Regards Roger Ineichen Hanno ___ 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 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] zc.buildout broken
Hi all, thanks for the Feedback Here is a pastebin link. Posting to a mailinglist is defently to bad for this 4572 lines of traceback ;-) http://pastebin.com/f1adc7a43 I think there are different things wrong. The first error looks like a difference in linux and windows output: -- File d:\eggdev\source\zc\zc.buildout\trunk\src\zc\buildout\buildout.txt, line 55, in buildout.txt Failed example: ls(sample_buildout, 'eggs') Expected: setuptools.egg - zc.buildout.egg Got: - setuptools.egg-link - zc.buildout.egg Other errors look like a path encoding problem because there is no difference if I compare: -- File d:\eggdev\source\zc\zc.buildout\trunk\src\zc\buildout\buildout.txt, line 287, in buildout.txt Failed example: print system(buildout), Expected: Develop: '/sample-buildout/recipes' Installing data-dir. data-dir: Creating directory mystuff Got: Develop: '/sample-buildout/recipes' Installing data-dir. data-dir: Creating directory mystuff Regards Roger Ineichen _ END OF MESSAGE -Ursprüngliche Nachricht- Von: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] Im Auftrag von Balazs Ree Gesendet: Freitag, 24. April 2009 13:39 An: zope-dev@zope.org Betreff: Re: [Zope-dev] zc.buildout broken On Fri, 24 Apr 2009 13:10:30 +0200, Marius Gedminas wrote: On Fri, Apr 24, 2009 at 05:56:45AM +0200, Roger Ineichen wrote: Hi everybody Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? It is always interesting to see the failures, but attaching large log files to emails is not very polite. True for large files, but a traceback is not that large _imo_. Depends on your connection of course. Also, we are on a development list, so if somewhere, then here tracebacks are on topic. Solution: use a pastebin. I disagree: pastebin is good for linking from irc, but when I come back to the archive I would like to see the details even when the pastebin entry is gone. -- Balazs Ree ___ 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 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] zc.buildout broken
Hi Sebastian Betreff: Re: [Zope-dev] zc.buildout broken On Fri, Apr 24, 2009 at 05:56, Roger Ineichen d...@projekt01.ch wrote: Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? Do you want a buildbot for zc.buildout? (py2.4, py2.5, py2.6 on linux 3264, sorry) Yeah, whould be great! Regards Roger Ineichen -- Sebastien Douche sdou...@gmail.com ___ 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] zc.buildout broken
Hi everybody Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? Regards Roger Ineichen _ END OF MESSAGE ___ 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] zc.buildout broken
Hi Tres Betreff: Re: [Zope-dev] zc.buildout broken -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: Hi everybody Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? Work on my Linux box (Ubuntu 8.10, w/ Python 2.5): - -- % --- $ svn co $ZSVN/zc.buildout/trunk zc.buildout-trunk Uzc.buildout-trunk/CHANGES.txt Uzc.buildout-trunk/setup.py Uzc.buildout-trunk/zc.recipe.egg_/CHANGES.txt Uzc.buildout-trunk/zc.recipe.egg_/setup.py Uzc.buildout-trunk/zc.recipe.egg_/src/zc/recipe/egg/egg.py Uzc.buildout-trunk/zc.recipe.egg_/src/zc/recipe/egg/README.txt Uzc.buildout-trunk/dev.py Uzc.buildout-trunk/src/zc/buildout/testing.py Uzc.buildout-trunk/src/zc/buildout/buildout.txt Uzc.buildout-trunk/src/zc/buildout/easy_install.txt Uzc.buildout-trunk/src/zc/buildout/easy_install.py Checked out revision 99446. $ cd zc.buildout-trunk/ $ ls bin buildout.cfg dev.py doc.txt README.txt src bootstrap CHANGES.txt disteggs setup.py todo.txt builddevelop-eggs doc partsspecifications zc.recipe.egg_ $ /path/to/virtualenv-2.5 --no-site-packages /tmp/zcb ... $ /tmp/zcb/bin/python bootstrap/bootstrap.py ... $ bin/buildout ... $ bin/test ... Ran 373 tests with 0 failures and 0 errors in 2 minutes 58.273 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. - -- % --- Thanks a lot. I'll take another look at what happens on windows. Regards Roger Ineichen Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ8Tv/+gerLs4ltQ4RAq7wAKCriyQU/yX5vFd5xP7PKeAJ6ecVFwCglxVL nuuvOIhUi8fFDX6b63B/+6c= =QEqP -END PGP SIGNATURE- ___ 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 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] People in the Zope 3 and ZMI teams
Hi Martijn Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams Hey, Roger Ineichen wrote: I think there is a little confusion about which package depends on each other. Right now there is a zmi.core package this package should contain core parts without to much dependency. After that we need several zmi.* packages which are replacements for each zope.app.* package. right? Right. Note that I'm against making too many zmi.* packages right now, keep it all in a few packages now. Concerning dependencies, let's first talk about zope.container: zmi should depend on zope.container zope.app.container.browser should have backwards compatibility imports from zmi, and zope.app.container should depend on zmi Now let's talk about a package that *hasn't* been factored away from zope.app.* yet, such as zope.app.file: in this case, zmi would depend on zope.app.file but zope.app.file.browser would depend on zmi. That's a circular dependency, which we should break as soon as possible by moving zope.app.file's content objects to zope.file or something like that. Agreed, we should at the same time split the packages like we did with others. I think it should be like: 1. zope.app.foo moves ZMI code to zmi.foo 2. zope.app.foo imports the zmi code from it's zmi.foo package Agreed. This allows us to move the zmi code from the zope.app packages to zmi packages. Custom projects can then depend on zmi.foo and skip the dependency to zope.app.foo. (at least for the zmi) probably some zope.app.* packages contain only zmi code probably some contain other code like Martijn told with zope.app.form. That's fine and is not a part of our refactoring. Projects which depend on zope.app.foo and will use the latest code will get pulled in the zmi.foo package without any other dependecy and should just work without to change the project setup since the zope.app.foo package defines the zmi.foo dependency in thier setup.py file. Agreed. btw, I think we should refactor the old menu implementaiton too ar at least review it since this part is very, very slow. But that's another part and could probably done after finishing the zmi refactoring part. Agreed; do it after the zmi refactoring. Thanks Roger for the coordination. I think we all agree on where we need to go, which is good. Yes, sounds good to me too Yusei, I'm out of the office till next monday. but I can answer mails if you have questions. Regards Roger Ineichen Regards, Martijn ___ 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 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] People in the Zope 3 and ZMI teams
Hi Martijn, Yusei I think there is a little confusion about which package depends on each other. Right now there is a zmi.core package this package should contain core parts without to much dependency. After that we need several zmi.* packages which are replacements for each zope.app.* package. right? I think it should be like: 1. zope.app.foo moves ZMI code to zmi.foo 2. zope.app.foo imports the zmi code from it's zmi.foo package This allows us to move the zmi code from the zope.app packages to zmi packages. Custom projects can then depend on zmi.foo and skip the dependency to zope.app.foo. (at least for the zmi) probably some zope.app.* packages contain only zmi code probably some contain other code like Martijn told with zope.app.form. That's fine and is not a part of our refactoring. Projects which depend on zope.app.foo and will use the latest code will get pulled in the zmi.foo package without any other dependecy and should just work without to change the project setup since the zope.app.foo package defines the zmi.foo dependency in thier setup.py file. btw, I think we should refactor the old menu implementaiton too ar at least review it since this part is very, very slow. But that's another part and could probably done after finishing the zmi refactoring part. Regards Roger Ineichen Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams Yusei TAHARA wrote: [snip] Should the old zope.app.* package depend on the new zmi.core package? (I think not) No. But zmi.core might depend on zope.app.* packages. I think this should be avoided if we can. The idea is to lose the dependency of the zope.app.* packages for the ZMI, after all. Of course there are exceptions: if you rely on a zope.app.* package that hasn't really been moved to zope.* yet (zope.app.form.browser for instance). But relying on zope.app.*.browser should be avoided in most cases, otherwise we create circular dependencies. Or should we break BBB and let people know that they have to install zmi.core for zmi support? (I think so) I won't break BBB as much as possible, at least I'd like to keep persistent data compatibility... But the ZMI is all views, right? What is persistent? For BBB, you want the zope.app.*.browser packages to import from zmi.core, not the other way around. Otherwise we don't clean up dependencies at all. [snip] - bump up the zope.app.* package version (full not partial) e.g. 3.5.1 to 3.6.0 Hmm, I'm not sure yet... I think this should be done; if you update a zope.app.* package to import its ZMI stuff from zmi.* a new release of the zope.app.* package should eventually be made, and it should have a new feature release (so increase y in x.y.z). [snip] For now, I don't have clear image yet. I'm checking all zope.app.* packages and make sure all tests pass. And maybe I will review current package dependencies. For that, you might want to investigate the z3c.recipe.depgraph recipe to generate dependency graphs. To try it against trunks you need to add them to 'develop' in your buildout.cfg After that, I will copy zmi parts to zmi.core one by one. I'm sorry but I'm very slow for some reasons, I cannot make an exact schedule yet. I don't think you're slow at all. Your plan sounds good and I'm glad you have Roger giving you feedback. Regards, Martijn ___ 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 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] Best way to invoke paster/WSGI apps on cmdline
be flat files but generated ones).
- If you'd like people that know things like paster to pick up our
environment easily, I think, that: make it obvious where the
deploy.ini Co went and as they are generated files,
leave a visible
note at the beginning of the file, that states something like:
# NOTE: This file is generated by foo.recipe.paster, it will be
# overwritten. Please apply changes to your buildout configuration
# (located in XXX) instead of changing this file.
Yep. Thanks for all the input!
[snip: zopeproject and referencing 'instances']
If I try to conclude, then I see several decisions to make:
* paster serve ... vs. commandname approach.
It looks like that the commandname approach makes more sense with
Zope as we certainly want to use the power of buildout and therefore
have to use generated config files in 'exotic' (seen from the casual
paster user's point of view) places.
* commandname-dbg vs. commandname --debug
I'll implement this concept in a next z3c.recipe.paster release.
The idea behind the z3c.recipe.paster is to define several
instances for what you need to have.
This will also prevents to start a Zope instance in a debug mode
if no debug option is defined. I'm not sure if this is the right
ting for everyone, but I like to be restrictive on production systems.
This means, we have to decide, whether we want several commands
performing special tasks (most probably: running everything in a
special 'mode'), or one command that accepts options to indicate
that special behaviour expected.
* conffile.in vs. buildout.cfg-embedded config files
I personally would really prefer the first approach for ease of use.
If, however, this leads to problems with parsing the files, we are
more or less bound to the latter. I'd like to investigate that
further.
It looks like that the 'commandname-w/o-configfile-param'
approach suits buildout-based environments best, which might
be a good reason to be different in that respect from other
paster-frameworks.
From my initial list of invokes (enriched by Hanno's Plone4
approach) then only some remain:
- instance-fg options and friends
- mycommand [start|stop|status...] options
The latter is partly already implemented by
z3c.recipe.paster. Currently it does not support external
config files and might do a bit more than needed (for example
it calls ZConfig parser in schemaless mode, but there
certainly is a good reason for it; in grokprojects we let
zope.app.wsgi do this stuff), but it took me less than half
an hour to create a flatter version that accepts both:
internal and external config files (where external zope.confs
are parsed with schemata) so that one can start a paster
served grokproject with generated configuration files in
parts/etc by doing::
$ bin/myapp
in foreground, where the script name is built from the
buildout.cfg section name. It is actually a wrapper that runs::
paster serve buildout-set-ini-file [cmdline-options]
This means also, you have to do::
$ bin/myapp --daemon
to start the server in background (which is bad if you prefer
SYSV compatible behaviour, i.e. ``bin/myapp start`` here),
but you can do::
$ bin/myapp status
$ bin/myapp stop
I already have a zdaemon recipe which allows to
use a zdaemon starting a paster setup. This looks
like:
[xpo]
recipe = p01.recipe.zdaemon
deployment = deploy
program = ${buildout:directory}/bin/app
zdaemon.conf =
runner
program ${buildout:directory}/bin/app
daemon on
socket-name /var/run/zdaemon/xpo.sock
transcript /var/log/zdaemon/xpo.log
# Enable this to run the child process as a different user
user zope
/runner
eventlog
logfile
path /var/log/zdaemon/xpo.log
/logfile
/eventlog
This allows to point to a paster app which was setup
with a z3c.recipe.paster. and is using a deploy buildout
like:
[deploy]
recipe = zc.recipe.deployment
name = zdaemon
etc-directory = /etc/zdaemon
log-directory = /var/log/zdaemon
run-directory = /var/run/zdaemon
logrotate-directory = /etc/logrotate.d
crontab-directory = /etc/cron.d
rc-directory = /etc/init.d
user = zope
Let me know if you are interested and like
to move that to the zope repos.
Regards
Roger Ineichen
which does, what one expects.
One can also pass the usual paster options like ``--reload``.
There is, however, no possibility to start in debug mode,
i.e. with a debug.ini as argument, except you declare another
command (at least I don't see any way to do it different).
It should also be possible to make use of z.r.paster in
Plone4, as one can easily generate an ``instance-fg`` script
this way. I wonder, however, whether this is still wanted with paster.
Hm, all this is confusing (and much too long). Maybe someone
nevertheless has an opinion?
Best regards,
--
Uli
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams Hi, I just start working on maintaining ZMI and make it optional package. For now, it is easy to participate, just porting zope.app.* (I already list up targets as directories in zmi.core) and make sure that existing tests succeeds. Can you tell a little bit about what you mean with tests succeed? Should the test in the existing package succeed? But this whould mean that the old packages we move the zmi parts from needs to depend on the new zmi.core package. Should the old zope.app.* package depend on the new zmi.core package? (I think not) Or should we break BBB and let people know that they have to install zmi.core for zmi support? (I think so) If so, then the test should succeed in the new zmi.core packages, right? Can you write down some comment how we sould do the refactoring like: - move the zmi part from a zope.app.* package to the new zmi.core.* package. - make sure the test pass in both packages. The zmi test should all get moved to the new zmi.core.* package Probably enhance the tests since the zmi part was not very well tested. - release the zmi.core package after each package move or at least before the zope.app.* package get released - bump up the zope.app.* package version (full not partial) e.g. 3.5.1 to 3.6.0 Not sure if the above is correct. Please change if not. It is at least only correct if we break BBB and move the zmi completly out of all zope.app packages to zmi.core. And probably we should also implement a testing layer setup which all test in zmi.core can share/use. Regards Roger Ineichen _ END OF MESSAGE Best regards, -- Yusei TAHARA yu...@domen.cx ___ 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 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] z3c.javascript license question
Hi Tres Betreff: Re: [Zope-dev] z3c.javascript license question -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, On svn.zope.org we have a library called z3c.javascript. Never got released to pypi, but it did get released to download.zope.org/distribution It basically contains a pile of javascript libraries. These have very non-ZPL licenses. I wonder whether anyone at zope corporation ever got permission for checking these in? What shall we do with this stuff? I'm tempted to remove it wholesale, except z3c.widget uses bits in it, and that in turn is used by megrok.form, which is how all this came to light. z3c.widget is released on pypi (though newer releases exist in download.zope.org/distribution again). Wwe will probably be able to rewrite megrok.form to lose the z3c.widget dependency easily enough, so I'm going to propose we do this on grok-dev. I see no ZC-employee checkins at all in the svn log, which starts in May 2006. This thread from October 2006 points out licensing issues: http://news.gmane.org/find-root.php?group=gmane.comp.web.zope. zope3article=19324 +1 to removal, perhaps after some kind of svn export process.: those who maintain the package should host it elsewhere. The tarballs should be removed from download.zope.org, as well. I remember that I added a correct license header some years ago for z3c.javascript. This code was at least some years ago used by the lovely systems guys. Not sure this days. Regards Roger Ineichen ___ 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] who wants to maintain Zope 3?
Hi Martijn
-Ursprüngliche Nachricht-
Von: zope-dev-boun...@zope.org
[mailto:zope-dev-boun...@zope.org] Im Auftrag von Martijn Faassen
Gesendet: Dienstag, 14. April 2009 17:54
An: zope-dev@zope.org
Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Hey,
Baiju M wrote:
[snip]
Does Zope Tookit support building a web application out of the box
without relying on Grok, Zope 2 or any other framework ?
(I am Ok to use a Buildout for building application from
Zope Toolkit
packages)
This is a very good question. My answer is no, it doesn't.
It might support tools to help construct such out of the
box experiences, but it won't be something you can install
and just get started with unless you really want to roll your
own framework.
If the answer to this question is No, then I am interested to
maintain the packages necessary to create a simple
application out of the box.
This is just an academic interest :)
Great!
We should definitely have Zope 2 and Plone and Grok and Zope
3 work together and share experience. I have the feeling each
project is working isolated from each other now, and with
Grok we're moving to paste and I just have the feeling we're
inventing some of our own wheels that could be shared, or
alternatively that we shouldn't be doing that way. Currently
for instance we generate debug.ini and such and put them in
parts as they have hardcoded path names. That can't be right...
Take a look at the z3c.recipe.paster:serve recipe
You can define your WSGI app in a buildout.cfg file like:
[app]
recipe = z3c.recipe.paster:serve
eggs = MYPYPI
ini =
[filter-app:main]
use = egg:Paste#translogger
next = zope
[app:zope]
use = egg:MYPYPI
fsStorage = ${buildout:directory}/parts/fsstorage
tmpStorage = ${buildout:directory}/parts/tmpstorage
[server:main]
use = egg:Paste#http
host = localhost
port = 8080
zope.conf =
${var:zconfig}
devmode on
eventlog
logfile
formatter zope.exceptions.log.Formatter
path ${buildout:directory}/parts/logs/error.log
/logfile
logfile
formatter zope.exceptions.log.Formatter
path STDOUT
/logfile
/eventlog
site.zcml =
configure
xmlns=http://namespaces.zope.org/zope;
xmlns:meta=http://namespaces.zope.org/meta;
meta:provides feature=devmode /
include package=mypypi file=app.zcml /
/configure
after run buildout you can call
bin/app
Regards
Roger Ineichen
_
END OF MESSAGE
Regards,
Martijn
___
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 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] who wants to maintain Zope 3?
Hi Martijn Betreff: Re: [Zope-dev] who wants to maintain Zope 3? Hey, Jim Fulton wrote: I don't think these bits are cleanly separated. For example, if a content component has some views, are those ZMI bits? Yes. zope.container doesn't define views. zope.app.container did (and does). browser directories are generally not part of the Zope Toolkit, though there are some exceptions (zope.app.publisher.browser, zope.app.form.browser). Can you identify projects that are in or out of the toolkit? What about zope.publisher? zope.security? zope.app.publication? Currently all three are in. zope.publisher + zope.app.publication might not remain in permanently if a better way of doing things evolves, but that's up in the air right now. [snip] I agree with the idea of simply supporting a library of components. I'm uncomfortable with the idea of saying you're going to shrink the codebase without saying what's going. The ZMI is the bit that is going right now. Since we're factoring non-ZMI bits out of zope.app.*, eventually that'll mean a whole range of zope.app.* packages will not be maintained by the Zope Toolkit developers. The other bits are up for discussion. We don't intend to stop people from maintaining other packages outside the toolkit. I don't want to see a separate Zope 3 project distinct from the Zope Toolkit. I do want to see the components we're using live within a project. If the Zope Toolkit doesn't include components in common use, then I don't think it has a lot of value. I'm not in the business of maintaining Zope 3 myself; I mainly care about how Grok uses it, and how I can integrate libraries in the ecosystem into my apps. The Zope Toolkit includes components in common use by Grok, Zope 2, and Zope 3. The Zope 3 project always attempted to be far more than just being a bunch of libraries. It attempted to be a system you can install and find documentation for and start developing with. When you install it, you see a user interface. It had a group of people who cared about it that you could talk to. There are a lot of concepts associated with Zope 3. What I'm trying to do is to separate these concepts, which is why we're going through some confusion. The Zope Toolkit is something that doesn't have an installation story for the whole. It does have some documentation about the whole: how it is developed primarily. But instead of having documentation for the whole (Build your app with the Zope Toolkit, here's how to get started! is not going to be there), it will focus on documentation about how to use the individual libraries. It leaves how to use it as an integrated whole to other projects. The Zope Toolkit has implementations of content objects such as the container. It doesn't have a user interface; it just has a way to construct user interfaces. The Zope Toolkit is there to serve the people who use it. That's people who use a large range of these libraries, or just some of them, and projects that build on top of these libraries. The question at hand is whether people care about a project that presents itself as a whole, uses a lot of the Zope Toolkit, and has an installation story (and possibly a user interface), and that isn't Grok or Zope 2, but like Zope 3. If so, we could have a Zope 3 project that cares about those things (naming discussion aside). Yes, absolutly. I will help to support such a Zope Toolkit management app which will allow to get rid of the zmi part. Regards Roger Ineichen Regards, Martijn ___ 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 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] who wants to maintain Zope 3?
Hi Martin -Ursprüngliche Nachricht- Von: zope-dev-bounces+dev=projekt01...@zope.org [mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im Auftrag von Martin Aspeli Gesendet: Montag, 13. April 2009 13:07 An: zope-dev@zope.org Betreff: Re: [Zope-dev] who wants to maintain Zope 3? Hermann Himmelbauer wrote: -1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain. FWIW, I think you're absolutely right. We can't just declare it dead because it is convenient to our goal of having clearer definitions about what we're working with. A piece of open source software is dead if no-one uses it and no-one maintains it. At least then, existing users can't count on bug fixers or security fixes. I think Martijn's point in starting this thread was to try to identify who wants to maintain Zope 3 as an app server and as something that gets released going forward. Let's give those people a chance to respond. Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly. This sounds much better then the earlier mails ;-) I'm willing to help to find a way to move the old code parts to a newer and better concept. Note, I don't use this code in my own projects and I don't propose to do that just for fun. But if someone proposes to do it, I'm willing to help. I think we have to support a smooth migration path for the old ZMI views and we can't just skip them. Releasing a Zope 3 app server is another part. I'm not sure if Stephan Richter, he told once, will support it for the future? I still think the Grok, Repoze, Plone, Zope 2 and Zope 3 developer should talk together and find a concept and see how we can find a code base which will fit for each other. This probably only means that we move the zmi part out of the existing zope.* and z3c.* packages. And each project could offer a own management concept and views for the same code base. Regards Roger Ineichen Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 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] who wants to maintain Zope 3?
Hi Martijn Betreff: [Zope-dev] who wants to maintain Zope 3? Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? Of corse do we all need the UI part for manage the components we install. But the old style ZMI views are obsolate this days. Right now we have to write this part for each project by ourself if they need to depend on z3c.form and z3c.pagelet. * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) Yes, I don't use it but I think we should have something available as a starting point for newcomers. This could be something like zopeproject or a minimalistic setup with as less as possible zope.*, z3c.* and repoze packages. * the thing that has some kind of documentation website - do you care about providing documentation for Zope 3 as opposed to documentation for Grok or individual libraries? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. I think we should take a look if we can build a minimal setup which Plone, Grok and other projects can use. Do you think there could be such a based configuration? Or is there to much difference in each of Plone, Grok, repoze etc? If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. The question is, can we find browser page pattern which Grok, Plone, repoze and others can use? Everybody needs to have at least management views for manage the components they install in some ways. So the question is not if we skip the ZMI or not. I think the question is can we improve and share such views in the different projects or do we have to develop views for each of them? Regards Roger Ineichen ___ 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] WSGI access log user info howto?
Hi Alex Betreff: Re: WSGI access log user info howto? A branch containing this refactoring named 'achapman__username_logging now exists in the zope.app.wsgi directory. I'll be merging it today and tagging a release if it appears acceptable. This looks good to me. Can you add a test for the new logging part? Or let me know if I can do it for you. Regards Roger Ineichen - Alex Chapman On Tue, Mar 31, 2009 at 10:00 PM, Alex Chapman achap...@gmail.com wrote: This would work great for my own needs if its acceptable with everyone else. Thanks for the help on this. In the future I'll do work on a branch and request a review from all those on the owner list before merging, tagging, and releasing. -Alex Chapman On Wed, 2009-04-01 at 03:30 +0200, Roger Ineichen wrote: Hi all Shane, any idea about the following which whould also affect the zope.pipeline or the zope.publisher refactoring? I need some advice for the access log topic in wsgi. The zope http server logs access in zope.publisher.http like: def setPrincipal(self, principal): 'See IPublicationRequest' super(HTTPRequest, self).setPrincipal(principal) logging_info = ILoggingInfo(principal, None) if logging_info is None: message = '-' else: message = logging_info.getLogMessage() self.response.authUser = message This means there is a ILoggingInfo adapter which returns a simple string. ASCII and no space are preffered because the standard access log format uses space aas delimiter. And access lgo fiels are not unicode. Of corse the ILoggingInfo adapter is responsible for choose the right format for each project. A default is configured in zope.publisher.principallogging PrincipalLogging Now to the question. In the latest checkins there was a access log part implemented. It doesn't use the ILoggingInfo adapter and is exposing the user login which is a part of the security credential. This get already released. (not good) Is there a standard how WSGI apps will log user info in access logs? I guess not, right? Does someone have a good idea how we should implement user access info for access logs in zope.app.wasg? If not, I propose the following: logging_info = ILoggingInfo(request.principal, None) if logging_info is None: message = '-' else: message = logging_info.getLogMessage() environ['wsgi.logging_info'] = message - this will set a ``wsgi.logging_info`` environ variable (or is there already a standard name)? - it uses the ILoggingInfo adapter which let us use different kind of access log info strategies in custom projects. By default we should use the PrincipalLogging adapter form zope.publisher.principallogging. Does anybody have a better idea how we can make the user info available for the access log? Alex whould this fit for you? Regards Roger Ineichen _ END OF MESSAGE ___ 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] z3c.pt bug
Hi Malthe I just improved coverage in z3c.form and found a bug in z3c.pt. Can you run the group.txt tests in z3c.form and confirm the issue. A div tag get skipped after some nested repeat tags. (line 898, in group.txt) Is this a known issue? Can you fix this or give me some hints which let me do this? Regards Roger Ineichen _ END OF MESSAGE ___ 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] WSGI access log user info howto?
Hi all Shane, any idea about the following which whould also affect the zope.pipeline or the zope.publisher refactoring? I need some advice for the access log topic in wsgi. The zope http server logs access in zope.publisher.http like: def setPrincipal(self, principal): 'See IPublicationRequest' super(HTTPRequest, self).setPrincipal(principal) logging_info = ILoggingInfo(principal, None) if logging_info is None: message = '-' else: message = logging_info.getLogMessage() self.response.authUser = message This means there is a ILoggingInfo adapter which returns a simple string. ASCII and no space are preffered because the standard access log format uses space aas delimiter. And access lgo fiels are not unicode. Of corse the ILoggingInfo adapter is responsible for choose the right format for each project. A default is configured in zope.publisher.principallogging PrincipalLogging Now to the question. In the latest checkins there was a access log part implemented. It doesn't use the ILoggingInfo adapter and is exposing the user login which is a part of the security credential. This get already released. (not good) Is there a standard how WSGI apps will log user info in access logs? I guess not, right? Does someone have a good idea how we should implement user access info for access logs in zope.app.wasg? If not, I propose the following: logging_info = ILoggingInfo(request.principal, None) if logging_info is None: message = '-' else: message = logging_info.getLogMessage() environ['wsgi.logging_info'] = message - this will set a ``wsgi.logging_info`` environ variable (or is there already a standard name)? - it uses the ILoggingInfo adapter which let us use different kind of access log info strategies in custom projects. By default we should use the PrincipalLogging adapter form zope.publisher.principallogging. Does anybody have a better idea how we can make the user info available for the access log? Alex whould this fit for you? Regards Roger Ineichen _ END OF MESSAGE ___ 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] Please use launchpad bugtracking/blueprints more
Hi Christian Betreff: [Zope-dev] Please use launchpad bugtracking/blueprints more Hi, so, we've been running with the steering group for a few weeks now and I'm losing track of things, because we're letting the mailing list do the job of an issue tracking system. (And the one document in SVN.) [...] I can't follow every single email on zope-dev and having to review large threads that were solved already isn't good use of anybodies time. Agreed, Can we use a marker in the header for official steering group mails like this one? Something like [Zope-dev][Announcment]. This let us easier pick up the important mails. Regards Roger Ineichen ___ 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
Hi Wichert Betreff: Re: [Zope-dev] setting missing minimum version in setup.py Previously Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote: This is an important point. As I see it the KGS is a Zope-only thing, and is just a workaround for the mindless behaviour of setuptools. I do not see it gaining acceptance outside of the Zope community, and imho effort is better spent on improving the packaging tools. Are there other Python projects that have to deal with such a huge amount of packages and dependencies? I don't know any similar project. So the solution must come from the Zope world (which does not mean that we participate in the packaging toolchain development as Tarek does). I don't know. I just feel quite strongly that improving the packaging tools would be a better use of manpower than working on the KGS in its current form. Stephan imlemented the KGS because there where a couple of limitations which we run into. I think the best you can do is to find out what they issues are which the KGS solves. After that you are very welcome to show us a better way to solve the same issues at a package lavel. Probably a way to go is to make both concept compatible with each other. Which probably means we should be able to ignore versions in packages if a KGS concept get used? (not sure if this is possible) Regards Roger Ineichen Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 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] ZPT attributes and
Hi Malthe Betreff: [Zope-dev] ZPT attributes and Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, , object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``. I think this is better then render empty strings. see below... How do folks feel about changing this behavior in ``zope.pagetemplate``. Probably anything else then should be skipped. There is no logic why object() or False should get rendered as . I only whould expect that an empty string whould get rendered as . And probably we should check the HTML specification and make sure that we only render empty strings for attributes where they are allowed. see: http://www.w3.org/TR/html401/types.html#type-name ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (-), underscores (_), colons (:), and periods (.). This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not? Regards Roger Ineichen \malthe ___ 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 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] ZPT attributes and
Hi Tres
Betreff: Re: [Zope-dev] ZPT attributes and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and
Currently, if an attribute expression evaluates to any
value that's
boolean False, it's omitted (e.g. 0, , object()). I think that's
unexpected. Instead, attributes should only be omitted when the
expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in
``zope.pagetemplate``.
Probably anything else then should be skipped. There is no logic
why object() or False should get rendered as .
Non-true values have special semantics for certain attributes
('checked', 'selected', I think).
Good point
I only whould expect that an empty string whould get
rendered as .
And probably we should check the HTML specification and
make sure that
we only render empty strings for attributes where they are allowed.
see:
http://www.w3.org/TR/html401/types.html#type-name
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens (-),
underscores (_), colons (:), and periods (.).
This means to me that an empty value for id or name doen't
start with
[A-Za-z] and is invalid because is must start with [A-Za-z]. or not?
- -1 on making ZPT / chameleon responsible for enforcing that
requirement:
that would be the application's job.
Hm, that's a good point too. I see what you are thinking.
My motivation is, it is valid to skip attributes with empty
values for an element in an XML document. (not sure)
If this is true, then there is no reason why a default empty
values should get rendered.
As far as I know it is valid to skip attributes for empty values
but for some attributes it is not valid to use empty values.
And the bad thing, some attributes need empty values like
you suggested with checked= etc, oh my ;-)
Regards
Roger Ineichen
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC
LfHPVXRoCkejJLyCvLjdvyU=
=ClnO
-END PGP SIGNATURE-
___
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 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] XML-RPC does not work under the paster process
Hi Michael Betreff: Re: [Zope-dev] XML-RPC does not work under the paster process -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: When using paste.httpserver instead of twisted.wsgi server zope.publisher.xmlrpc.XMLRPCRequest.processInputs() hangs when reading 0 Bytes from the request (wsgi.input socket._fileobject object). As i found the zope.publisher.http.HTTPInputStream.readlines() signature was changed 3 years ago from readlines(self, hint=None) to readlines(self, hint=0) http://svn.zope.org/Zope3/trunk/src/zope/publisher/http.py?rev=66941r 1=66940r2=66941 Do you think we could revert the change? Bugs reported: zopeproject: https://bugs.launchpad.net/zope3/+bug/283089 grokproject: https://bugs.launchpad.net/grok/+bug/332063 Bump - maybe my description was too complicated, but the issue is serious: XMLRPC is broken at least with paste.httpserver Any input on the implications of reverting the change in revision #66941? We should also add a good test case where we can see what happens. Regards Roger Ineichen Regards Michael - -- http://blog.d2m.at http://planetzope.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwOU0l0uAvQJUKVYRAnILAKCOSnA3YfUXilqoTD74/ukemGPkyACgil0O 1F0ZmR11vhodC33S6Wcg0z0= =JX17 -END PGP SIGNATURE- ___ 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 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
Hi Wichert, Steering Group? Betreff: Re: [Zope-dev] setting missing minimum version in setup.py Previously Martijn Faassen wrote: Wichert Akkerman wrote: [snip] I see no useful different between x.y and x.y.z here. All I want is if someone installs one of our packages that package will work as expected. If a package will only work with a certain revisions of a dependent package it has to state say. I do see a useful difference between the two. x.y is a feature release that might have changed the API or behavior. If you rely on this in a version of your package, you will have to indicate that this is so. x.y.z is a bugfix release. If we do it right, there will be no change in the API and only small changes in misbehavior. Therefore it seems far less likely to me that a package ends *needing* to depend on a minimum version. In addition, porting back bugfix releases is far harder. If version x.y of package A adds a new feature which requires a feature in package B, but was broken in B until version d.e.f of that package, I would expect version x.y of package A to have a dependency on version d.e.f of package B. Do you agree with that? What do you do if version x.y works with d.e.d but not with d.e.e (because it's borken) and fixed in d.e.f. This means you could use d.e.d or d.e.f. but not d.e.e What's your solution then? Fix the version to d.e.d or d.e.f or skip fixing versions? This is a use case where fixing versions in packages doesn't work and the KGS only can help. You can have different KGS version indexes. One with d.e.d and one with d.e.f. This is the benefit of the KGS. You can define whatever you like an nobody is able to block packages which you need to use. Note; Not that fixing versions in a package is a bad thing in general. But such fixed versions will mess up the KGS that's the bad part. And since the KGS solves any kind of version conflict problems, there is no way to do it in a package anymore. I think you are suggesting that we should be able to use all package without a KGS. If so,you are right, then we need fixed versions. But if we decide to use KGS as our primary pattern, then we do not need to mess up with versions in packages. Steering group? Do we support a release management at package level or do we only guarantee a working release/version management based on KGS? Regards Roger Ineichen Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 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
Hi Betreff: Re: [Zope-dev] setting missing minimum version in setup.py On Monday 16 March 2009, Martijn Faassen wrote: I'm not sure I agree you here, Stephan. A possible disagreement within the steering group, how interesting! :) :-) The most widely open requirement is this: zope.foo but another open requirement is this: zope.foo = 1.3 Sure, but here is what happened before. Person A made a bugfix to zope.foo 1.3, releasing zope.foo 1.3.1. He then said, ok, zope.bar 1.0.0 depends on zope.foo = 1.3.1. Person B backports the bug fix to zope.foo 1.2.1. Now zope.bar would also work with 1.2.1, but can't because of the version specification. So person B has the choice of upgrading to zope.foo 1.3.x or release a new version of zope.bar. Updgrading to zope.foo 1.3.x might not be easy for various reasons that I think most of us experienced (I know I did). Releasing a new zope.bar version might not be possible, if person B does not have access. Also expecting person B to create new releases for all packages where the bug fix would work is unrealistic. I also don't recall open requirements bringing development to a halt? They did. :-) You bring up the case of backporting a fix (a relatively rare occurrence, but it certainly happens): Not so rare at all, I think. Even if it's rare, why should we not support that? The consequence of fixing versions is to skip backporting. There is no way to have both. Are you really sure we like to skip backporting. Regards Roger Ineichen ___ 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: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
Hi Michael Betreff: Re: AW: [Checkins] SVN: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``. Am 15.03.2009 um 23:47 schrieb Roger Ineichen: Hi Michael Can you explain why you implemented the login viewlets? The login in zope.app.security is implemented using browser pages and metal-macros and is not really customizable. I needed a login/logout which works fine with pagelets and behaves like the one in zope.app.security as I think zope.app.security was not implemented so badly. What does this viewlets have to do with the pagelet layer? It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. Yes and No. It's of corse usefull to have predefined login views available. But I use a z3c.form based implementation for this. Which means I don't need them. Everything else in z3c.layer.pagelet is needed by everyone. Otherwise the pagelet pattern doesn't work. This let me think that everything which is not needed by default in z3c.layer.pagelet should go to another package because it's only optional. Then z3c.layer.pagelet is only a base implmentation for make pagelet working and is used in other packages as mixin. I think they are very project specific and should go to an explicit package which offers login viewlets. I'm not sure about this, as the implementation as adopted from the one in zope.app.security. I don't think the one in zope.app.security is project specific. But I might be wrong. I think that's right. The pagelet layer has nothing to do with such explicit implementations. The z3c.layer.pagelet package offers only the minimum setup for make pagelets traversable and offers error handling etc. My implementation does not even require new dependencies. ``zope.authentication`` and ``zope.principalregistry`` where split out from zope.app.security to reduce dependencies. What do you think, can we move your viewlet part into another package which is based on z3c.layer.pagelet or probably on z3c.layer.ready2go which uses the pagelet layer too? It could be an idea to add it to z3c.layer.ready2go which currently only contains some interfaces. But a completely new package seems a bit overkill to me. Ok, sounds good to me. I'll take a closer look at that and let you know if I change something. Regards Roger Ineichen Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] [Zope3-checkins] [Checkins] SVN:zope.app.component/trunk/setup.py set missing minimum version
Hi Stephan, Wichert, Michael Betreff: Re: [Zope3-checkins] [Checkins] SVN:zope.app.component/trunk/setup.py set missing minimum version On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I backport the fix? We have done version specification like this in the Zope packages before and it almost brought development to complete halt, because versions would not match anymore. +1 If one of several packages doesn't get updated with buildout is only possible if someone uses an index server which only have one of the both released packages available. If this is not true, then this is a bug in buildout and buildout doesn't catch the package versions correct. Which I think is not the case. All other reason I can think about that someone only got one package and another not if two package get released depends on a bad package management. Fix versions are a pain because you can't be sure that someone uses a patched or branched package which you will fix the version for. Package management should never be done in a single package! Michael, can you explain what's happen that you didn't got the zope.publisher release? And was this problem solved after fixing the version or did you do something else too? Regards Roger Ineichen Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope3-Checkins mailing list zope3-check...@zope.org http://mail.zope.org/mailman/listinfo/zope3-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] Releasing z3c.recipe.i18n?
Hi Brian Betreff: [Zope-dev] Releasing z3c.recipe.i18n? Hi, I've added a oneline bugfix to z3c.recipe.i18n that's pretty important for me (97979). Thanks a lot! Could someone release it? or add me as an owner in pypi so I can do it myself? My pypi username is jinty. Just added you as Owner. Regards Roger Ineichen -- Brian Sutherland ___ 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 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.password
Hi Stephan Betreff: Re: [Zope-dev] zope.password On Tuesday 10 March 2009, Dan Korostelev wrote: Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use extras anymore, I think this calls for another package which depends on zope.password and zope.schema. I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's password.zcml file, include zope.password explicitly and define your own vocabulary. I think we have become dependency paranoid. And we embrace package proliferation instead, which in my opinion is equally bad. If you really hate the dependency, make it an extra requires. I know that goes against the latest guidelines as well...*sigh* My big problem here is that we dismiss all solutions but new packages. We want to minimize dependencies and not have extra includes. The only choice left is a separate package. We should, however try to make the number of packages a parameter too. This is exactly my reaction. It is allways bad to skip existing patterns without to have a better one. Note, there is always a reason for a pattern. We didn't just develop that for fun. I think the steering group should think about what are the consequence if we skip someting and how we can solve the problems which get solved based on patterns they like to skip. Right now it means, skip extra_requires forces us to add more new package and include them in the original package for BBB reason which will add back the same dependency like we tried to skip with extra_requires. But now as a hard depenency. ouch! Regards Roger Ineichen Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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.password
Hi Dan Betreff: Re: [Zope-dev] zope.password 2009/3/10 Roger Ineichen d...@projekt01.ch: Hi Steering group, Hanno, Dan Betreff: Re: [Zope-dev] zope.password Dan Korostelev wrote: 2009/3/10 Hanno Schlichting hanno...@hannosch.eu: Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use extras anymore, I think this calls for another package which depends on zope.password and zope.schema. I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's password.zcml file, include zope.password explicitly and define your own vocabulary. I don't quite like the idea of extras and we decided to avoid them. We also decided to avoid tests_require from what I understand. What you did was to not specify an extra nor a hard dependency, but still add zope.schema to the test extra section. That feels wrong. Either you have a dependency and so have the tests or you don't. I think extras have been created for this kind of use-case of providing an optional feature from a package. Either we use that mechanism and declare it, or we don't want this mechanism and live with creating extra packages instead. Hanno, Can you propose something else to solve our problem? The problem is, zope.password offers password manager which get used by zope.app.testing, zope.app.authentication, z3c.authenticator and other packages. zope.app.authentication configures the vocabulary for the password managers in zope.password. That's defently a no go. Write another package for just define and register them is I think also a no go. Probably we should depend zope.password on zope.schema too and configure the vocabulary and managers registry there. Dan, I think we should not be to excessive with the dependency cleanup and stop ourself. It would be nice to use zope.password without the zope.schema package but that's right now no use case for our refactoring. I'd like to be able to use zope.password without zope.component for some of my tiny old Pylons-based projects, that's why I'm trying to avoid dependency on it. I believe that repoze guys will also be quite happy, if it didn't pull unneeded (for them) dependency. I think that's a valid reason for your use case. But that's a problem for the zope framework ;-) I'd be fine with an extra requirement, but others seem to be against that. :-/ I think we don't have any replacement pattern for extra_requires. The extra_requires where developed for exactly that reason. We should use that pattern till someone will show us a better concept. I also think to add an additional package for register a vocabulary is very ugly. Probably we should think about zope.app.security or something like that and move the password managers and vocabulary to someting like that. Regards Roger Ineichen ___ 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] Proposal: refactoring of zope.app.security
Hi Dan Betreff: [Zope-dev] Proposal: refactoring of zope.app.security Hi people! One of most large packages that really wants to be refactored but still wasn't touched is zope.app.security. It has much in it and it brings many dependencies, including zope.app.form and company. And even some zope.* packages, like zope.securitypolicy still depend on it. So, let's finally refactor it :) Here's a sketch of a refactoring plan I wrote after taking a quick look at the current package: - Move IAuthentication and other interfaces into new zope.authentication package. Also move there PrincipalSource and the checkPrincipal utility function. Also move there the PrincipalTerms class, however that will add dependency on zope.browser (which is really really tiny, as you may know). Should we move the password managers registry and vocabulary to zope.authentication too? - Move global principal registry, its IPrincipal/IGroup implementations and its directives into new zope.principalregistry package. - Move LocalPermission into new zope.localpermission package. I personally didn't ever need local permissions. - Rewrite PermissionsVocabulary and PermissionIdsVocabulary not to depend on zope.app.component and move them into zope.security. It's generally useful there and won't introduce any new dependencies. - Move zcml definition of zope.Public permission. Maybe move security declaration for the `zope.security.permission.Permission` class as well. - Leave all browser views, globalmodules.zcml, _protections.zcml, other zope.* permission definitions in zope.app.security as well as backward-compatibility imports. - Just to note: the settings module was recently moved to zope.securitypolicy as there's the right place for it. Not sure about: - ILoginPassword and its basic implementations. The interface should probably go into zope.authentication while implementations - into zope.publisher. It will add a dependency on zope.authentication to zope.publisher, but the zope.authentication are expected to be really tiny and already installed for most applications, so I believe that it's okay. - PrincipalLogging - the adapter from zope.security.interfaces.IPrincipal to zope.publisher.interfaces.ILoggingInfo. I'd just move it into zope.publisher, because it's already tied to zope.security. - ILogoutSupported flag interface/adapter. Looks like it's only ever used for enabling/disabling the logout button in the UI. I'd deprecate it and leave in zope.app.security. That's an important feature. It could be really hard to nearly impossible to find out if an authentication provides logout or not without the ILogoutSupport adapter or a similar concept. We should think about how to replace that pattern if we skip the existing one. Regards Roger Ineichen ___ 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.container broken
Hi Tres Betreff: Re: [Zope-dev] zope.container broken -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: The zope.container package was broken. I added a missing ComponentLookupError import. Yup, and there is no test for that 'browserDefault' raising the error, either. Can someone with a linux/windows system release zope.component with the C extensions? Why do you need a release? Hm, I'm confused. Because the existing release is broken. I don't think we are quite done tweaking it, or adding package docs. For instance, I don't even know that anybody has run the compattest suite against the new version. I'm not up to date with zope.container. What is a show stopper for another release? Regards Roger Ineichen ___ 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.container broken
Hi Tres Betreff: Re: AW: [Zope-dev] zope.container broken [...] Can someone with a linux/windows system release zope.component with the C extensions? Why do you need a release? Hm, I'm confused. Because the existing release is broken. I don't think we are quite done tweaking it, or adding package docs. For instance, I don't even know that anybody has run the compattest suite against the new version. I'm not up to date with zope.container. What is a show stopper for another release? You asked for a release of zope.component, including C extensions. Uhhh, must be late last night ;-) Regards Roger Ineichen ___ 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] deprecating the deprecation system?
Hi Chris Betreff: Re: [Zope-dev] deprecating the deprecation system? Martijn Faassen wrote: Thoughts? + sys.maxint to all of that from me :-) I think documenting that something is going to go away is useful, but ultimately, people only really worry about it when something stops working. I've got way to bored to the millions of meaningless deprecation warnings emitted by *released* zope/plone/blah versions over the years... Millions, that doesn't sound like serious statement. Can you give an example of a meaningless deprecation warning? I don't know of any useless deprecation message. Every message makes me faster if I update my or zope code. Could it be that you depend on packages for a long time which deprecated code and don't have time to update them? I allways update my projects and migrate them if I work on something. This way I don't see any deprecation message on my production system. Or if so, I know what I have to for a next release. Regards Roger Ineichen Chris ___ 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 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] zope.container broken
Hi The zope.container package was broken. I added a missing ComponentLookupError import. Can someone with a linux/windows system release zope.component with the C extensions? Regards Roger Ineichen _ END OF MESSAGE ___ 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] deprecating the deprecation system?
Hi Martijn Betreff: [Zope-dev] deprecating the deprecation system? Hi there, Perhaps it's time to deprecate the deprecation system. Why? * I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do. It is always good to have such a documentation. But what does this have to do with removing a deprecation system? * using the deprecation system requires quite a bit of effort, as we're adding code. Do we test deprecations? That's quite a bit of energy spent there that we could instead spend on documentation. Yes, a deprecation system requires a lot of effort but that doesn't mean that the deprecation system is bad or good. I personaly think it's harder for me to write a good english documentation in the same time. But that's probably because I never learned english. * it's a zope-specific system no other Python projects use. Now we'll need some of them, but do we need this one? We have many things in zope which others don't use. That's no mesuring base for good or bad * we've not been very good at removing old deprecations over time. we can do it better * the deprecation system's messages have traditionally not been of a high quality. I recall occasions where it told me half of what to do, and certainly won't give me any background on what is going on. a unclear message is even better then no message * for moving code around we have an alternative system: a backwards compatibility import, documentation about what to do, and a tool part of the test runner which can point out indirect imports. I therefore propose we do the following: * look at any package which uses deprecation warnings now. * rip out the deprecation warnings and backwards compatibility code. Even if it's really expiring in 2010 (I doubt we have much of this). When you do so and you think anyone might still using that code path, please make a remark in zope3docs/source/migration/34to35.rst about what's going on and what people are to do. * run the compattests to see whether anything breaks. I think it's quite possible some deprecated code is in use by the Zope libraries themselves. :) I'm a little bit skeptic about this proposal. And I think no reason you listed does really explain why the deprecation system is bad. The only reason to use a deprecation system is to ensure that there is a deprecation period. I think the (real) reason why we can't use a deprecation system is that we don't like to support a deprecation period anymore because we like to evolve our package in a incompatible way now and not later. This makes our deprecation system useless and a migration path document is the only solution to handle that. Any other reason not using a deprecation system is just based on to less available time to support it or lazyness. btw, Right now it's very unclear how we identify versions like 3.4 / 3.5 What does that mean since packages have it's own versions e.g. 3.7.5 and are release within 3.4. How do you identify the zope version (3.4/3.5) of such a package? Thoughts? +/- 0 I let me surprise, let's try something new. We can still fallback to a deprecation system if everything else fails. Regards Roger Ineichen Regards, Martijn ___ 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 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.publisher
Hi Martijn Betreff: Re: [Zope-dev] zope.publisher Roger Ineichen wrote: Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. As long as zope.publisher's configure.zcml does it, Grok will load that up. Grok isn't different in that respect; it only uses Grok-style registration in packages that explicitly use grok or grokcore.* libraries. It's quite possible Grok can start using some of your changes for its REST skin implementation (which do apply to IBrowserRequest), though I'm not 100% sure. of corse, all changes are 100% compatible. The changes allow you to inherit from IHTTPRequest instead of IBrowserRequest and support a IDefaultSkin. The previous implementation required that the default skin pattern uses an IBrowserRequest. REST does normaly depend on IBrowserRequest but JSON-RPC doesn't have to, or you will get all the IBrwoserRequest parts in JSON-RPC too which is not good. Also XML-RPC has to be inherited from IHTTPRequest and not how it is right now from IBrowserRequest. XML-RPC should also allow to use it's own default skin and not depend on the IBrowserRequest default skin implementation. e.g. we do really not need a contents.html page in XML-RPC skins. But that's another (security) topic which we can discuss at a later time. I'm trying to understand why the default default skin cannot be registered as an interface, instead of the introduction of an adapter. Is this because defaultSkin can only be used for IBrowserRequest? Because it's not an adapter. It's doens't provide what it should provide and is registered for. The following will end in a TypeError: request BrowserRequest() defautlSkin = IDefaultskin(request) TypeError ... but it should return: IDefaultBrowserLayer Another side effect is that we get pickled interfaces in the adapter registry. That really hurts if someone does the same in a local (persistent) adapter registry and the interface get removed. The question is, should we allow to register such *junk* in the zope adapter registry? I think you need to update the upgrade notes in zope3docs too to point out this change. If there is anything people should change to their code, you need to explain how to find what needs to be changed and what change to make. You need to at least warn them that something big changed if they get problems with their skins and point them to zope.publisher's changelog. will do so soon I'll also note that this is *not* a minor bugfix release of zope.publisher, so it should be 3.6 not 3.5.7. Also don't use 'dev' markers in CHANGES.txt; only in setup.py. agreed Regards Roger Ineichen Regards, Martijn ___ 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 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] the Zope Framework project
Hi Paul Betreff: Re: [Zope-dev] the Zope Framework project On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. Regards Roger Ineichen These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ 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 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] zope.publisher
Hi Martijn, Shane I fixed some issues in zope.publisher and at the same time I implemented the default skin pattern within an adapter pattern. The adapter getDefaultSkin in zope.publisher.browser.py is registered in configure.zcml The changes are compatible within the zope core but only if zmcl is used. The concept is the following A request implementation can provide a named IDefaultSkin adapter within the name default. This default skin get used if no other default skin get defined. The IDefaultBrowserLayer is used as such a default adapter for IBrowserRequest. This was done hardcoded in setDefaultSkin before my changes. A default skin in your own projects get registered as an unnamed IDefaultSkin adapter. This is normaly done within the defaultSkin ZCML directive. Such a unnamed adapter get used before the setDefaultSkin method will lookup for the *fallback* named adapter. Everything is 100% compatible if the adapter configuration get used in configure.zcml. Questions - Everbody, Right now the setDefaultSkin method will silently fail if a skin doesn't provide ISkinType. What do you think should we raise an exception instead of silently ignore the skin? A general problem in the implemenation before and after my changes is that the skin interfaces registered by the defaultSkin ZCMl directive will register the interface as adapter which is not adaptable because it's not an adapter factory. Should we change the defaultSkin directive and register an adapter factory? This whould ensure that we don't have junk in the dapter registry. Another question The applySkin method removes all skin types from the request. Why do we not remove all skin types in setDefaultLayer? Are there any skins applied at the time we call setDefaultSkin? Martijn, Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. Shane, Can you review and merge this changes into your zope.pipeline branch? Regards Roger Ineichen _ END OF MESSAGE ___ 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] the Zope Framework project
Hi Betreff: Re: [Zope-dev] the Zope Framework project [...] Grok and Repoze are in part *workarounds* for the deficiencies in this community. For Grok I'm very sure it's a workaround, as I had quite something to do with it and this was explicit in my mind. It's not *only* a workaround, but it's definitely a community hack, too. I don't agree one bit it's workaround for deficiencies in the community. It's workarounds for deficiencies Zope3. And the community has fixed them. You can also call this anticipation the oposit of participation But I know it's much more productive to impelement a new framework then to convince other developer to change something in existing zope. And sometimes it has to happen. We also did this in several z3c packages. The good thing right now is that we have different experiences and can merge the good concepts back to the zope core or offer different implementations solving similar problems in different ways. The big questions now is, do we like to merge this good things back to the zope core or do we like to stay with different packages because we can't find an agreement what we like to do. Regards Roger Ineichen ___ 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] the Zope Framework project
Hi Martijn Betreff: [Zope-dev] the Zope Framework project The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 I generaly agree and give you a big +1 for do something and get a new fresh drive into our development process. I probably will disagree with some details but for myself it's much more important that we look forward and find a better way how we work together. In my point of view we should do the following: precondition: Don't do to much fomral things like write this document. 1. call for participation for a group of people that are interested to work together 2. make progress with the refactoring and dependency cleanup we started 3. show what we did and propose visions and strategies 4. get acceptance for what we this group did. I'm pretty sure that after an intial progress most developer will agree on future visions if the work is well done and is based on the right descissions the working group made. The zope community is not very good in find a way out of problems and tend to discuss things till nothing happens. But all the time if someone just did something it ends probably with a good result. Especialy if some developer work together. See grok, repoze or some z3c.* libraries Let's just call for participation. I'm pretty sure we will find the right road with the people which will contribute their ideas and will help to make progress. btw, I could organize a sprint this spring if some people are interested. Regards Roger Ineichen ___ 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] the Zope Framework project
Hi Chris Betreff: Re: [Zope-dev] the Zope Framework project Martijn Faassen wrote: The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 Introduction This document offers suggestions to reorganize our community so we can act more effectively. It does this by trying to clarify what our community is about. The document tries to innovate minimally in concepts and naming in order to provide a relatively small evolutionary step forward that can still make us all work together better. Even though this is an evolutionary step, it will still have a big impact if implemented, so please read on. This document should be relevant to *all* the parts of our community that build web applications, whether they use Zope 2, Zope 3, Grok, Repoze, or applications built on top of these such as Plone or Silva. While it talks a lot about Zope 3 this is because the Zope technology within Zope 3 is used within all these projects. The document wants to recognize this officially. The main innovations in concepts are the name Zope Framework to distinguish it from the Zope 3 application server and the core/extra concept. These are all hopefully descriptions of what are current practices, simply making them more explicit. The biggest innovation is the introduction of a Zope Framework Steering Group as a new entity that will be the steward for the development of this framework. The steering group's primary aim is to facilitate developers in the community so that they can continue to maintain and develop the framework so that it is useful to all of us. I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) Do you see any benefit not following a style policy? I think that's the minimum price we have to pay if we work in a community. btw, our zope style policy is defently not very strict and gives most developer enough room for individual coding style. - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). - focusing on externalizing software; each egg should stand on its own as something that a non-Zope person would be able to understand and use in isolation. This means documentation for each thing, as well as a sane dependency graph. This is *less* about giving this collection of software a group name (the zope framework) and more about making people *forget* that it is a part of some larger thing. When a piece of software does not have a purpose in isolation but still lives in its own egg, kill it off and merge it back into whatever thing its most closely related to. - Stop trying to version control and treat all this software in some overall release. Let each piece of software have its own life. Likewise if a piece of software does not have its own life, kill it. I'm pretty sure you are not using much zope.* or z3c.* packages in your projects as dependency. Your idea is not bad in general, but as a developer which developed all projects based on zope packages your idea could become a nightmare. Years ago I convienced Stephan Richter to start with a new namespace called z3c because we implemented some experimental things like viewlets, templates, macros, pagelets etc. I think this is what happens with repoze and grok too. Now I think it's time to merge the good patterns back to the zope core and replace some old stuff. But we should be carfull with break things if possible. Radical changes and experimental stuff should allways be optional till it's ready, stable and used by a bigger audience. At least it should be very good documented for others which have to update thier projects if we switch to a new concept. Regards Roger Ineichen ___ 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] Proposal: merge zc.configuration's exclude directiveinto zope.configuration.
Hi Martijn Betreff: Re: [Zope-dev] Proposal: merge zc.configuration's exclude directiveinto zope.configuration. Hi there, On Thu, Feb 26, 2009 at 12:43 PM, Roger Ineichen d...@projekt01.ch wrote: Now we only need to find out how to write an z3c.autoexlude and a z3c.autooverride library ;-) :) Just so that this doesn't get misinterpreted, autoinclude includes packages just like manual include statements do underneath, so there should be no incompatibility with the exclude directive at all. You can override autoincluded packages just like you'd override any included package. In addition there's an includeDependenciesOverrides directive which can include overrides automatically if you wish to do that. If a package uses z3c.autoinclude to include its dependencies there'll be no difference in what you can do concerning overrides or exclusion. I was just kiding as you saw. But this sounds very good to me since it has no other side effects! Thanks Roger Ineichen Regards, Martijn ___ 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] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Hi Shane Betreff: Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3 Martijn Faassen wrote: One question: why is this in zope.app? I think there's a consensus we're trying to pull as much from zope.app as possible. Is this going to provide a ZMI UI at all? If not, I'd suggest putting it in zope.* I admit I'm being lazy here. It seems like zope.app is a dumping ground for packages with muddy dependencies. I didn't want to work out the dependency list yet. :-) I do have some justification though: it depends on IAuthentication, which is in zope.app.security. Still, I suspect IAuthentication needs to be moved out of zope.app.security. just a note; I have still a refactoring pending which which I proposed month ago. This will move the IPasswordManager out of zope.app.authentication. Regards Roger Ineichen Shane ___ 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 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.pipeline proposal
Hi all Betreff: Re: [Zope-dev] Zope.pipeline proposal Hey, Tres Seaver wrote: [snip] In general, if you need full-on backward compatibility with the existing behavior of Zope2 / Zope3 / Grok, switching to a paste-driven WSGI pipeline doesn't gain you much speed (but it is not a loss, either). If, for a given application, you can relax the BBB requirement, then some performance wins are available via WSGI which can't be made in the monolithic publisher (dropping out features by removing the middleware layer). As for Grok I hope we can break some backwards compatibility and get some larger performance speedups. We definitely need to aggressively keep moving forward in this area. Not even primarily for speed gains but also for comprehensibility; I find Chris's what's it doing report far more worrying than differences in speed at this point: http://plope.com/whatsitdoing2 This is why zope.pipeline is such an important effort to me. Not that it will immediately make things better, but it would hopefully open up a path to move the Zope Framework forward in this area. I absolutly agree! As far as I can see, the repoze sample doesn't open a ZODB which makes it not really comparable. Regards Roger Ineichen ___ 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.pipeline proposal
Hi Tres http://plope.com/whatsitdoing2 This is why zope.pipeline is such an important effort to me. Not that it will immediately make things better, but it would hopefully open up a path to move the Zope Framework forward in this area. I absolutly agree! As far as I can see, the repoze sample doesn't open a ZODB which makes it not really comparable. I think you've made Chris' point for him: nothing about the application being tested *requires* that there be a ZODB connection open; Grok's design forces opening one unconditionally, which is a layer of complexity which *can't be turned off.* The conceptual overhead of each of the frameworks is at least as important as the performance overhead. Yes, that's true. But I like to see the real performance win within a *real* application. My applications normaly do not only show a hello world page ;-) I also like to see how much the repoze method calls will grow if the authentication, transaction, ZODB etc is involved. I'm pretty sure that it will much less then 20 times like in the given test. I'll also be happy if we will gain a 2 time perfomance factor in a real comparable test app. I've developed a prototyping package in my own personal repos which tries to setup a site within some objects which I use with the old zope server and a paste WSGI server setup. This let us run performance tests against the ZODB. Probably I should add that to the zope repos and we could start adding all our different publishing implementations. This whould let us compare the same things in a real world use case. Regards Roger Ineichen ___ 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] z3c.jsonrpc relase
Hi Jim Betreff: Re: [Zope-dev] z3c.jsonrpc relase Roger Ineichen wrote: does someone have a good idea how we can handle an Unauthorized error with JSON-RPC? Should we use an error view concept and include a JavaScript method which can handle a special error code/message from the server and show a kind if login form? Any hints or does somebody know a framework which supports such an implementation? Hi Roger Here's a hint I've been looking at. Maybe it will give you some ideas. http://ajaxpatterns.org/Direct_Login Thanks a lot for the hint. Regards Roger Ineichen _ END OF MESSAGE - Jim Washington ___ 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] z3c.jsonrpc relase
Hi jukart I just released the newest z3c.jsonrpc version including your changes. btw, does someone have a good idea how we can handle an Unauthorized error with JSON-RPC? Should we use an error view concept and include a JavaScript method which can handle a special error code/message from the server and show a kind if login form? Any hints or does somebody know a framework which supports such an implementation? Regards Roger Ineichen _ END OF MESSAGE ___ 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] z3c.form update issues
Hi all I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions. For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120 Can you please review if this and let me know it this is compatible with our own z3c.form parts? My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update. Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call. Any hints/ideas about that. Or do you know a good use case for this problem. It also smells to me that the MultiWidget or the ObjectWidgets implementation could be more robust within a better update/execute concept. Regards Roger Ineichen _ END OF MESSAGE ___ 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] z3c.form update issues
Hi Dan Betreff: Re: [Zope-dev] z3c.form update issues 2009/2/21 Roger Ineichen d...@projekt01.ch: Hi all I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions. For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120 Can you please review if this and let me know it this is compatible with our own z3c.form parts? My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update. Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call. Any hints/ideas about that. Or do you know a good use case for this problem. It also smells to me that the MultiWidget or the ObjectWidgets implementation could be more robust within a better update/execute concept. IIRC, the update and execute phases are already separated for actions (you call actions.update() for setup and actions.execute() for actual execting) and that fact is used in MultiWidget and many custom forms. Yes, I think we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions. I'll see later if I take another look at that part. Regards Roger Ineichen _ END OF MESSAGE -- WBR, Dan Korostelev ___ 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] z3c.form update issues
Hi Dan Betreff: Re: [Zope-dev] z3c.form update issues 2009/2/21 Dan Korostelev nad...@gmail.com: 2009/2/21 Roger Ineichen d...@projekt01.ch: we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions. ... snip ... One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :) I just checked in a fix like I described above. It seems to work at leasts for tests.:-) Can you please review it? Yeah great, that's exactly what we need to do. Thanks a lot! Regards Roger Ineichen _ END OF MESSAGE -- WBR, Dan Korostelev ___ 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] How can we update our source?
Hi all First, thanks to the great refactoring work! Can someone give a summary about what got moved or is there another way to find out what I need to change in z3c and own packages? I guess there must be an update strategy since we skipped the deprecation message which I don't know. or not? Regards Roger Ineichen _ END OF MESSAGE ___ 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] How can we update our source?
Hi Christian Betreff: Re: [Zope-dev] How can we update our source? On Tue, 03 Feb 2009 01:49:25 +0100 Martijn Faassen faas...@startifact.com wrote: Hey, Roger Ineichen wrote: First, thanks to the great refactoring work! Can someone give a summary about what got moved or is there another way to find out what I need to change in z3c and own packages? I guess there must be an update strategy since we skipped the deprecation message which I don't know. or not? Basically I gave a description of what the major changes were: zope.app.folder - zope.site (for Folder), zope.container (for base class to implement Folder, not typically to import from though) zope.app.container - zope.container This information is also in the changelog of these packages and these packages have undergone major (x.Y.z) releases. Nevertheless we've put re-imports in place so current code should be easy to get working again. With one exception: some dependencies were cleaned up, and if you didn't declare your direct dependencies correctly, you'll have to do some trial-and-error. This is especially true for persistent classes for which the package became obsolete. You'll have to add a direct dependency on the old package containing that code and can remove it, once your persistent data has been touched (I'm working on a tool for that, too). I think perhaps the zope3docs area should contain a document about major changes in the whole collection of Zope 3 libraries with this kind of information. This reminds me a lot of what we used to write as proposals ... if we had one, this would have been a good place to - reference from the CHANGELOG - describe what happened - describe how to upgrade I think documentation of major changes is actually an upgrade strategy that we shouldn't ignore as a project. This is often better than seeing isolated deprecation warnings which sometimes even neglect to say what people should be doing, let alone why. A document can do so better. In order to get hints about better import locations the test runner (trunk) contains an option to let it report this information (you imported something from here but in turn that actually comes from somewhere else). This tool is not perfect (it cannot report on instances being imported, only classes and functions) but should be useful in finding hints of better import locations. It doesn't depend on the deprecation system. Christian Theune should be able to tell people more about this tool. I'll write something as soon as I have the tests finished and this stuff released. Thanks, sounds good to me. Regards Roger Ineichen ___ 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] Request input on bug about HTTP response.setStatus
Hi all Betreff: [Zope-dev] Request input on bug about HTTP response.setStatus Hi all. There's some disagreement about how to resolve the bug below, even though there's agreement that we want it resolved. Your input would be appreciated so we can find a consensus and move forward with a solution. https://bugs.edge.launchpad.net/zope3/+bug/322486 As far as I can see, we all agree that we need to be able to use new response status. And the question is, should we be able to use them ad hoc or do we need to declare them first. In programming language normaly you can just use things. But a framework like a server must be configured first befor you can use new things. I think it's a question if the response setStatus is a kind of the server as a framework or if this is just another python method. As far as I can tell, I personaly like to use setStatus(209) and I whould be surprised if something other then 209 get returned as 209 by getStatus() (as shane told). another solution could be to introduce an additional argument. (seatbelt) e.g. def setStatus(status, force=False): if force: # don't fallback to status 500 else: # fallback to 500 if given status doesn't exist Anyway, Python is a bike and java is a car. Because why? Java has built in seatbelts and airbags and Python is light and fast. Regards Roger Ineichen ___ 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.globalrequest?
Hi Martijn Betreff: Re: [Zope-dev] zope.globalrequest? Hi there, Roger Ineichen wrote: [snip] Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I don't think that's always true. Let me give you an example. I wrote a library called hurry.resource. This library is framework neutral. You can define a javascript or css resource and express that you need it to be included in the page in a certain code path: yui.datatable.need() I also have a library called hurry.zoperesource. This library provides integration of hurry.resource with Zope 3. When need() is called in a Zope 3 context, I need the request object as I chose the request object as the place to store the list of resources that are needed. So I need to get the request without having it. You could argue my library isn't designed right, and that instead I should require people to pass 'request' to the .need() method. But since hurry.resource is framework-neutral, what request should that be? And in a system like Pylons it makes no sense to have to pass in the request, as it's available globally everywhere. It only seems to put an implementation detail into the API. Besides the framework neutralness argument, which you can argue makes no sense, I think it's simply a nicer API to say '.need()' instead of having to pass the request. That's a weaker argument, however. That said, zc.resourcelibrary does the same strategy, as that's where I took it from. Anyway, I do believe there are cases of APIs that need the request internally but want to abstract it away as an implementation detail. I guess I might've been able to use the interaction directly in Zope 3's case and I shall study that. There are of course drawbacks (as mentioned) with testing and such when taking this approach. But I think one can make a reasonable case for such an API nonetheless, when used in moderation. I see your point. I'm not saying that this is bad in general. Probably when used in moderation is the right concept for this package ;-) Regards Roger Ineichen Regards, Martijn ___ 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 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.globalrequest?
Hi Andi Betreff: Re: [Zope-dev] zope.globalrequest? Roger Ineichen wrote: I don't say that this is bad in general. I just say that if you build an application based on zope.globalrequest, this is a totaly different base concept how you will develop applications like we do now. And you have to pay the price with a complex test setup. it's merely one more package and its zcml (setting up two event subscribers). considering the complexity of the stack as we know it i don't think it really adds that much, no? I think it's more then that It changes the way you will think about MVC and the way you develop and take care on separate your model, view controller components. It's like aquisition in Zope 2, you don't have to take care where your attributes coming from, they're just there. Doesn't matter if this is good or bad, it's just a very different concept. Defently a bad thing is, if to many developer start using zope.globalrequest in their 3rd party packages. We can't reuse this 3rd party packages whithout using a global request variable. In my point of view it's a fundamental change on what an application is built on. Probably the good thing is, it's easy to provide such a global request as long as you use a webserver (publisher). just a sample; In my point of view an application like a wiki or forum etc. should get developed as a python application without to require a global request because it's just a (MVC) model part. There should never be a request involved. If such a wiki needs a last modified user argument. This should not get set by a global request lookup. Or at least not the model should use such a global request by itself. If you need to set such a last user modified argument the view/controller should be responsible for doing so. I'm pretty sure if we have a global request available we will see very quick that developer start to use the global request in the model part. Note, mixin model, view and controller responisibilities into one component/object make it allmost impossible to replace or reuse parts of it. Regards Roger Ineichen best regards, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1.7 released! -- http://plone.org/products/plone/ ___ 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 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.globalrequest?
Regards Roger Ineichen _ END OF MESSAGE -Ursprüngliche Nachricht- Von: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] Im Auftrag von Laurence Rowe Gesendet: Sonntag, 18. Januar 2009 16:43 An: zope-dev@zope.org Betreff: Re: [Zope-dev] zope.globalrequest? Roger Ineichen wrote: just a sample; In my point of view an application like a wiki or forum etc. should get developed as a python application without to require a global request because it's just a (MVC) model part. There should never be a request involved. If such a wiki needs a last modified user argument. This should not get set by a global request lookup. Or at least not the model should use such a global request by itself. If you need to set such a last user modified argument the view/controller should be responsible for doing so. I'm pretty sure if we have a global request available we will see very quick that developer start to use the global request in the model part. Note, mixin model, view and controller responisibilities into one component/object make it allmost impossible to replace or reuse parts of it. The most convincing reason for me to persevere with the current pattern of views is that it offers the possibility of adaption on the request. This is something that repoze.bfg is exploring and I think could be helpful, for instance registering separate views on POSTRequest from GETRequest. I don't see anything wrong in allowing a utility access to the request without explicitly including it in its method signature. If they choose to use it from a model, it's their foot and they are free to shoot it if they wish. Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I fully agree with Christian if he says this is an anti pattern. Not ure but probably Reinventing the square wheel is the anti pattern was thinking about. http://en.wikipedia.org/wiki/Reinventing_the_square_wheel Regards Roger Ineichen Laurence ___ 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 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] Some tools from the Launchpad project
Hi Gary Betreff: [Zope-dev] Some tools from the Launchpad project Hi all. As announced elsewhere (and described in https://dev.launchpad.net/OpenSourcing) , Canonical's Launchpad project is working towards open-sourcing the majority of the code base by this summer. Prior and subsequent to the grand open-sourcing date, the Launchpad developers are encouraged to abstract stand-alone code for distributions. Since Launchpad uses several Zope libraries, some of the stand-alone packages may be of special interest to the Zope community. Unsurprisingly (at least if you know Launchpad), the packages use bzr for revision control, and Launchpad for codehosting, bug tracking, and so on. Currently we are standardizing on zc.buildout-based releases for these packages. We have two at the moment: http://pypi.python.org/pypi/lazr.delegates Provides an interesting Python delegation pattern. Uses zope.interface. cool ! 1+ for move this to zope.interface Regards Roger Ineichen ___ 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Martijn Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] Hey there, Roger Ineichen wrote: [snip] I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode? I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB. I don't like the use of devmode for that, especially as I hardly ever use devmode for anything (Grok doesn't really do much with it as far as I know). I prefer a tool that's external to the source code in question. You could base it off something like that importchecker (see pypi) does. It'd analyze what imports take place and whether it's importing from a place that marks itself as deprecated. Your mention of the ZODB issue brings up a good point. We'd also need a ZODB-level tool that can do this reporting in this case. The current deprecation system already covers this case, though, right? Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. The benefit is also that it'd be thorough and find all instances, not just those that happen to be in use by a particular application. I'm fine with any implementation. I just don't like to loose this (for me) important feature. Note; I think nobody is able to develop an application which does the cleanup right if objects get removed. At least I don't know any application where all objects get correct removed and I know different apps developed from different companies. Also my own apps don't do the cleanup correct right now. Or does someone remove items (e.g. dublin core) from the annotations for removed objects or the annotation container itself etc. etc? There is also an issue with interface references in the adapter registry. Interfaces (pickle) do not get removed. This means we really need deprecation warnings in running applications. Probably a good start whould be a script which allows to access every object in the ZODB by iter all objects and see if something raises a deprecation warning. Regards Roger Ineichen Regards, Martijn ___ 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 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Christian Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] On 2008-12-22 18:48:47 +0100, Martijn Faassen faas...@startifact.com said: Hi there, All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them. I think we need to think of some way to signal that the preferred import location of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely. Right. May I remove the deprecation warning then? Yes, but only after someone implemented another concept for notify about old import location ;-) I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the right public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end. A correctly crafted BBB together with some simple grep-like tool would be sufficient, would it not? What is grep ;-) I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode? I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB. Regrads Roger Ineichen ___ 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] ZODB 3.8.1 issue
Hi Jim Just found an issue in ZODB 3.8 branch. (3.8.1 release) The line: 370 in blob.py uses *targetpath* (undefined) This should be *path*. The current 3.9 trunk is fixed. I didn't fix and release that issue because I only have a MinGW compiler installed. Can you pick that up? Regards Roger Ineichen _ END OF MESSAGE ___ 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] If we that there is a real goal other than future cleanliness for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer. I think it's more then future cleanliness. My goal is to reuse as much as we can. This means, if we deprecate zope.app.form.browser.interface.ITerms. And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects. If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts. I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base. And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do. Reegards Roger Ineichen ___ 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] One issue is that adding deprecation messages for importing symbols from the old makes all downstream code add ugly BBB warts in order to suppress them when run against multiple versions. Yes, that's exactly what deprecation message do. Deprecation messages in tests do not have to win a beauty award. The goal of a deprecation message is to inform developers about upcomming changes. This ugly BBB output is very important to me! This allows us to schedule our work and we don't run into removed backward compatibility issues. This makes deprecation messages something like a reminder and nothing which we should ignore. If we don't use deprecation messages we can not do future cleanup because we can't remove old not deprecated code. This means using deprecation message or not depends on the need for a future cleanup. If we like to support an old interface location then we don't need deprecation messages. But if we like to remove the interface at the old location in the future then we need to deprecate them. This has nothing to do with beautify our test output. Regards Roger Ineichen ___ 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] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
Hi Christian Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?] [...] A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. btw, we also should deprecate the ISite interface at the old location. Regards Roger Ineichen ___ 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Christian Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] On 2008-12-15 13:44:43 +0100, Roger Ineichen d...@projekt01.ch said: Hi Christian Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?] [...] A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. Depends. See below. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. Yes, for necessary API changes which do not need to be shipped immeadiately I can see that. btw, we also should deprecate the ISite interface at the old location. Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings. All I can say about that is: If there is an improvment in the API we need to announce that. Otherwise other developer will not follow or follow at a time they think it's better for them. Or even worse, they don't know about that. Deprecation messages will kick them a little bit and they get forced to update their code in a acceptable way ;-) The question now is, should we be lazy and skip this information and support nice deprecation free test output or support developer with information about the newest API changes in form of deprecation message hints? Regards Roger Ineichen ___ 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 )
