[Zope-dev] Call for translating z3c.form
Hello, fellow users and developers of zope components! I just added support for i18n in z3c.form, so it can be now translated to many languages. If you want to contribute to z3c.form internationalization, checkout the z3c.form.pot file from the z3c.form's trunk and translate it to your language, then send back to me or commit to the repo, if you are a committer. Thanks! -- 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] Test Runner (was Re: Dependencies and future of zope 3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Sep 3, 2008, at 8:37 PM, Tres Seaver wrote: >> The change under discussion about testing is whether or not to remove >> the test requirements as part of 'install_requires' in setup.py. Some >> folks have objecctions to using the setuptools-provided >> 'tests_require' >> field, although I think the argument there is weak: packages which >> spell 'tests_require' and 'test_suite' in their setup can be tested >> trivially with 'python setup.py test', which seems a win to me. > > I agree that this is a win. It is not a big win IMO, as I prefer a > separate test runner. > > It would be far more useful to me if the data were captured as part of > egg info. > >> I'm not volunteering to write it, but it strikes me as odd that folks >> haven't morphed zc.buildout (and / or associated recipes) to use this >> field. I *did* write a setuptools add on which saved the >> 'tests_require' info into the EGG_INFO directory: that package >> could be >> used to capture the metadata during installation of packages, for >> consumption by a testrunner later. > > That's very good. It would be much much much better if setuptools > would do this by default. Now that setuptools' development is opening > up, perhaps we can do this. 'egginfo' uses the established "setuptools plugin" API: I don't have commit access, but I would be fine with having it merged. In the meantime, including it within 'zc.buildout' environments would make the information widely available. > The setuptools add-on doesn't help when you don't have source releases > and many interesting packages get distributed as eggs on Windows. 'egginfo' includes the test info in bdist_egg zipfiles if it is present on the system where the egg is built. >> I discovered today I think the time is ripe for a "blank buffer" >> rewrite >> of the testrunner: it is so full of "twisty passages" that my >> confidence in its own internal correctness is seriously depleted. It >> has too many features, > > I doubt it. I find the vast majority of it's features very useful. I > agree that the test discovery is ripe for a revamp. Can you truly say that reading the code doesn't make your eyes cross? Here are a couple I noted while debugging broken discovery yesterday: - Extensive use of generators, in spite of the fact that we always consume them all. It feels like a "here's a new language feature, let's use it" choice, and makes debugging the code harder. I doubt very much that the decision was driven by an actual constraint (the only one I can imagine is RAM consumption). - '--path' vs '--test-path' vs. '--package-path' interact in unpredictable ways, based on ordering. >> and too many incompatible ways to run it: I >> would love a simpler version, whose discovery logic used egg metadata >> instead of (mal)heuristics (e.g., ordering of '--test-path' and >> '--package-path' arguments can make some tests unfindable). > > I'm very open to revamping test discovery. > > I'm opposed to a rewrite. I sure as heck wouldn't be willing to spend > time on a rewrite. I wouldn't be opposed to replacing out test runner > with a bunch of nose plugins that added missing features. I have > almost zero interest in using setuptools test runner during development. I typically use 'setup.py test' in two cases: - When evaluating a new package, I create a virtualenv and run 'setup.py develop' and 'setup.py test' using the virtualenv's python. Packages whose tests run clealy in a sandbox get a higher "score" than those which don't: for one thing, it guarantees that their dependencies are accurate. - When building packages which I hope will be used outsize of Zopeland, I want to make the tests accessible to folks who don't use zc.buildout or zope.testing. I tend to skip running 'setup.py test' only in projects where I am writing custom software, and where the project is already committed to another testrunner. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv/4u+gerLs4ltQ4RAp+8AJ9iTagUjGOdkgYGIA7xGqeyFu6X/wCcD74d 6LZrrCg9OsDb8+FYHG2rVmM= =d2kX -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] Test Runner (was Re: Dependencies and future of zope 3)
On Thu, 2008-09-04 at 16:33 +0200, Martijn Faassen wrote: > Note also that Christian Theune also started a major > cleanup/reorganization of the testrunner some months ago. Christian > can tell you more about the status and future plans for further > cleanups. The code became more readable in many places so the test runner became easier to change. The test discovery is one of the remaining really dirty places in there and I'd be happy to see this improved. I'd also be happy to help with this. -- Christian Theune · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
On Sep 4, 2008, at 10:55 AM, Martijn Faassen wrote: > Hey, > > On Thu, Sep 4, 2008 at 4:52 PM, Jim Fulton <[EMAIL PROTECTED]> wrote: >> On Sep 4, 2008, at 8:49 AM, Fred Drake wrote: >> >>> On Thu, Sep 4, 2008 at 8:16 AM, Martijn Faassen <[EMAIL PROTECTED] >>> > >>> wrote: Does the hidden status explain it not being picked up by buildout? Anyway, sorry for getting confused there. >>> >>> No; the "hidden" bit only affects the normal PyPI user interface. >> >> No, it also affects buildout if you use the PyPI user interface as >> your >> index, which is why you should use http://pypi.python.org/simple/, >> or one of >> its mirrors as your index. > > I thought buildout used the simple version by default? I'm using > buildout 1.0 and this was introduced in a beta (b29). It does, but it lets you specify a different index. I assumed you were using an old index. Jim -- Jim Fulton 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 )
Re: [Zope-dev] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
Hey, On Thu, Sep 4, 2008 at 4:52 PM, Jim Fulton <[EMAIL PROTECTED]> wrote: > On Sep 4, 2008, at 8:49 AM, Fred Drake wrote: > >> On Thu, Sep 4, 2008 at 8:16 AM, Martijn Faassen <[EMAIL PROTECTED]> >> wrote: >>> >>> Does the hidden status explain it not being picked up by buildout? >>> Anyway, sorry for getting confused there. >> >> No; the "hidden" bit only affects the normal PyPI user interface. > > No, it also affects buildout if you use the PyPI user interface as your > index, which is why you should use http://pypi.python.org/simple/, or one of > its mirrors as your index. I thought buildout used the simple version by default? I'm using buildout 1.0 and this was introduced in a beta (b29). 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] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
On Sep 4, 2008, at 8:49 AM, Fred Drake wrote: > On Thu, Sep 4, 2008 at 8:16 AM, Martijn Faassen <[EMAIL PROTECTED] > > wrote: >> Does the hidden status explain it not being picked up by buildout? >> Anyway, sorry for getting confused there. > > No; the "hidden" bit only affects the normal PyPI user interface. No, it also affects buildout if you use the PyPI user interface as your index, which is why you should use http://pypi.python.org/ simple/, or one of its mirrors as your index. Jim -- Jim Fulton 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 )
Re: [Zope-dev] Test Runner (was Re: Dependencies and future of zope 3)
Hi there, On Thu, Sep 4, 2008 at 4:29 PM, Jim Fulton <[EMAIL PROTECTED]> wrote: [snip] >> I discovered today I think the time is ripe for a "blank buffer" rewrite >> of the testrunner: it is so full of "twisty passages" that my >> confidence in its own internal correctness is seriously depleted. It >> has too many features, > > I doubt it. I find the vast majority of it's features very useful. I agree > that the test discovery is ripe for a revamp. Note also that Christian Theune also started a major cleanup/reorganization of the testrunner some months ago. Christian can tell you more about the status and future plans for further cleanups. 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] Test Runner (was Re: Dependencies and future of zope 3)
On Sep 3, 2008, at 8:37 PM, Tres Seaver wrote: > The change under discussion about testing is whether or not to remove > the test requirements as part of 'install_requires' in setup.py. Some > folks have objecctions to using the setuptools-provided > 'tests_require' > field, although I think the argument there is weak: packages which > spell 'tests_require' and 'test_suite' in their setup can be tested > trivially with 'python setup.py test', which seems a win to me. I agree that this is a win. It is not a big win IMO, as I prefer a separate test runner. It would be far more useful to me if the data were captured as part of egg info. > I'm not volunteering to write it, but it strikes me as odd that folks > haven't morphed zc.buildout (and / or associated recipes) to use this > field. I *did* write a setuptools add on which saved the > 'tests_require' info into the EGG_INFO directory: that package > could be > used to capture the metadata during installation of packages, for > consumption by a testrunner later. That's very good. It would be much much much better if setuptools would do this by default. Now that setuptools' development is opening up, perhaps we can do this. The setuptools add-on doesn't help when you don't have source releases and many interesting packages get distributed as eggs on Windows. > I discovered today I think the time is ripe for a "blank buffer" > rewrite > of the testrunner: it is so full of "twisty passages" that my > confidence in its own internal correctness is seriously depleted. It > has too many features, I doubt it. I find the vast majority of it's features very useful. I agree that the test discovery is ripe for a revamp. > and too many incompatible ways to run it: I > would love a simpler version, whose discovery logic used egg metadata > instead of (mal)heuristics (e.g., ordering of '--test-path' and > '--package-path' arguments can make some tests unfindable). I'm very open to revamping test discovery. I'm opposed to a rewrite. I sure as heck wouldn't be willing to spend time on a rewrite. I wouldn't be opposed to replacing out test runner with a bunch of nose plugins that added missing features. I have almost zero interest in using setuptools test runner during development. Jim -- Jim Fulton 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 )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Am Donnerstag 04 September 2008 12:49:17 schrieb Martijn Faassen: > Hermann Himmelbauer wrote: > [snip] > > > - The real reason I need the interfaces is that I have to include them in > > my configure.zcml in order to make the underlying objects read/writeable. > > But this is in my case only annoying, but not helpful at all. > > Ah, interesting! This is a problem that doesn't exist in Grok, as we > turn off model-based security checks. (views still make them, and > permissions can still be model based. just no automatic checks when you > access a method or attribute) Yes, the problem is that for a ZODB I'd say that an owner of an object may alter it's data. For instance, a user has a "person" object and may alter his name, address but he must not alter other person objects. When using a RDB, all persons are in a table and I have a Person object, which represents a row of this table, however, I cannot outline who owns the person, therefore I have to allow access to person objects for all users. Therefore I have to do security at another level, e.g. the view and not at the model. Nevertheless I assume there will somehow be a magic command that I can issue for the RDB-based classes (probably there's some counterpart to the ZCML "class" directive). Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
On Thu, Sep 4, 2008 at 8:16 AM, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Does the hidden status explain it not being picked up by buildout? > Anyway, sorry for getting confused there. No; the "hidden" bit only affects the normal PyPI user interface. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
Hi there, On Thu, Sep 4, 2008 at 1:42 PM, Andreas Jung <[EMAIL PROTECTED]> wrote: [snip] > zope.testing 3.6.0 was marked as hidden on PyPI. It's now visible again - > together with 3.5.6. Does the hidden status explain it not being picked up by buildout? Anyway, sorry for getting confused there. 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] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
Andreas Jung wrote: > --On 4. September 2008 13:38:27 +0200 Martijn Faassen > <[EMAIL PROTECTED]> wrote: > >> There appears to be a release of zc.recipe.testrunner 1.1.0 which >> requires zope.testing 3.6.0, but zope.testing 3.6.0 was not released as >> far as I can see. This means zc.recipe.testrunner 1.1.0 cannot be >> installed. > > zope.testing 3.6.0 was marked as hidden on PyPI. It's now visible again > - together with 3.5.6. Which will be hidden again once the next release is made. That's why http://pypi.python.org/simple/zope.testing is the only sensible place to look for releases. The normal PyPi interface is only useful for discovering packages and reading their documentation. 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] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
Martijn Faassen wrote: > There appears to be a release of zc.recipe.testrunner 1.1.0 which > requires zope.testing 3.6.0, but zope.testing 3.6.0 was not released as > far as I can see. This means zc.recipe.testrunner 1.1.0 cannot be installed. http://pypi.python.org/pypi/zope.testing/3.6.0 This looks quite released and fine to me, no? It's probably not the default for 'zope.testing' anymore, since someone released 3.5.6 after 3.6.0 and that automatically hides every other release. 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] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
--On 4. September 2008 13:38:27 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote: Hi there, There appears to be a release of zc.recipe.testrunner 1.1.0 which requires zope.testing 3.6.0, but zope.testing 3.6.0 was not released as far as I can see. This means zc.recipe.testrunner 1.1.0 cannot be installed. zope.testing 3.6.0 was marked as hidden on PyPI. It's now visible again - together with 3.5.6. Andreas pgpCkZWLLvn2R.pgp Description: 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] zc.recipe.testrunner 1.1.0 requires zope.testing 3.6.0, but not released
Hi there, There appears to be a release of zc.recipe.testrunner 1.1.0 which requires zope.testing 3.6.0, but zope.testing 3.6.0 was not released as far as I can see. This means zc.recipe.testrunner 1.1.0 cannot be installed. 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] Dependencies and future of zope 3
Hi Martijn > Betreff: Re: [Zope-dev] Dependencies and future of zope 3 > > Roger Ineichen wrote: > [snip] > > Most packages which are interesting for reuse provide more or less > > only ZMI related views. > > > > What about zope.zmi if they provide views for the ZMI. This > views are > > allmost unuseable outside the ZMI (know as Rotterdam skin) > > Why not simply leave the ZMI stuff in zope.app.* for now? It > means less to move around, so more likely it'll get done and > less chance it'll break. I.e. the eventual goal would be that > the zope.app.* packages > *only* contain the remaining ZMI stuff. I can absolutly agree on that. 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 )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Wed Sep 3 11:00:00 2008 UTC to Thu Sep 4 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Sep 3 20:52:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010110.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 3 20:53:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010111.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 3 20:55:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010112.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 3 20:56:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010113.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 3 20:58:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010114.html ___ 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] Idea: Create SQL-Alchemy tables via interfaces
Hermann Himmelbauer wrote: [snip] > - The real reason I need the interfaces is that I have to include them in my > configure.zcml in order to make the underlying objects read/writeable. But > this is in my case only annoying, but not helpful at all. Ah, interesting! This is a problem that doesn't exist in Grok, as we turn off model-based security checks. (views still make them, and permissions can still be model based. just no automatic checks when you access a method or attribute) 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] Idea: Create SQL-Alchemy tables via interfaces
Hermann Himmelbauer wrote: [snip] > Although ZODB may not be useable for a specific case, why not use a > Zope3-style design process? So I'd start out with interfaces that describe my > content objects, then I'd model relations, with interfaces too. And when I'm > done, I'd derive the SQLAlchemy tables from that. I'm not the biggest fan in the world of the described design process. That is, I often design by writing concrete classes, refactoring several cycles, and only writing the interfaces when they become clear. If I want to use a relational database I'll do my data modeling on that level, as when I choose a relational database I think that's the best way to obtain the benefits. I do like the SQLAlchemy table definition system in Python, but it's still relational. > But, you know, that's theory, you may be right that this approach is not > possible. I'm not saying not possible. I just think it's harder than the other way around. That said, I'd be interested to see you give it a try. 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] Dependencies and future of zope 3
Hi there, Roger Ineichen wrote: [snip] > We have different kind of refactorings which all solve some > problems. I think we should not start with the browser views. > There are some core dependencies we need to cleanup first. > > Right now I'm working forward with small refactorings > which solve some dependencies to zope.app.form (ITerms) and > zope.app.authentication (IPaswordManager). I think most of our progress will be by incremental step-by-step refactoring, so I'm glad to hear you're working on this. 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] Dependencies and future of zope 3
Roger Ineichen wrote: [snip] > Most packages which are interesting for reuse > provide more or less only ZMI related views. > > What about zope.zmi if they provide views for > the ZMI. This views are allmost unuseable > outside the ZMI (know as Rotterdam skin) Why not simply leave the ZMI stuff in zope.app.* for now? It means less to move around, so more likely it'll get done and less chance it'll break. I.e. the eventual goal would be that the zope.app.* packages *only* contain the remaining ZMI stuff. 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] Dependencies and future of zope 3
Hi there, On Wed, Sep 3, 2008 at 7:55 PM, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Benji York wrote: [snip] >> Maybe we should create a new namespace package for "browser" code. >> >> How about "zope.browser"? > > My general sentiment is against creating more structure than we already > have. Flat is better than nested. IMHO it's perfectly ok to have the Python > APIs in zope.foo and browser code in zope.app.foo. I think sooner than later > people won't want to the zope.app.* stuff anyway. Yeah, I'm leaning towards this approach as well. It's less to move around. We should not be afraid to move stuff from zope.app.* into zope.* though if it's clear it's "browser-related" but still not a UI. Say, absolute URL generation. Otherwise we'll never get rid of some of the zope.app.* stuff. 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] Dependencies and future of zope 3
Hey, On Wed, Sep 3, 2008 at 5:41 PM, Stephan Richter <[EMAIL PROTECTED]> wrote: [snip] > Jim must have read your message with a big smile on his face. He was arguing > for this approach of flat package names about 2-3 years ago and I shot that > proposal down. I hate when I only realize design mistakes years after Jim > does. ;-\ I only get the idea a few years after Jim gets them. I don't know what's better. :) > For several packages we took the following approach. Most packages that have > browser packages are in zope.app; for example, zope.app.folder (we did not > convert this package yet). We then took the API and moved it to zope.folder. > We imported the API in zope.app.folder again to maintain BBB. This way > zope.folder has the minimal deps and zope.app.folder contains the browser > code. I guess that's indeed a reasonable way to move forward. The idea would be that we can move forward on the zope.* package and probably retire some of the zope.app.* packages eventually. > BTW, zope.app.form is a big exception. Agreed. Just wanted to mention the exception too. There are some other publisher related packages that also have significant not-really-UI stuff in .browser. 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] Idea: Create SQL-Alchemy tables via interfaces
Am Donnerstag 04 September 2008 09:10:22 schrieb Brian Sutherland: > On Wed, Sep 03, 2008 at 05:18:50PM +0200, Hermann Himmelbauer wrote: > > Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland: > > > On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: > > > > Hi, > > > > In my current SQLAlchemy / Zope-based design, I need the following: > > > > > > > > - SQLAlchemy table definitions > > > > - classes + mappers > > > > - Zope interfaces > > > > > > > > The problem with this design is that much data has to be defined > > > > twice, e.g. the datatype "varchar(50)" should be represented by an > > > > interface with TextLine(max_length="50"). Moreover, any changes such > > > > as adding columns etc. also have to be done in the interface and the > > > > table definition. > > > > > > > > To overcome this, I just had the idea to use the interface/schema > > > > definitions for the table definition itself. Probably I'm not the > > > > first who had this idea, but I'm not aware of such an extension to > > > > interfaces. > > > > > > > > Any thoughts on this? > > > > > > I'm much more in favour of the reverse procedure. I think the database > > > is the canonical store of this information and that SQLAlchemy should > > > read that and make it available for doing form validation. > > > > But isn't exactly that the real meaning of interfaces? > > So I have the impression that at the beginning of the design process, I'd > > model the interfaces, which describe and express everything I expect from > > the underlying objects. > > > > And when that is done, I'd program the underlying objects. And for > > content objects, the storage could be in an RDB (SQLAlchemy), or > > somewhere else. And for that, the table structure could be derived from > > the interface. > > Trying to derive an RDB table structure from an object model's design > has nearly always left me with badly designed and/or badly performing > database tables. > > Every time, it's paid me to design the database structure to be > application independent. Basically assume that your application will > never be the only application using the database. Many projects have a > way of sprawling and having a database usable by non-application code is > a big advantage. But wouldn't the database still be application independent this way? The only difference seems to be that I'd define the database structure in the interface. And zope.interface is a package that can easily be included in a non-zope.app related application. > So, given that I believe the above, trying to use the application to > create an application independent database schema is the wrong way > around. To be honest, I personally also always went the RDB -> Zope way, either because the database already existed, or for some other reasons. Therefore I don't really had such negative experiences, but I expect that there will problems if one has an object-only design and tries to stuff these objects in the database later on. Thanks for you comments; I'm curious if other people see that issue the same way. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] Dependencies and future of zope 3
Stephan Richter wrote: > On Wednesday 03 September 2008, David Pratt wrote: >> I am trying to avoid the need for selective forking that Chris has found >> necessary to make progress with bfg. I want to continue using zope since >> these things are a big factor for the factors I stated. > > I do not think that this community is so hard headed that forking is > necessary. As far as I remember, I have not seen any serious commitment on > their side. Many of us are interested in decreasing the dependency tree, so > solutions will be found. It is just so much easier to fork. I'm not sure what "committment" and "their side" implies here, but it's probably a good idea to explain what "selective fork" refers to in this context. The package that David referred to as a fork (because I mentioned to him offhand that it was) was "repoze.catalog" (http://static.repoze.org/catalogdocs/). This is a package that is modeled on zope.app.catalog, but which relies on only zope.index. In reality, it's maybe less of a fork than it is a reaction to a divergence of goals. There's no way I could have gotten what I needed *without* abandoning any hope of pushing the changes up to zope.app.catalog because it's likely that nobody but me cares about the use case: zope.app.catalog relies on "the world" because it wants to hook in tightly with Zope containers, local site managers, object events and so on. I didn't want any of that; I just wanted something that I could hand some text and a docid and have the results queryable later, making the responsibility of the catalog to later only hand me back a set of docids based on the query parameters. It'd be absurd to pull down more than zope.index and ZODB for this purpose, which is exactly what the repoze.catalog package relies on. Sometimes such divergences are just necessary. Take for example, Zope 3, which was a "fork" of Zope 2 in basically the same way that repoze.catalog is a fork of zope.app.catalog. You might argue that it should have retained the "Zope" brand (it hasn't). But then again, it's is not really any more a fork than, say, z3c.form is of zope.formlib, and neither does that. You could also maybe argue that it should live in the Zope SVN repository (it doesn't). But then again, neither does Plone or hundreds of other derivative projects. If we unhose the dependency tree a bit, we might be able to avoid "silly" forks of things, but we'll never be able to mend the divergence of goals and natural progress. I'm not terribly optimistic that the existing community has the will or the time to do the necessary unhosing under the "Zope" flag; it will be extremely painful and time-consuming, and a lot of it will imply similar "forks" which will also need to be maintained even while the old code lives on. These forks won't be in the interest of folks who just want to use Zope 2 and Zope 3 wholesale, which appears to be a solid majority right now given the reluctance to make changes to existing packages. - C ___ 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] Idea: Create SQL-Alchemy tables via interfaces
On Wed, Sep 03, 2008 at 05:18:50PM +0200, Hermann Himmelbauer wrote: > Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland: > > On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: > > > Hi, > > > In my current SQLAlchemy / Zope-based design, I need the following: > > > > > > - SQLAlchemy table definitions > > > - classes + mappers > > > - Zope interfaces > > > > > > The problem with this design is that much data has to be defined twice, > > > e.g. the datatype "varchar(50)" should be represented by an interface > > > with TextLine(max_length="50"). Moreover, any changes such as adding > > > columns etc. also have to be done in the interface and the table > > > definition. > > > > > > To overcome this, I just had the idea to use the interface/schema > > > definitions for the table definition itself. Probably I'm not the first > > > who had this idea, but I'm not aware of such an extension to interfaces. > > > > > > Any thoughts on this? > > > > I'm much more in favour of the reverse procedure. I think the database > > is the canonical store of this information and that SQLAlchemy should > > read that and make it available for doing form validation. > > But isn't exactly that the real meaning of interfaces? > So I have the impression that at the beginning of the design process, I'd > model the interfaces, which describe and express everything I expect from the > underlying objects. > > And when that is done, I'd program the underlying objects. And for content > objects, the storage could be in an RDB (SQLAlchemy), or somewhere else. And > for that, the table structure could be derived from the interface. Trying to derive an RDB table structure from an object model's design has nearly always left me with badly designed and/or badly performing database tables. Every time, it's paid me to design the database structure to be application independent. Basically assume that your application will never be the only application using the database. Many projects have a way of sprawling and having a database usable by non-application code is a big advantage. So, given that I believe the above, trying to use the application to create an application independent database schema is the wrong way around. > If I model it the other way round, the power of interfaces is somehow > crippled: > > - The tables can already be documented in the table declaration itself, so > the > interfaces are only useful for extra documentation, such as mapper properties > and class properties. > - The interface values are of mediocre value for forms, too, as the forms > will often need a change of the schema. (E.g. think of an add person form, > where the name is required and in comparison a search form, where the name > may not be required and thus the name-schema cannot be 1:1 used, or, even > simpler, think of a change of the title). I currently either copy the schemas > into my form, or even write separate interfaces. > - The real reason I need the interfaces is that I have to include them in my > configure.zcml in order to make the underlying objects read/writeable. But > this is in my case only annoying, but not helpful at all. > > Best Regards, > Hermann > > -- > [EMAIL PROTECTED] > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > -- 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 )
