[Zope3-dev] The elevator speech for Zope 3

[Oliver Marx]

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.

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!

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 ;)

/Oliver

[Stephan Richter]

Post by Oliver Marx
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.

Regards,
Stephan

[Martijn Faassen]

Post by Stephan Richter

Post by Oliver Marx
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

[Philipp von Weitershausen]

Post by Oliver Marx
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.

Post by Oliver Marx
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.

Post by Oliver Marx
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.

[Oliver Marx]

Post by Philipp von Weitershausen
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.

Post by Philipp von Weitershausen

Post by Oliver Marx
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.

Post by Oliver Marx
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.

Post by Philipp von Weitershausen
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
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

[Philipp von Weitershausen]

Post by Oliver Marx

Post by Philipp von Weitershausen
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.

Post by Oliver Marx

Post by Philipp von Weitershausen
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/

Post by Oliver Marx

Post by Philipp von Weitershausen
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.

[Uwe Oestermeier]

Post by Oliver Marx
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
***@iwm-kmrc.de
Tel. [phone]
Fax [phone]

[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

Post by Uwe Oestermeier

Post by Oliver Marx
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
Tel. [phone]
Fax [phone]
_______________________________________________
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca

[Philipp von Weitershausen]

Post by David Pratt
Hi Uwe. I have been thinking of something similar and posted on the
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.

Post by David Pratt
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 :).

[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

[Martijn Faassen]

Post by 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"?

Grok *aims* to support reusing bits of it. It hasn't reached this goal
yet as we focused on making it work first, but has been an explicit
seocndary goal from the beginning last year.

We need to do some things to make this possible:

* Done: Grok's mechanism of scanning for classes and instances in
modules and issuing some form of configuration has been factored out
into the martian library.

* as Philipp mentioned, emit configuration actions instead of component
registrations directly. This is underway, started at the sprint last
week by Godefroid Chapelle.

* split up Grok into separate components that are independently
reusable, without having to pull in the whole of Grok to use this.
Philipp wanted to start this work but I'm not sure about its status.

* related to this, Grok turns off some of Zope 3's security
infrastructure (for content objects, not for views). The Grok core
should continue doing this for the forseeable future, but of course if
you want to reuse other bits of Grok standalone this shouldn't come along.

So, this is slowly but surely coming nearer. We want Grok to be a
unified story for most users, so this is not our *primary* goal, but we
do want Grok's work to be reusable in other Zope 3 projects as well.

Regards,

Martijn

[Roger Ineichen]

Hi Martijn

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

[...]

Grok *aims* to support reusing bits of it. It hasn't reached
this goal yet as we focused on making it work first, but has
been an explicit seocndary goal from the beginning last year.
* Done: Grok's mechanism of scanning for classes and
instances in modules and issuing some form of configuration
has been factored out into the martian library.
* as Philipp mentioned, emit configuration actions instead of
component registrations directly. This is underway, started
at the sprint last week by Godefroid Chapelle.
* split up Grok into separate components that are
independently reusable, without having to pull in the whole
of Grok to use this.
Philipp wanted to start this work but I'm not sure about its status.
* related to this, Grok turns off some of Zope 3's security
infrastructure (for content objects, not for views). The Grok
core should continue doing this for the forseeable future,
but of course if you want to reuse other bits of Grok
standalone this shouldn't come along.
So, this is slowly but surely coming nearer. We want Grok to
be a unified story for most users, so this is not our
*primary* goal, but we do want Grok's work to be reusable in
other Zope 3 projects as well.

Cool, sounds promising

Regards
Roger Ineichen

Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch

[Philipp von Weitershausen]

Post by Martijn Faassen

Does grok support a component architecture where I can use some
components from or is grok a "use it all or nothing
concept"?

Grok *aims* to support reusing bits of it. It hasn't reached this goal
yet as we focused on making it work first, but has been an explicit
seocndary goal from the beginning last year.
* Done: Grok's mechanism of scanning for classes and instances in
modules and issuing some form of configuration has been factored out
into the martian library.
* as Philipp mentioned, emit configuration actions instead of component
registrations directly. This is underway, started at the sprint last
week by Godefroid Chapelle.

Great! Where can this work be seen?

Post by Martijn Faassen
* split up Grok into separate components that are independently
reusable, without having to pull in the whole of Grok to use this.
Philipp wanted to start this work but I'm not sure about its status.

There's a branch that works and has tests [1], but I need to speak to
you about some quirks that the current Grokker story has. Some
refactoring in Martian would make this much easier. I will bring this up
on grok-dev.

Post by Martijn Faassen
* related to this, Grok turns off some of Zope 3's security
infrastructure (for content objects, not for views). The Grok core
should continue doing this for the forseeable future, but of course if
you want to reuse other bits of Grok standalone this shouldn't come along.
So, this is slowly but surely coming nearer. We want Grok to be a
unified story for most users, so this is not our *primary* goal, but we
do want Grok's work to be reusable in other Zope 3 projects as well.

[1] http://svn.zope.org/grok/branches/philikon-grokcore.component/

[Martijn Faassen]

Hey,
[snip]

Post by Philipp von Weitershausen

... emit configuration actions instead of component
registrations directly. This is underway, started at the sprint last
week by Godefroid Chapelle.

Great! Where can this work be seen?

Good question. I thought there was a branch but I can't find any. This
definitely needs some followup from Godefroid, to at least check his
work into a branch of Grok: Godefroid?

Post by Philipp von Weitershausen

* split up Grok into separate components that are independently
reusable, without having to pull in the whole of Grok to use this.
Philipp wanted to start this work but I'm not sure about its status.

There's a branch that works and has tests [1], but I need to speak to
you about some quirks that the current Grokker story has. Some
refactoring in Martian would make this much easier. I will bring this up
on grok-dev.

Okay, thanks, see you there. Hopefully we can get martian fixed for
this quickly.

Regards,

Martijn

[Philipp von Weitershausen]

Post by Roger Ineichen

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.

[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

Post by David Pratt
Hi Uwe. I have been thinking of something similar and posted on the
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.

Post by David Pratt
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 :).