[Grok-dev] Re: template syntax
faassen at startifact.com
Wed Jan 10 15:03:23 EST 2007
Gary Poster wrote:
> While I'm not sure I'd use grok because it doesn't appear to be designed
> for the kind of work I do (over the long haul, I prefer configuration
> over convention, for instance),
I hope you'll end up changing your mind about Grok.
I'm going to respond somewhat argumentatively in this mail, so I hope
you'll still consider what I have to say. I am argumentative as I want
to inject some other sensibilities in the mind of Zope 3 developers
beyond the worthy sensibilities that they already have, and because
you're on Grok's home mailing list I feel I can. :) Thanks for coming
here, by the way!
Grok is in fact very committed to supporting explicit configuration. It
just has defaults and does its configuration inside Python code. Grok is
actually very explicit when it finds situations it cannot understand - I
think it already has better error reporting than ZCML does.
> I certainly acknowledge that you guys
> are trying to address a group of developers and developer use cases that
> are disenfranchised in the Zope 3 world. So, go you.
Note that I don't consider the Grok project to be altruism at all: I
count myself among the (partially) disenfranchised with the current
state of Zope 3. I think about others when thinking about Grok, but also
very much about making my own life simpler. Simple things should not be
complicated or verbose.
> So, that said, I intend this to be a very small possibly interesting, or
> maybe even helpful, piece of feedback.
Feedback is very welcome!
> The whole template folder thing sits particularly badly with me, even
> trying to put on the hat of a developer whom you are targeting. grok is
> reveling in automation, which as we well know from Zope 2 can become
> "magic" when it obscures.
Is grok indeed "reveling in automation"? Is Python reveling in
automation because a subclass has the methods of its base class? Is Zope
3 is "reveling in configuration" which we well know from Zope 3 can
become "overly verbose"? :)
Of course Grok automates. Sometimes we probably automates too little and
sometimes our automation will do too much. It's therefore very good to
discuss these things, so I'm glad you brought up the template
As a little disgression:
I think the accepted wisdom that Zope 2 has problems because it is too
"magic" because of excessive automation is a bit too simplistic. I don't
see so much of this supposed automation in Zope 2. I just see
acquisition leaking everywhere causing problems, and APIs that could be
Actually Zope 3 (but not Grok) shares some of these problems with Zope
2; security proxies getting into every nook and cranny reminds me
uncomfortably of Zope 2's acquisition wrappers.
With Grok, we try to state things only once, and give everything a
default where possible. Sometimes we state things in the directory we
place things in or the name we give to a class or file.
> The automatically-found *_template folder
> seems too disconnected and magic for me to understand as I read the code
> in your example modules. A simple explicit connection would make me
> understand what's going on when looking at a grok module better, I
> think; it would also avoid the unfortunate naming issue in the blog
> package ("page_template", if I recall) because the name could be chosen
As Christian mentioned, you can in fact choose the name explicitly using
the grok.templatedir() directive. It's just the default. You'll find
this pattern in many places in Grok: we have explicit configuration with
And yeah, the naming is unfortunately chosen in grokblog. :) Perhaps a
better name than *_templates can be imagined, though I cannot think of what.
Concerning templates, we're not entirely comfortable with all patterns
in Grok yet. I myself am fine with the template directory, but not
entirely certain about associating a template automatically with a model
if the template doesn't have an associated view class. On the one hand
it's very easy, but on the other hand there is no way to associate
permission specifications and it becomes a bit harder to realize that
such a template-only view exists at all when looking at just the Python
code. Then again, it's not hard to add such a class with a two-liner.
If we do not want to automatically associate templates without view
classes, perhaps we should give an error if you have a template in your
template directory that is not associated with a view class.
More information about the Grok-dev