[Grok-dev] Re: An untapped area..?

[Jeff Shell]

On Jan 23, 2008 4:09 AM, Martijn Faassen <faassen at startifact.com> wrote:
> Hey,
>
> Jeff Shell wrote:
> [snip]
> > 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.
>
> Why do you think you can't have done them with Grok? I'm really curious;
> after all it's typically possible to reach exactly the same
> configuration state using Grok.

There are three major layers - a CMS (like Plone, but not like Plone),
a vertical market collection of packages, and an additional set of
plug-ins. That's all on top of Zope 3, and before we get to the actual
application.

There are a lot of resources and resource-library setups. There are a
few overrides (the IWriteFile adapters for zope.app.file objects are
incredibly stupid and broken). There are a couple of major and
different Skin layers. It's a big system.

Big systems go through a lot of refactorings. This one certainly has.
It didn't take me long to run into a surprise when I tried to do a
simple "Extract Class" kind of refactoring in a small Grok application
I was trying. As someone who's had to explain why ``<dtml-var
full_name>`` works fine while ``<dtml-var name>`` doesn't, I'm
sympathetic to the anguish that forgotten conventions can cause. And
again, I think this mostly happens when things get to be large scale,
both in code size and in team size. "But I just moved this class to a
different module and now I'm getting this funny error..." "Oh, for
that kind of class you have to do grok.baseclass()" "Oh, Grok was
picking up a context automatically before, but now it isn't. you have
to explicitly set it."

I've maintained enough of these big systems through the years to see
conventions go forgotten, and have seen new batches of developers
struggle with the surprises.

So when I have such a big core framework, used by multiple customer
sites/applications, that I hope to have last for years and years, I
personally like to turn all the magic off.

That's not a knock against the design or aims of Grok. I just would
not be comfortable using that in this situation. I have too many bad
memories from Zope 2 (I have a lot of great memories too, but I
remember some bare knuckle fights as the system and I'd clash when
it's DWIM did not do what I meant).

In fact, I'd like to our end-point applications using Grok at some
point, as that's the area where I hope new hires will do most of the
work and I'd like for the system to be a lot easier for them to learn,
run, and maintain.

> > 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.
>
> Examples? Grok can do views, adapters, multiadapters, local and global
> utilities, layers, skins, and just about anything Zope 3 can. Soon
> enough, viewlets. The only thing that Grok doesn't do out of the box is
> content-level security. Someone could add it though - I don't see it as
> a major project.

I worry more about not what Grok can do, but where it will suddenly
surprise you. There just comes a time when conventions feel like
they're getting in the way more than they are helping. And the only
thing that I find more frustrating is a system that makes me have to
do a lot of explicit work to get something done is the system that
makes me have to do even more explicit work to start turning its magic
features off.

Part of what I'm trying to point out is that the narrative should talk
about what's going on, and why, and how to control it. A lot of the
magic 'DWIM' systems never do this, partially because they have no
control story to tell. They have the air of "You follow the
convention, and if that doesn't work out for you, too bad, you're
writing your code the wrong way anyways and we don't want you as a
member."

> > 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 ..."
>
> Grok *does* allow you to set up views and adapters explicitly. It's just
> that the explicitness is in Python code; if you don't use defaults for
> your directives you're completely explicit. Not that I think there's
> anything very magic about the defaults it uses.

It was counter-intuitive for me to try to make my own base View class.
In normal Python intuition, I should be able to make a module
'base.py', and do a `class View(grok.View):` and that's it. Grok blew
up. I eventually found that I needed to add `grok.baseclass()` to the
class statement. Which wasn't a big deal. But that's not the kind of
defaults that I expect.

Likewise, I do hope that the name of 'ViewBase' turning into one of
those base classes is going away. "I have this ArmyBase view, why
isn't it picking up my context?" "Oh, because it's name ends in Base.
Change it to ArmyBaseView or something".

Those are the kinds of defaults that worry me. Just like how <dtml-var
foo> was really a shortcut for <dtml-var name="foo"> which worked out
awesome - until you tried to display a variable named 'name'.

A big way to help this situation is to have good reference
documentation though, and Grok does appear to have a good start there.
Make sure the docs have some good examples. This is, again, an area
where many other systems fall short.


-- 
Jeff Shell