[Grok-dev] Re: is automatic context detection harmful?

Leonardo Rochael Almeida leorochael at gmail.com
Tue Aug 28 10:23:05 EDT 2007

Yes, there are those of us who like to read the Python Language
Reference just for kicks, so +1 :-)

If one were to help with this documentation, where in grok should we
start looking? The doctests?

On 8/28/07, Brandon Craig Rhodes <brandon at rhodesmill.org> wrote:
> Martijn Faassen <faassen at startifact.com> writes:
> > I don't think the grok.context() rule is so hard to understand.
> > Almost all the grok directives have a default. If you leave it out,
> > the default behavior will kick in.
> Ah!  I begin to understand!  If we followed to its logical conclusion
> my argument that requiring grok.context() makes code more legible, we
> would have to always require *every* Grok directive, which would mean
> dozens of Grok statements everywhere from now on.  But, instead, both
> the grok.context() directive and every other Grok directive is going
> to always have the Most Useful Default possible, so that in as many
> places as possible they disappear.
> If I understand that correctly - and thanks for your long and helpful
> reply - then there is a new piece of documentation I would like.
> I want a concise document showing, for every class that can be
> decorated with Grok directives, the list of every single Grok
> directive that applies to that class, and gives the default value.
> Because, I now see, when I write a simple Model or View, even if I
> include grok.context() to make things more explicit, there are
> probably several other directives I don't even know about for which
> Grok is silently choosing reasonable defaults that I therefore never
> have to think about.  It would be neat to have one place of reference
> to see what they are and what they default to.
> I would be happy to start such a document if none exists (is it
> somewhere I haven't looked yet?).
> Such a document would not be like a "tutorial", and only a little like
> a "recipe".  It could even go by the separate name of "Reference",
> maybe called "the Grok Reference", because it seems to me that it
> would have the same place in our documentation as the Python Reference
> has for Python - the place you go for the dry, technical, final
> explanation of everything that Grok allows.
> I would also love the Grok Reference to have a short, brief, and
> exhaustively correct description of how Grok/martian iterates across
> my application - all in one place, the rules about what directories it
> enters, which it ignores, and exactly how it finds my modules and
> templates.  Which might be helpful when beginners are debugging "Why
> doesn't Grok see my class"!
> --
> Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev

More information about the Grok-dev mailing list