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 )
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
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
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] 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
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] 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] 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 )
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 )
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
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
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
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. fdrake at gmail.com 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] 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 )
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 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. shrug 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)
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 )
[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 )
