[Grok-dev] An untapped area..?

[Jeff Shell]

This is something I meant to write about when I saw the recent 'ZMI'
discussions (fwiw, the 'Grok ZMI' as it stands right now in 0.11 is
EXACTLY the kind of ZMI that I want: install an app, manage the
instance, look at help (oh, except stupid zipped eggs make help cry)).
As always, I get busy and can't always keep up on discussions and I
apologize if this has been brought up or covered by someone else.

I've been reading some of the recent grumblings from the Rails world,
and I've been thinking about the old 'Z Shaped Learning Curve' (seeing
the ZMI mentioned earlier made me think of it) - there comes a time
when apps grow up. When they get to be too big for the automagic
systems, or for the ZMI, or for basic templates and scripts. I think
Grok can serve the automagic while also catering to helping
applications scale up into the kind of world to which traditional Zope
3 caters, where explicit and measured control become important.

I know that I couldn't have done any of my recent projects in Grok, or
just about anything else besides Zope 3. Those projects are large
beasts, although many started out small. As cranky as I can get having
to type out ZCML and some of the other long-winded stuff just to get
something seemingly simple going, I appreciate the hell out of it due
to what we've been able to build and deliver.

Anyways, I know I'm a bit of a special case. I've been using
Bobo/Principia/Zope1,2,3 for more than a decade and my brain is set in
its object-publishing ways, and I remember all of the "wouldn't it be
nice if we..." questions from my Zope 2 days that I've been able to
answer in Zope 3.

But I do look at Rails, Django, Pylons, etc, with a bit of envy, esp.
when trying to write something that is small and simple. Grok serves
this area well, and I appreciate how it takes advantages of the
technological underpinnings of Zope 3.

The area that I'm unsure of is what happens when someone grows beyond
what Grok makes easy. Because very few things stay small and simple
for long.

Here's the kind of story that I think Grok should be able to tell. "So
that little Knowledge Base application you wrote over a weekend has
been getting used more and more within your company. The boss even
wants your whole devision to start using it, if it can also handle
trouble tickets. There's even a good chance that it could get used
company-wide. It's going to require some structural changes as now
you'll have a few more models and a lot more views and will have to
integrate with the company contact system which, fortunately, has a
Python API already. In short, your little application is about to grow
up fast. Grok has done a lot of things automatically up until now, but
it might be a good time to let some of that automation go, or at the
very least it may be time to understand in greater detail what Grok is
doing so that you can start to take greater control yourself. Here's
how Grok uses Zope 3. Here's information on where to look for answers
when things aren't working like you expect. Here's how to explicitly
set up a view or adapter so that you know nothing funny will happen,
especially when you start to work with developers from that other
division. You know the one I'm talking about. But don't worry - you
don't have to change it all at once! Here's how ..."


-- 
Jeff Shell