[Zope-dev] Re: [Checkins] SVN: z3c.jbot/ Initial import.
But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? The package makes no assumptions that Five is available, but there are tests for a scenario where it is. \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] Re: Bug in AbsoluteURL Adapter
Philipp von Weitershausen schrieb: Sebastian Wehrmann wrote: while using the AbsoluteURL Adapter in a view, By the way, you're using Five's AbsoluteURL adapter. (It's different from the one in Zope 3). Also, the patch below seems to be for Five. Would be good to mention that :). You are right. I forgot to mention it because the mail was originally for the Five mailing list, which does not exist anymore, though. Any comments? Can you round up a test that demonstrates how the current implementation fails to cover your case and how your suggestion change fixes that? While trying to write a test it turned out, that it's not a problem in Five but in the interaction between Plone3 and Zope2/Five. The problem we tried to solve was: We have a structure of Plone content objects. We wanted to access a particular one in a view which can be called anywhere. Therefore we registered this content object as an utility. It turned out, that this utility does not have a request after fetching it in our view with getUtility(). The request is needed to get an absolute URL of our content object. We solved the problem temporarily with an adapter which overrides Five's AbsoluteURL adapter which contains the code from the patch. Anybody an idea how to do this in a better way? -- Sebastian Wehrmann gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale · germany www.gocept.com · work. +49 345 122988912 · fax. +49 345 12298891 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Bug in AbsoluteURL Adapter
On 28 Nov 2007, at 11:45 , Sebastian Wehrmann wrote: Can you round up a test that demonstrates how the current implementation fails to cover your case and how your suggestion change fixes that? While trying to write a test it turned out, that it's not a problem in Five but in the interaction between Plone3 and Zope2/Five. The problem we tried to solve was: We have a structure of Plone content objects. We wanted to access a particular one in a view which can be called anywhere. Therefore we registered this content object as an utility. It turned out, that this utility does not have a request after fetching it in our view with getUtility(). The request is needed to get an absolute URL of our content object. This is what I don't understand: why should content objects have access to the request? I understand that the request is needed in order to compute the absolute URL, but the IAbsoluteURL adapter is a *multi*-adapter for (context, request). So it will always receive the request explicitly in its constructor. This pattern is the foundation of separating content from presentation: the content object is request- unaware, the adapters and views around it are request-aware. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: unregistering components?
Philipp von Weitershausen wrote: So zope.app.component replaces the getSiteManager implementation in zope.component? :-( Yes. It's a shame this couldn't have been implemented in a more component-architecture-oriented way, but I'm guess things get chicken-and-egg-y at this point? zope.thread.local provides an implementation for the thread-local variable, ...which both Python 2.5 and Python 2.4 (now that you reminded me ;-) ) have. in Python 2.4 under 'threading.local'. The latest version of zope.thread.local just refers to 'threading.local'. Ah, I see :-) Also, where's the code which, in the local registry, defers to the global registry to find more adapters/subscribers/whatever? Look for the __bases__ property and its dynamic setter. Okay, but where's this code? (ie: what .py should I look at for the local registry implementation) I think zope3-users is also for the users of the separately usable components. Well, as it turns out, they're not so separately usable right now, at least when you're tryinig to easy_install zope.component or so :(. But at least we're working on that. I still can't make out if the whole eggs/easy_install thing just sucks and we should build something else for the python community (it's not just zope that's struggled with easy_install ;-) ) or if it's just zope that's had the real problems 'cos of some bad eggs... I think there's value in separating development from the rest of the traffic. Why? As far as [EMAIL PROTECTED] is concerned, I see a lot of old-school (e.g. DTML-related) traffic there, Really? I don't see much activity on that list at all nowadays, although there was quite an interesting thread (and quite relevent to zope3 and zope-dev) that kicked off which involved dtml ;-) PS: I am quite excited that it looks like I may actually be able to use bits of zope independently, and this wsgi stuff looks pretty cool too :-) Cool! Be sure to let us know about it afterwards. I think we could use some feedback on projects like this. Will do, but please be patient with my fumblings in the meantime. If it helps, as far as components and registries goes, I'm aiming for something like skin-like stacked registries that can be altered ttw... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Re: Additional locales for zope.i18n.locales.data?
On Nov 28, 2007 12:29 AM, Nathan Yergler [EMAIL PROTECTED] wrote: If you follow the wink, http://www.unicode.org/cldr/repository_access.html has the details to the files. Currently the latest is at http://unicode.org/Public/cldr/1.5.0/core.zip. Zope at this point still uses LDML 1.0 whereas the latest version is LDML 1.5. Upon casual inspection of the files it seems their basic structure is still the same, though more careful inspection is required. I've been avoiding even less interesting work this afternoon, taking a look at this. I started by dumping the new files into the data directory and just running the tests. As expected, things blew up in a really spectacular manner. After some wrangling I've discovered that in the newer versions of the CLDR dataset some of the information previously contained in the locale files (such as weekend start/end, etc), is now in located in a supplemental file. While this makes a certain amount of sense (it's tied to territories, not really languages), it does mean that the information needed for a Locale is no longer self-contained in a single XML file. So unfortunately it's going to require some more work to fix up the loader; I'll probably create a branch to work on this some... Has anyone looked at Babel (http://babel.edgewall.org/)? It includes a python interface to CLDR, which if usable would let us off the hook of maintaining such an interface ourselves. -- Martijn Pieters ___ 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] AW: [Checkins] SVN: z3c.jbot/ Initial import.
Hi Malthe Betreff: Re: [Checkins] SVN: z3c.jbot/ Initial import. But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? The package makes no assumptions that Five is available, but there are tests for a scenario where it is. Thanks, sounds good to me if it's only for testing. 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 )
[Zope-dev] Solved!, was: Re: Escaping special characters in ZCTextIndex.QueryParser?
mustapha wrote: Robert Casties wrote: Enclosing the words with double quotes has not helped, neither have backslashes... You have to enclose your string with double quotes and then with single quote. So the parser gets the double quotes with the search string The parser does not interpret the string between double quotes. Ok, it was my fault :-( The query parser does not interpret expressions in double quotes, it was my special splitter that got called from the QueryParser (I didn't know that the QueryParser does that) that split and deleted all parentheses before the actual search. Now I have changed my splitter and it works as expected. Thanks a lot Robert ___ 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] Re: Bug in AbsoluteURL Adapter
On 28 Nov 2007, at 12:54 , Daniel Havlik wrote: Am 28.11.2007 um 12:01 schrieb Philipp von Weitershausen: The problem we tried to solve was: We have a structure of Plone content objects. We wanted to access a particular one in a view which can be called anywhere. Therefore we registered this content object as an utility. It turned out, that this utility does not have a request after fetching it in our view with getUtility(). The request is needed to get an absolute URL of our content object. This is what I don't understand: why should content objects have access to the request? I understand that the request is needed in order to compute the absolute URL, but the IAbsoluteURL adapter is a *multi*-adapter for (context, request). So it will always receive the request explicitly in its constructor. This pattern is the foundation of separating content from presentation: the content object is request-unaware, the adapters and views around it are request-aware. Exactly, thats why we thought this may be a bug. The __str__ method of Five's AbsoluteURL adapter does not make use of the request the adapter gets in its constructor, it just calls the zope2-ish absolute_url() method on the context. (Which itself relies on the REQUEST attribute of the object to convert the path to an URL) I see what you mean now. In that case I agree that it would be cleaner to use the adapter's request, *IF* request.physicalPathToURL(obj.getPhysicalPath()) will always yield the same as obj.absolute_url(), especially regarding virtual hosting, etc (if we don't have tests for that yet, creating some would be extremely good). If the improved version of the adapter will also fix a few problems when used with Plone, it would still be good to have tests that provoke such circumstances and verify that the new implementation is indeed better. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Additional locales for zope.i18n.locales.data?
Martijn Pieters wrote: On Nov 28, 2007 12:29 AM, Nathan Yergler [EMAIL PROTECTED] wrote: If you follow the wink, http://www.unicode.org/cldr/repository_access.html has the details to the files. Currently the latest is at http://unicode.org/Public/cldr/1.5.0/core.zip. Zope at this point still uses LDML 1.0 whereas the latest version is LDML 1.5. Upon casual inspection of the files it seems their basic structure is still the same, though more careful inspection is required. I've been avoiding even less interesting work this afternoon, taking a look at this. I started by dumping the new files into the data directory and just running the tests. As expected, things blew up in a really spectacular manner. After some wrangling I've discovered that in the newer versions of the CLDR dataset some of the information previously contained in the locale files (such as weekend start/end, etc), is now in located in a supplemental file. While this makes a certain amount of sense (it's tied to territories, not really languages), it does mean that the information needed for a Locale is no longer self-contained in a single XML file. So unfortunately it's going to require some more work to fix up the loader; I'll probably create a branch to work on this some... Has anyone looked at Babel (http://babel.edgewall.org/)? It includes a python interface to CLDR, which if usable would let us off the hook of maintaining such an interface ourselves. Looking at the API docs, it seems that the ILocale implementations in zope.i18n.locale could simply make appropriate calls to functions in the Babel API. So +1 from me, but since it looks like Nathan will be doing the work, he should decide :). Babel seems to exist since mid-2007, by the way. I wonder, if we had made zope.i18n separately available sooner and actually told people about it, it possibly wouldn't have been necessary to duplicate the effort there. In fact, the Babel website lists zope.i18n as an alternative, but finds that it's tied too closely to Zope 3. * zope.i18n has a scope similar to Babel (covering both gettext and the CLDR), but is closely tied to Zope 3. * PyICU is a Python/SWIG wrapper for the ICU library, and provides access to locale data based on the CLDR (or the other way around). It would be interesting to get in touch with the original authors and ask them whether zope.i18n's 4 or so dependencies still make it too tied to Zope 3. ___ 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] AW: [Checkins] SVN: z3c.jbot/ Initial import.
Roger Ineichen wrote: Hi Malthe Betreff: Re: [Checkins] SVN: z3c.jbot/ Initial import. But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? The package makes no assumptions that Five is available, but there are tests for a scenario where it is. Thanks, sounds good to me if it's only for testing. Except that if those tests are only run after manual intervention (i.e., after editing something in the checkout or environment), then if a hapless contributor can check out z3c.jbot, make changes, run the tests (and they all pass), and check in the changes and those changes may have broken the parts of the code that only are tested if Five is around. These sorts of situations are where works out of the box testing really helps. Maybe I'm misunderstanding how these tests are set up. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: [Checkins] SVN: z3c.jbot/ Initial import.
Roger Ineichen wrote: Hi Malthe Betreff: [Checkins] SVN: z3c.jbot/ Initial import. Log message for revision 81997: Initial import. [...] + from Products.Five.browser.pagetemplatefile import + ZopeTwoPageTemplateFile I really like what you are doing, cool ideas! But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? We do have the 'five' namespace for things like that, by the way (so far it's used by five.intid and five.localsitemanager, for instance). I'm not sure about that, it's just a question. What do you think about a namespace called z5c or something like that? I guess it's easier to explain the different core concepts if we separate them in base libraries. Or is it possible to skip the Five dependency and implement Five support in a second layer/package? -1 to magic or weak dependencies. +1 to test what you fly and fly what you test btw, I think since we use buildout, it's not possible to implement mixed Zope3/Five packages bacause setup has to define the Five packages too. right? In general, it makes the reuse of a package difficult if it depends on Zope 2 stuff (incl. Five). ___ 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] Re: Additional locales for zope.i18n.locales.data?
Philipp von Weitershausen wrote: It would be interesting to get in touch with the original authors and ask them whether zope.i18n's 4 or so dependencies still make it too tied to Zope 3. For me, it's be interesting to see what it'd take to drop zope.18n completely and just use Babel ;-) (ie: we as the zope community should be trying to do less and re-use good stuff from the python community rather than building our own which then ends up in a mess of unnecessary dependencies...) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Additional locales for zope.i18n.locales.data?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Philipp von Weitershausen wrote: It would be interesting to get in touch with the original authors and ask them whether zope.i18n's 4 or so dependencies still make it too tied to Zope 3. For me, it's be interesting to see what it'd take to drop zope.18n completely and just use Babel ;-) (ie: we as the zope community should be trying to do less and re-use good stuff from the python community rather than building our own which then ends up in a mess of unnecessary dependencies...) Please separate out the dependency problem from NIH: in this case, zope.i18n predates the NIH package by *years* (the i18n support was the topic of the *first* extra-mural Zope3 sprint, in January of 2002). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFHTeri+gerLs4ltQ4RApR8AKCYl0brIQszXFHVIMVltXIG+mRSJACgmVFt jZ3ll2SOgx5ElQQ3J3H/sFA= =iGLY -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 )
Re: [Zope-dev] Re: Additional locales for zope.i18n.locales.data?
On 11/28/07, Martijn Pieters [EMAIL PROTECTED] wrote: On Nov 28, 2007 12:29 AM, Nathan Yergler [EMAIL PROTECTED] wrote: If you follow the wink, http://www.unicode.org/cldr/repository_access.html has the details to the files. Currently the latest is at http://unicode.org/Public/cldr/1.5.0/core.zip. Zope at this point still uses LDML 1.0 whereas the latest version is LDML 1.5. Upon casual inspection of the files it seems their basic structure is still the same, though more careful inspection is required. I've been avoiding even less interesting work this afternoon, taking a look at this. I started by dumping the new files into the data directory and just running the tests. As expected, things blew up in a really spectacular manner. After some wrangling I've discovered that in the newer versions of the CLDR dataset some of the information previously contained in the locale files (such as weekend start/end, etc), is now in located in a supplemental file. While this makes a certain amount of sense (it's tied to territories, not really languages), it does mean that the information needed for a Locale is no longer self-contained in a single XML file. So unfortunately it's going to require some more work to fix up the loader; I'll probably create a branch to work on this some... Has anyone looked at Babel (http://babel.edgewall.org/)? It includes a python interface to CLDR, which if usable would let us off the hook of maintaining such an interface ourselves. I've used Babel for some basic catalog manipulation, but didn't realize it did CLDR, too. I'll take a look at it. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Frustrated with Python and Frameworks. Zope, Grok, , Django, CherryPy
Tres Seaver wrote: Martijn Faassen wrote: Hey, On Nov 28, 2007 12:16 AM, Martijn Jacobs [EMAIL PROTECTED] wrote: We could also consider putting them in some kind of collective-like SVN repository so that people can make changes when they need to. I think this is a great idea as it works with the Plone collective this way as well. Just to make it utterly clear: this stuff won't happen by itself. We need a bunch of self-driven volunteers to do this work: look up the relevant codebases, contact their authors, check them into a SVN if they look orphaned (if they aren't of course don't fork them!) and make an index page describing what is going on. This can be done independently from zope.org, and should later become part of the zope.org website. You will need a SVN repository somewhere. svn.zope.org could be used if you have committer access, but it would be somewhat restricted as GPL-ed products can't be placed in there. Anyway, all these questions I'm thinking of now someone else should take the lead on, as it won't be me. :) For clarity, nobody but a ZC employee (at present) is supposed to be checking in any code with any license other than the ZPL; in the future, such a checkin will need to be approved by some agent / organ of the Zope Foundation. It's actually even more restrictive than that: If I read paragraph 5 of the contributor agreement [1] right, then whoever checks things in must have the intellectual property over the code, otherwise s/he would not be able to donate half of it to ZC. So effectively you can't check in somebody else's code, even if it's covered by the ZPL. [1] http://www.zope.org/DevHome/CVS/Contributor.pdf ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Frustrated with Python and Frameworks. Zope, Grok, , Django, CherryPy
sorry, meant to CC [EMAIL PROTECTED], not zope-dev@zope.org Philipp von Weitershausen wrote: Tres Seaver wrote: Martijn Faassen wrote: Hey, On Nov 28, 2007 12:16 AM, Martijn Jacobs [EMAIL PROTECTED] wrote: We could also consider putting them in some kind of collective-like SVN repository so that people can make changes when they need to. I think this is a great idea as it works with the Plone collective this way as well. Just to make it utterly clear: this stuff won't happen by itself. We need a bunch of self-driven volunteers to do this work: look up the relevant codebases, contact their authors, check them into a SVN if they look orphaned (if they aren't of course don't fork them!) and make an index page describing what is going on. This can be done independently from zope.org, and should later become part of the zope.org website. You will need a SVN repository somewhere. svn.zope.org could be used if you have committer access, but it would be somewhat restricted as GPL-ed products can't be placed in there. Anyway, all these questions I'm thinking of now someone else should take the lead on, as it won't be me. :) For clarity, nobody but a ZC employee (at present) is supposed to be checking in any code with any license other than the ZPL; in the future, such a checkin will need to be approved by some agent / organ of the Zope Foundation. It's actually even more restrictive than that: If I read paragraph 5 of the contributor agreement [1] right, then whoever checks things in must have the intellectual property over the code, otherwise s/he would not be able to donate half of it to ZC. So effectively you can't check in somebody else's code, even if it's covered by the ZPL. [1] http://www.zope.org/DevHome/CVS/Contributor.pdf ___ 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] Re: unregistering components?
Philipp von Weitershausen wrote: zope.app.component.site contains the LocalSiteManager class. This is the persistent component registry used in Zope 3's standard ISites. It inherits from zope.component.persistentregistry.PersistentComponents which in turn inherits from zope.component.registry.Components. The latter has the dynamic __bases__ property. You'll see that the setter really just sets the __bases__ on its internal adapter and utility registry. Both of those (sic!) are some sort of subclass of zope.interface.adapter.BaseAdapterRegistry which has the handling for cascading lookups through its __bases__ property. :) This does all look pretty scary... What code do I need to read to see how to setup a group of registries where a search for adapters/etc gives: - the sum of all the registries (ie: all possible adapters are returned) - the most appropriate adapter is returned (ie: the first registry is searched and if no matching adapter/etc is found, the second registry is searched, etc) If eggs had some decent dependency handling. Surely that's kinda key in any kind of package management system, which eggs surely are? ;-) Why? Because some developers prefer lower traffic lists that focus on solely on development. All three lists together now consitute less than one low volume list from what I can see :-S If it helps, as far as components and registries goes, I'm aiming for something like skin-like stacked registries that can be altered ttw... Sounds wild :) Indeed, I have a nagging feeling the hard work for this has already been done, which is why I'm trying to find otu how to re-use it rather than re-inventing wheels... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: [Checkins] SVN: z3c.jbot/ Initial import.
On Wed, 28 Nov 2007 11:45:10 -0800, Malthe Borch [EMAIL PROTECTED] wrote: -1 to magic or weak dependencies. +1 to test what you fly and fly what you test I agree. In this case it would make sense to have five.jbot. If everyone's in favor, I can split it out like that. It's an interesting situation though because the package in question does not have any code that depends on zope 2 in any way. While we're on a renaming spree here, why jbot? (I know, Just a Bunch of Templates) My associations go to IRC or spam bots immediately. :) -- Alexander Limi · http://limi.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] Re: Frustrated with Python and Frameworks. Zope, Grok, , Django, CherryPy
On Wed, 28 Nov 2007 15:52:01 -0800, Philipp von Weitershausen [EMAIL PROTECTED] wrote: It's actually even more restrictive than that: If I read paragraph 5 of the contributor agreement [1] right, then whoever checks things in must have the intellectual property over the code, otherwise s/he would not be able to donate half of it to ZC. So effectively you can't check in somebody else's code, even if it's covered by the ZPL. That's correct from a legal point of view. Which is why code in the Collective is a separate repository and isn't covered by the contributor agreement in our particular case. -- Alexander Limi · http://limi.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 )
Re: [Zope-dev] Re: AW: [Checkins] SVN: z3c.jbot/ Initial import.
On Wednesday 28 November 2007, Malthe Borch wrote: -1 to magic or weak dependencies. +1 to test what you fly and fly what you test I agree. In this case it would make sense to have five.jbot. If everyone's in favor, I can split it out like that. It's an interesting situation though because the package in question does not have any code that depends on zope 2 in any way. +1 Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 )
