[Zope] Response to Matijn Faassen Grok/Zope 2 question.

[Martijn Faassen]

Hello,

Thanks very much for your feedback!

I'm cc-ing this discussion to grok-dev, as I want to make sure that
Grok developers see this. Future discussion
should continue on grok-dev, I think, as this is all pretty grok
specific by now.

On Nov 29, 2007 2:29 AM, Rene B <rb2.net at gmail.com> wrote:
> Thanks for the feed back. I didn't expect the responses i got from a post
>  placed.

I think it's good you started this discussion.

> I like some of the suggestions.  Some one mentioned he used Zope 2 as
> a "container"
>  for his Python scripts. He used Python as much as possible for logic and
> sparingly
>  used DTML and ZPT to view the results. i like this approach.
> I'll stick with Zope 2 to continue the learning curve.

This is a reasonable approach to manage complexity, indeed. The drawbacks to the
this ZMI-driven approach is that distribution of software becomes
somewhat harder,
and development tools, especially team development tools, can't work
with the code. That said,
in many smaller projects this is not a major objection.

> I wanted to answer some questions asked by Martijn Fassen
>  regarding grok and what I liked about Zope 2.
> I do like the Zope 2 ZMI.  It helps organize visually your MVC. I do like
>  coding TTW and seeing a
> template file or controller all organized in a project directory and testing
> live just by clicking the link.

Yes, it's very direct, and more direct than Grok is right now, as
development still requires frequent
restarts of the server. I think there is room for a project that adds
through the web development to
Grok, "Grok-style". It'd be very different and entirely incompatible
to Zope 2, but it would allow
writing simple Python code and templates in a web interface. Jim
Fulton (the architect of Zope) and I had a debate back
in may on whether the through the web approach is really something
that adds to it, or whether you could get quite far
in replicating the experience on the filesystem. I thought the
filesystem could get quite far, and I'd certainly like
to explore it further, but he does have a strong point.

In any Grok TTW development environment, it'd be very important that
it would be possible to take TTW code directly
to the filesystem, without having to change it. Just press a button,
and boom, you have the equivalent code on the filesystem.
This could help combine the benefits of TTW development and rapid
prototyping with that of team-development tools.

> I also like the "ADD" feature. It list all the products/components you can add.
>  It would be nice to have this in Grok since i don't know what is out there to add and what they do.
>  And "add" feature with a description/docs and simple code example
>  would be nice. Example would be the the "formlib".
>  a database connection(relational)  helper would be helpful too.

That's a good point: the add list is very helpful in exploring what is
available.

One thing that Zope 3 (and Grok) is missing is coarse-grained
components, like you have in Zope 2. There are a lot
of components, but they're very programmer oriented and using them
requires calling the right API calls. They're not typically
content-style components though like in Zope 2, so it's hard to see
how these would be in an add list. Perhaps we could create a special
kind of code-content component (like a python method or a page
template) that is addable.

All this bears more thinking too. You know, I really have to thank you
for starting this discussion, as I'm getting all kinds of
ideas for Grok that might keep us busy for a while! :)

> I don't think i'll be diving into the ZODB
> right now for 2 reasons. There isn't a whole lot of ZODB docs and what
>  happens if i create a project at
> work ( i,e, asset tracking ) and the other programmers in the office only
>  know SQL . If i have all me data
> is in  ZODB how will they be able to get at it? If the asset tracking app
>  grows i know these other programmers will wont to get to the
>  data to do some adhoc report. I'll be cooked if they can't get to it
> via SQL. Unless there is a way i have not read about yet!
> Maybe someone should write some reverse ORM to translate SQL
>  and query a ZODB database!!!  stupid i
> know.

query languages like SQL do have important benefits that are missing
in the ZODB. The ZODB has benefits
too, of course. Making SQL work on the ZODB is not a project I'd like
to start. It's certainly possible
to design custom query languages for querying ZODB content however,
and several people have written things
like this in the past (including myself, in the hurry.query ZODB
extension). Anyway, it's not a stupid idea, but
also not a near-term project. I do know some of the ZODB developers
are thinking quite seriously about such things however.

I understand perfectly why the ZODB is not the right choice for all
projects. I don't think the Zope community should be
in the business of always telling everybody that they should be using
the ZODB. We started Grok with ZODB and the tutorial
is about the ZODB, but we do have several users using Grok with a
relational database and we have tutorials in the work
that will hopefully help this situation eventually.

> I will  go through the Grok Tutorials again. i did have a problem
>  with installation.
> "zope3recipes\winctl.py line 28"  no module named win32api.
> i may have missed some prerequisite.  I'll have to go through it again.
>  Zope 2 had a nice windows
> install .exe package!!!!!!!

Thanks for letting us know! I think that may be an oversight in the
Grok installation documentation. I realized only recently that
win32api is a real requirement. It's basically the win32 all
extensions, they're on www.python.org, here:

http://starship.python.net/crew/mhammond/win32/Downloads.html

(get the one for Python 2.4)

I'll create an issue for this in launchpad so we make sure this gets
added to the documentation. Here it is:

https://bugs.launchpad.net/grok/+bug/172793

> The tutorial did have a few steps wrong. Naming the projects and
>  packages come after module name
> and username and password. Not a big deal but i thought i would
> mention it.

Thanks again. It's *really* important for us to get the installation
procedure exactly
right. If we lose beginners because they couldn't install Grok, most
of the time we won't even hear from them,
so we need to really listen quite hard to people who *are* saying something.

The tutorial was originally right, but grokproject changed so now it's
not. We should fix this too. Added this
to our todo list:

https://bugs.launchpad.net/grok/+bug/172797

> my Grok install ended up in c:\python24\scripts\sample
> it would be nice if Grok was installed in its own self contained
>  directory with a self contained version of
> the required python version.  Just nice to keep it isolated from python 2.5 +.

I'm confused about why it ended up there. You must've started your installation
procedure in the c:\python24\scripts directory for some reason (while
it reuses Python 2.4 that is installed elsewhere on the system).
What was the reason you started the installation procedure in
c:\python24\scripts?

> The more docs and tutorials the better. Nothing in my opinion is more
>  important to learning and
> sticking with a platform. if you run out of docs and tutorials to grow
> on you get soured quickly.

You're right, I agree! We're currently working quite hard to fix the
Grok website
so we have a better CMS, mainly so we can better maintain tutorials and docs.

> once last thing about the ZMI and if it were to make its way to
> Grok ( even partially)!
> why not have the GMI add some code for you automatically like :
>
> import Grok
> Class Sample(grok.Application, grok.Container):
>         pass
> Class index(grok.View):
>         pass
>
> It would save typing if we could click "New App" and enter "Sample" and
>  have the MI add the rest of the
> small code. Mabe i'm being lazy but Zope 2 seemed to hide this from you.

grokproject does create this code for you already (but on the filesystem).

Anyway, the GMI is in the first stages of design; I'm not even sure
whether we can make it possible to define content objects through it.
I think
the first step would be to make it easy to create and adjust views for
existing content objects, as that
seems a more tractable problem. Note that the Zope 3 project
originally started out thinking about
all kinds of advanced ZODB-based development ideas but hit quite a bit
of complexity here, so I'd like to approach this carefully.
What we could do with any grok development environment is provide a
few very generic content objects that are still flexible
enough to start building applications. All the logic would end up in
the views, but that's not *that* far from many Zope 3 or Grok
applications anyway.

We definitely need to think about generating the right stuff by default.

Regards,

Martijn