[Grok-dev] Re: template syntax

[Martijn Faassen]

Hey Gary,

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.

Thanks!

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

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

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

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

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.

Regards,

Martijn