[Grok-dev] Grok 1.0 and beyond

[Luciano Ramalho]

Recently I've spent most of my spare time developing LoginDemo [1] and
that has led me to some deep questioning of what Grok is today and
what I'd like Grok to be.

[1] http://svn.zope.org/grokapps/LoginDemo/

For those who don't know about it, LoginDemo is an app that allows one
to create a user account, login, logout, and see what other accounts
exist. It's intended to demonstrate how to program these tasks using
Grok. I've probably lots of things in a sub-optimal way, and I'd
really appreciate if some of our gurus take a look at the code. It's
very focused, and quite well covered with tests, so please feel free
to refactor, improve and simplify whatever you feel the need.

To me, this experiment has demonstrated that Grok has a long way to go
to be appealing to people outside of the Zope 3 community. For an app
as basic as that, I think a dozen lines of imports in each module is a
sign of trouble: the programmer has to learn too much of Zope 3 to do
even the bare essentials of a web app. Writing and registering an
adapter that does lots of attribute trickery just to put annotations
in a principal is a sign of another problem. On any SQL-based web
framework it not difficult to add attributes to any entity, and in a
ZODB-based one it should be easier, not harder. Granted, after I set
up the adapter it's now trivial to add as many fields as I like to a
user, but getting to this point is not easy for someone just coming to
Grok from anywhere but Zope 3.

Philipp's Todo list and my earliest experiments, AnimalTree and Adder,
show that doing toy apps in Grok is really easy. During the PloneConf,
Andy McKay told me just that: all he sees are these trivial toy apps
demoing Grok. How about some exciting stuff? Well, it turns out doing
anything more exciting is quite hard in Grok, because of the need to
find, understand, and combine lots of Zope 3 parts.

Also, although extremely rich in funcionality, Zope 3 is amazingly
poor when it comes to the practical needs of day to day web
programming. Case in point: why does it offer fields as varied as Id,
BytesLine, DottedName, ASCII, URI etc. but not an Email field? And we
certainly could use more decent widgets. I'm not even asking for
Archetypes-quality widgets or Ajax (yet), just some that don't suck as
hard as a plain input type=text for entering dates...

Grok is a great improvement over Zope 3, but it can only be considered
"agile" if we compare it to plain Zope 3 and J2EE. If you take a
deeper look at Django or Ruby on Rails, Grok really looks primitive
and not very agile. Kind of like a caveman, if you come to think of
it...

Please understand that I think Zope 3 is an extremely valuable
codebase, and that Grok is the best thing to happen to it, by making
it much more accessible.

Grok the software is great, but Grok the community is even better:
having personally met most of you in 2007, I believe this group has
the talent and sensibility to do what it takes to make Grok a viable
alternative to Django and Rails for a lot of projects. But right now,
I find that Grok can only appeal to people who have already drunk
massive doses of the Zope 3 Kool-aid.

So if we'll have Grok 1.0 out soon, I will help however I can to make
it happen. But this will be like Zope 1.0 when I found it in 1998:
really promising, but not really there yet.

Grok 2.0, however, may be truly great if we make it so.

Cheers,

Luciano