[Grok-dev] Re: Question about viewlets

[Martijn Faassen]

Hey Kevin,

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.

[snip]
> 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.

Regards,

Martijn