Re: [Zope3-dev] Re: The elevator speech for Zope 3

2007-10-08 Thread David Pratt
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

2007-10-08 Thread Philipp von Weitershausen

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

2007-10-08 Thread Roger Ineichen
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

2007-10-08 Thread Philipp von Weitershausen

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

2007-10-08 Thread David Pratt
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

2007-10-08 Thread Uwe Oestermeier
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

2007-10-08 Thread Philipp von Weitershausen

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

2007-10-08 Thread Oliver Marx




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

2007-10-08 Thread Martijn Faassen

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

2007-10-08 Thread Philipp von Weitershausen

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