Re: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Philipp. I am strongly attached to packages and software that is reusable in and out of zope 3. Explicitly defining configuration using decorators should keep configuration top of mind (which is where I want to keep it when I develop) and not interfere with reuse goals. Further, I don't have to write or format xml at all since all interaction with it would be python. I believe I understand where you are going with Grok development quite well. At the same time, I recognize another approach for dealing with the labor of component registration that could assist the zope 3 developer. Obviously this is not relying on a Grokker for its configuration magic since you need to be explicit, but this is how I wish to keep things. Buildout is a wonderful tool and extending to the class level to write the xml text that zope needs seems natural for me. I use buildout as my setup and configuration automation tool for virtually everything from physical server setup to configuring and building just about all the software I use at the present time. I don't see it as the wrong place to automate this task and to save time. Frankly, there is irony in my configuring software in other languages using buildout but not my own python packages in zope 3 to the level of the class. Regards, David Philipp von Weitershausen wrote: On 8 Oct 2007, at 15:14 , David Pratt wrote: Hi Uwe. I have been thinking of something similar and posted on the list a couple of weeks back: http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html I want the zcml to be generated with a switch on zc.buildout so all configuration is auto generated. Currently site.zcml is done this way and I want to extend this to the class level. Recipe's would be produced to handle different types of configuration by providing the decorator methods. I'm hoping to use decorators exclusively on the classes to do this so there would be no need to modify the code in the classes themselves to accomplish the configuration. Further, classes without this decoration would be skipped by the process allowing this approach to be incorporated into your code gradually. I want to be able to see and verify the zcml produced and have the same control over it that I have now. We were considering the generation of ZCML briefly when developing Grok, but discarded it quickly. The ZCML machinery (zope.configuration) itself is nice, but many of the directive handlers that are out there are flawed. In particular, the browser:page handler is so awful, I'm very very happy not having to use it in Grok. Death to magic class creation! Other handlers have side-effects during parsing time (as opposed to action execution time). Of course, we could've always written our own directives, but that wasn't the exercise. Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. The advantage of having it in buildout is that it becomes integrated into the development of the application, which is by nature just the configuration glue for your packages. I think buildout is entirely the wrong place to do this, but feel free to pursue your own ideas :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: The elevator speech for Zope 3
On 8 Oct 2007, at 15:52 , Roger Ineichen wrote: Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a "use it all or nothing concept"? Currently Grok has tendencies of an "all-or-nothing" approach, but we're working on separating it to different packages. In the future, if you just want to register adapters and utilities using the Grok way, but don't want Grok's security policy or publication, you won't have to load all of Grok. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Philipp > Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] > Soon, we will change Grok so that it emits configuration > actions, rather than doing the registrations right away. That > way, you will still be able to inspect what exactly Grok is > doing (for example by dumping all configuration actions > before or instead of executing them), but you won't have to > deal with ZCML anymore. You will also be able to use the > overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a "use it all or nothing concept"? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The elevator speech for Zope 3
On 8 Oct 2007, at 15:14 , David Pratt wrote: Hi Uwe. I have been thinking of something similar and posted on the list a couple of weeks back: http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html I want the zcml to be generated with a switch on zc.buildout so all configuration is auto generated. Currently site.zcml is done this way and I want to extend this to the class level. Recipe's would be produced to handle different types of configuration by providing the decorator methods. I'm hoping to use decorators exclusively on the classes to do this so there would be no need to modify the code in the classes themselves to accomplish the configuration. Further, classes without this decoration would be skipped by the process allowing this approach to be incorporated into your code gradually. I want to be able to see and verify the zcml produced and have the same control over it that I have now. We were considering the generation of ZCML briefly when developing Grok, but discarded it quickly. The ZCML machinery (zope.configuration) itself is nice, but many of the directive handlers that are out there are flawed. In particular, the browser:page handler is so awful, I'm very very happy not having to use it in Grok. Death to magic class creation! Other handlers have side-effects during parsing time (as opposed to action execution time). Of course, we could've always written our own directives, but that wasn't the exercise. Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. The advantage of having it in buildout is that it becomes integrated into the development of the application, which is by nature just the configuration glue for your packages. I think buildout is entirely the wrong place to do this, but feel free to pursue your own ideas :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Uwe. I have been thinking of something similar and posted on the list a couple of weeks back: http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html I want the zcml to be generated with a switch on zc.buildout so all configuration is auto generated. Currently site.zcml is done this way and I want to extend this to the class level. Recipe's would be produced to handle different types of configuration by providing the decorator methods. I'm hoping to use decorators exclusively on the classes to do this so there would be no need to modify the code in the classes themselves to accomplish the configuration. Further, classes without this decoration would be skipped by the process allowing this approach to be incorporated into your code gradually. I want to be able to see and verify the zcml produced and have the same control over it that I have now. The advantage of having it in buildout is that it becomes integrated into the development of the application, which is by nature just the configuration glue for your packages. Uwe, is there a chance your package can be zpl'd since I believe bebop is gpl and this is fairly low level code that could be a great plus for general z3 development. At the very least I'd like a zpl'd package to handle configuration this way or to borrow from your efforts to move forward with this idea. Regards, David Uwe Oestermeier wrote: Oliver Marx <[EMAIL PROTECTED]> writes: I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. Have a look at bebop.protocol in PyPI. It's still a preminary version but it does exactly what you want. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The elevator speech for Zope 3
Oliver Marx <[EMAIL PROTECTED]> writes: >I have looked at Grok. I love the ideas. But it feels like its a little >too much convention over configuration. I do not hate zcml. I hate to >write zcml. If there was a way to auto generate zcml and way to >overwrite that zcml when needed - then I would be a happy man. Have a look at bebop.protocol in PyPI. It's still a preminary version but it does exactly what you want. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
On 8 Oct 2007, at 13:30 , Oliver Marx wrote: Yup. Now let's drop the "3" in that sentence, because all of this applies to Zope software as a whole. This is, in fact, one way to sum up the way the Zope project as a whole works. I have no problem with that. The simpler the better. As long as the new comers learn Zope 3 and not Zope 2. That's the idea. http://cheeseshop.python.org/pypi/zopeproject is probably the fastest and easiest way to get started nowadays. One command and you're set up with a sandbox. If you haven't got Zope 3 downloaded yet, it will do so as well. It selects a set of libraries that are common in most applications and installs them by default. You can, of course, get rid of them later on. I will have to look at zopeproject. Without having looked at it - My guess is that I would like a little more flesh on the bones - like z3c.form(demo). Remember it is for people who are *new* to Zope. I would love to see a set of extjs widgets as well. It's always an act of balance figuring out how much boilerplate we give to the users and how much we don't. zopeproject is a tool for getting started with *your* application, not a demo app. If somebody wants to go and build demo sites with Zope 3, then I'd welcome such an effort. It's just not what zopeproject is about. By the way, there are a number of demo Grok apps in the repository: http://svn.zope.org/grokapps/. Another one is here: http:// codespeak.net/svn/z3/NudgeNudge/trunk/ Then of course there's Grok (http://grok.zope.org) which builds on the Zope Libraries and aims at making it all much easier. It too has a "click clack install" along the lines of zopeproject; it's called grokproject. And a while ago, I demonstrated how you could create a TodoList application in 15 minutes with it: http:// www.archive.org/details/grok_todo_part1. Note that Grok has evolved a bit since then and adding any kind of ZCML or working with the ZMI is unnecessary nowadays. I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. I realize that Grok's message is currently a bit misunderstanding. With Grok, you can spell out everything that you spell out in ZCML. Every little detail. But: if you adhere to some conventions, you can save yourself some typing. You don't have to adhere to those conventions at all. But in that case you'll have to do the typing again. The typing is, of course, much nicer than ZCML, because it's in Python and frankly, it's much more coherent than ZCML, easier to remember and it prevents context-switching. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
Yup. Now let's drop the "3" in that sentence, because all of this applies to Zope software as a whole. This is, in fact, one way to sum up the way the Zope project as a whole works. I have no problem with that. The simpler the better. As long as the new comers learn Zope 3 and not Zope 2. Maybe we can learn from the javascript libraries? The first time you pick the whole package. Later when you have become more familiar with the library you only include the parts that you really need. But that is not how you start! Absolutely. Zope 3 should IMO have a "click clack install" version that makes the first little app a piece of cake. Add to that a story about flexibility and automated testing; then even I would buy it ;) http://cheeseshop.python.org/pypi/zopeproject is probably the fastest and easiest way to get started nowadays. One command and you're set up with a sandbox. If you haven't got Zope 3 downloaded yet, it will do so as well. It selects a set of libraries that are common in most applications and installs them by default. You can, of course, get rid of them later on. I will have to look at zopeproject. Without having looked at it - My guess is that I would like a little more flesh on the bones - like z3c.form(demo). Remember it is for people who are *new* to Zope. I would love to see a set of extjs widgets as well. Then of course there's Grok (http://grok.zope.org) which builds on the Zope Libraries and aims at making it all much easier. It too has a "click clack install" along the lines of zopeproject; it's called grokproject. And a while ago, I demonstrated how you could create a TodoList application in 15 minutes with it: http://www.archive.org/details/grok_todo_part1. Note that Grok has evolved a bit since then and adding any kind of ZCML or working with the ZMI is unnecessary nowadays. I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. /Oliver ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
Stephan Richter wrote: On Sunday 07 October 2007 21:55, Oliver Marx wrote: Zope 3 should IMO have a "click clack install" version that makes the first little app a piece of cake. Add to that a story about flexibility and automated testing; then even I would buy it ;) I agree, with the "click, clack, install" part. In the past we tried to accomplish this by trying to show how a blog or wiki can be done in 30 minutes. But I think that z3c.formdemo was well-received. So maybe we should have many more of those demo packages that you can simply build and run. Later we can then combine the demo packages into a Web site. Zope 3 technology does have a "click clack install, read tutorial, can see 'hello world' in a few minutes" story: Grok. Grok also has a web site already: grok.zope.org. We've been doing this stuff for a year now. With Grok it's actually a core activity to worry about this kind of stuff, more so than I've experienced the Zope 3 technology developers to do. Perhaps there are other explanations for why Zope 3 is lagging a year behind? Hopefully it will finally change. Elsewhere I made the suggestion, following Roger Ineichen's suggestions, to form a separate group, similar to Grok's, that focuses on these issues for those who want to continue use Zope 3 technology the traditional way. I realize that this sounds annoying: why do I keep mentioning Grok as an example in this? Isn't Grok completely irrelevant to all this? It's not irrelevant, as it's working example of what you'd like to accomplish with Zope 3. You might take useful lessons from our approaches in building a community around such an effort. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
Oliver Marx wrote: Here is what I told my mother: Zope 3 is a web development technology that focuses on code reuse, automated testing and security. - Code reuse: we can do more in less time. - Automated testing: Code reuse makes it a much have. - And with automated testing we can actually prove that we implemented the security model we have agreed with our customers to use. Yup. Now let's drop the "3" in that sentence, because all of this applies to Zope software as a whole. This is, in fact, one way to sum up the way the Zope project as a whole works. What I told my mother is much much less important than what I didn't tell her. I did not use words like library, server, python, zodb, sql etc. Who are the people in the audience? Business people -> yes Non-programmers (but still IT) -> maybe Programmers (non-python) -> more often that not Programmers (python) -> yes Zope 3 core developers -> never - already customers Zope 2 programmers -> yes The audience consist of people who will never (or at least very seldom) become contributers to the Zope 3 stack!? Maybe we can learn from the javascript libraries? The first time you pick the whole package. Later when you have become more familiar with the library you only include the parts that you really need. But that is not how you start! Absolutely. Zope 3 should IMO have a "click clack install" version that makes the first little app a piece of cake. Add to that a story about flexibility and automated testing; then even I would buy it ;) http://cheeseshop.python.org/pypi/zopeproject is probably the fastest and easiest way to get started nowadays. One command and you're set up with a sandbox. If you haven't got Zope 3 downloaded yet, it will do so as well. It selects a set of libraries that are common in most applications and installs them by default. You can, of course, get rid of them later on. Then of course there's Grok (http://grok.zope.org) which builds on the Zope Libraries and aims at making it all much easier. It too has a "click clack install" along the lines of zopeproject; it's called grokproject. And a while ago, I demonstrated how you could create a TodoList application in 15 minutes with it: http://www.archive.org/details/grok_todo_part1. Note that Grok has evolved a bit since then and adding any kind of ZCML or working with the ZMI is unnecessary nowadays. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
