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

[Martijn Faassen]

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.

> 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.

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.

> 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.

Could you give an example of what you can do with Zope 3 + ZCML and you 
can't do with Zope 3 + Grok? I am sure that there *are* examples, but 
possibly not as many you can't think.

Of course, you also mention "here's the information". That I think is 
very important; we should get our reference published and completed so 
that the information is available to everybody.

Regards,

Martijn