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@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