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 [EMAIL PROTECTED] 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
