Grok 1.0 and beyond
Luciano Ramalho
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
Dirceu Pereira Tiegs
> 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.
+1
Some really important stuff that IMHO should be better on Grok:
- Easier authentication / user management;
- *Good* form generation: zope.formlib's is too primitive comparing to
Django admin interface or Archetypes, for example;
- Indexing / Searching: I think this should be easier, perhaps with a
default Catalog with default indexes, something more like Plone's
CatalogTool;
- Automated testing: I know this was already discussed, but I really
don't like to write the same boilerplate code to run my tests on every
grok application.
(And hey, please don't take it wrong. This is not a rant, these are
simply suggestions).
Cheers,
--
Dirceu Pereira Tiegs
Weimar Consultoria
Hospedagem Plone, Zope e Python
http://www.pytown.com
Dirceu Pereira Tiegs
> 4 jan 2008 kl. 16.17 skrev Wichert Akkerman:
>
> > Previously Luciano Ramalho wrote:
> >> 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.
> >
> > add-on products for grok that implement common features. For example I
> > would love to see a megrok.authentication that I could plug into all
> > grok applications. LoginDemo could then just be a trivial demo which
> > only loads grok and megrok.authentication and does nothing else.
> >
> > Wichert.
> >
>
> I was helped a lot by hurry.query and hurry.workflow. Without these I
> would probably have abandoned Grok early on. Maybe more "helper
> components" such as these are a solution. IMHO we don't want core Grok
> to grow too much.
+1, but I think some of these "helper components" could ship with Grok
(perhaps by making grokproject download and install them).
Luciano Ramalho
> Excuse my ignorance, I might not be grasping the full complexity of
> your implementation, but I found annotationa easy to implement after
> looking at the tests in grok.Annotation.
Thanks for the pointer, Sebastian! There's nothing fancy about the way
I use the annotations, but I did not use grok.Annotation so that was
my mistake. I will look into it and refactor that part of the code. My
main references for doing annotations were the books by Philipp and
Stephan, it totally escaped my mind that grok.Annotations existed (we
really need the reference!).
> And Kirbi set me on the right track to manage users. Maybe this is only
> an example of how important "howtos" and "recipes" are.
Yes, most of the user management code in LoginDemo was extracted from
Kirbi, with the simplification that LoginDemo does not use roles but
assigns permissions directly to principals, and the addition of
annotations to store extra data about the users.
Cheers,
Luciano
Luciano Ramalho
> - -1 to expanding the core. Note that if we make 'easy_install' a
> first-class citizen in the Grok world (see Noah's problems earlier this
> week), then we don't need or want to jam such helpers in the core: they
> are a 'bin/easy_install <helper>' awa (in the virtualenv case).
>
> This is where virtualenv / easy_install shine: you can install a thing,
> try it out, etc. with near zero effort.
It may be near zero effort for you, Tres, a hard-core Zope insider
since the last century, and very smart one to boot. For the rest of
us, downloading and installing a package is just a fraction of the
issue.
First you have to know that the package in question exists, which is
not trivial (although I admit it's getting easier with PyPI and the
eggification trend, if you are not bitten by dependency problems).
After you discover it, you have to figure out how to use it. Many docs
and tests don't provide enough context to be anything like real world
usage examples of the APIs. Most Zope 3 components I've seen are
documented; what is sorely lacking is documentation on how to put
those components together to solve real problems. And we are talking
about basic, essential stuff here: managing users, indexing and
searching, populating a select widget with options, stuff that every
web developer needs.
I think Grok core has to integrate and document a wider set of
facilities if it is to be favorably compared to other agile web
frameworks.
Best regars,
Luciano
Dirceu Pereira Tiegs
> On Jan 4, 2008 9:03 PM, Dirceu Pereira Tiegs <dirce...@gmail.com> wrote:
> > - *Good* form generation: zope.formlib's is too primitive comparing to
> > Django admin interface or Archetypes, for example;
>
Yeah, but most web-apps today have CMS characteristics.
+1 for this not belonging to the core, we should enhance zope.formlib
or z3c.form instead.