[Grok-dev] Re: Grok actions and grok.grok() cleanup

[Martijn Faassen]

Philipp von Weitershausen wrote:
[Grok now has configuration actions!]

Yay!

> If you use grok.grok() in your unit tests, you will have to use
> grok.tests.grok() so that the configuration actions are executed. I will
> probalby move this to grok.testing.grok() though. grok_component will
> likely also move to grok.testing (if Martijn and other people who use it
> are ok with that).

Sure, +1

[snip]
> Here's how I tackled the individual keyword-arguments:
> 
> * module_info: Since this is generally useful for all grokkers, I've
> created a branch of martian that now always passes it in as a keyword
> argument. This change is completely backwards compatible because a) most
> grokkers took the module_info argument in the first place and b)
> grokkers are required by the IGrokker interface to take **kw anyway. So
> even if they wouldn't wanted module_info, it wouldn't matter.

Sounds good. +1

> * context: This is the object that is figured out by scanning for
> grok.Model and grok.Container subclasses. I now implemented a global
> (=module) grokker that has a higher priority than all the other
> grokkers, therefore it's executed ahead of them. It does the scanning
> and save the result in module.__grok_context__. This is incidentally the
> same variable that the module-level grok.context() directive uses. So
> module.__grok_context__ either contains the explicitly set context or it
> will contain the implicitly figured-out context (or it will contain the
> special AMBIGUOUS_CONTEXT marker which leads to an error). The advantage
> of this being a grokker also means it's now pluggable which classes are
> treated as implicit contexts.

A very nice idea. +1

> * templates: This is now also dealt with by a grokker that creates the
> templates registry and puts it into modules.__grok_templates__. Grokkers
> that need it can get it using module_info.getAnnotation('grok.templates'), just like we get all other
> module-related annotations.

+1 too.

> The finalize method basically checked for unassociated tempates and
> raises an error if it found any. I've turned this into a grokker as well
> and gave it a very low priority (-1000) so it's executed after all other
> grokkers.

A nice concept to use module grokkers for this. It's interesting how in 
a year's time we evolved from a completely ad-hoc way to do this with 
Grok to a separate, general system (Martian), and we continuously find 
better ways to use this. We wouldn't have been able to design this last 
year as we would've had no clue what we were doing, so it's very nice to 
see that now we do. :)

[snip]
> To summarize the visible changes for 3rd party code:
> 
> * grok.grok() changed because of the configuration action dependency.
> Use grok.tests.grok() (or wherever it will finally move) instead.

I'd advocate grok.testing.grok() for this, and you seem to agree, so it 
looks like that will be the final location.

Regards,

Martijn