[Grok-dev] Re: Question about viewlets
faassen at startifact.com
Fri May 2 14:38:34 EDT 2008
Kevin Smith wrote:
> Ordering by definition order seems pretty cool.
Yeah, it's unfortunate that we can't make this happen if grok.order() is
not there at all. There are Python modules that let you get the line
number information that's needed, but you'd need to parse the actual
file, which is ugly.
> Ordering by dotted module name may create a consistent order, but does
> it have any real value? I typify it as "nice" to have.
At least it provides consistency. Some reasons:
* sometimes you might not care, but you do want to be able to write
tests so you want at least *some* ordering
* under any ordering scheme, *some* ordering will come out. It may
already be the order you really want, causing you to never really get
explicit about order. If we leave ordering undefined, it might suddenly
be another order when you least expect it.
> When it's time to reorder things, would I rather change the order number
> or cut-n-paste the class? Dunno.
It depends. Intra-module cut-n-pasting is useful (if you use
grok.order() without arguments), I think.
> Maybe grok is in too highly an experimental stage of grokker development
> to start laying down rules, but when I'm developing grokkers,
> I think I want more rules. I want to have guidelines on when to create a
> directive and when not to. I see this directive and it makes me
> wonder where the cut-off is for creating new directives. My gut instinct
> is *not* to create a new directive unless absolutely necessary. I think
> want a rule similar to "measure twice, cut once", "less is more", or
> "GROK SMASH ZCML".
I guess it's the border between framework and application. I see there
being a lot of potential for ordering menus, which is why I figured
investiging in a grok.order() infrastructure makes sense. It could be
applied to a lot of different things.
We're still developing our intuitions, I guess. I hope that the new more
declarative directive approach under development will also help us make
rules more consistent. I thought of the need for this when I was working
on viewlets at the snow sprint, by the way.
> So ultimately this may be a cry out for a "Grokkers Guide". (unless I
> already missed something like this on the list :) )
I'm not sure anyone can write such a guide for arbitrary Grok
extensions, at least not now. But yeah, we're basically exploring things
as we go in Grok the framework. Here is some vague approach at guidelines:
* if you have something that needs to be configured, use a base class.
Try to avoid 'grok.imperative_registration_command()'. A base class can
use directives which have defaults, and might get a title, a description
and an order and be used in a menu, and might grow some methods eventually.
* can a potential directive be used on just one kind of class or a lot
of different kind of classes? If it can be used on multiple unrelated
kinds of classes, it might be a directive.
* is a potential interesting in application configuration from a
framework perspective, or is it just interesting in a particular
concrete application? If it's more frameworky (menu abstraction, say),
then it might be a directive.
* is it something that is used to declare and then is used by other bits
in the framework, or is it something instances of a class itself only
cares about? If it's only the class itself (instances of it) that cares
about it, it's probably not a directive.
More information about the Grok-dev