[Grok-dev] Re: [Zope] Response to Matijn Faassen Grok/Zope 2 question.

[Sebastian Ware]

I went from TTW with Zope 2 to Grok so I thought I would chip in...

29 nov 2007 kl. 13.53 skrev Martijn Faassen:
>
> On Nov 29, 2007 2:29 AM, Rene B <rb2.net at gmail.com> wrote:
>>
>> 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.
>

The two main reasons for me to switch (apart from really liking the  
idea of the Zope 3 component architecture) were:

-I can use the full power of Python and all it's libraries without any  
voodoo... (restricted Python wasn't very fun)
-TTW gets messy when the number of python scripts increase

I still try to generate as much HTML as possible in python-code to  
keep the ZPT-files clean and readable. That is just a matter of taste.

The import/export feature of Zope 2 rocked! I miss it a lot. Also the  
live editing of objects (edit/cut/paste...) was really useful. This  
was the first thing I wrote in Grok, a simple CMS to handle my objects.

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

I loved that TTW didn't require a restart when python scripts were  
updated. That was a great feature. I don't miss it that much any more,  
because I have created a keyboard shortcut in my IDE (Komodo) so I  
just hit shift-command-R and my app restarts in 2-5 secs. But I  
wouldn't mind saving those seconds too.

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

In many cases it was the GUI configuration that was the big benefit.  
It is kind of the equivalent of having recipes to solve common coding  
problems. Recipes rock for newbies!!! trust me...:)

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

Zodb is just so much more adapt at persisting python objects than a  
RDB. I think the reduced complexity of the end application is worth  
the learning curve. However, it does have it's limitations (ad hoc  
search...). I find that I design better applications with Zodb than  
without.

Mvh Sebastian