[Grok-dev] a grok.getApplication() implementation

Martijn Faassen faassen at startifact.com
Mon Nov 30 06:22:35 EST 2009

Jan-Wijbrand Kolman wrote:
> Kevin Teague wrote:
>> I see that Jan-Wijbrand "Viewish" refactoring has just moved
>> application_url into grok.util.application_url (leaving the original
>> View method in place but just delegating to the util). So then you
>> could have symmetry here by making a grok.util.application function
>> instead of a grok.getApplication function. This would probably make
>> more sense if people wanted to have a View.application() method to be
>> symmetrical with View.application_url().
>> Having a `grok.util.application(context)` function wouldn't be too
>> bad, it does make the call more explicit as to where it's finding the
>> application from, as opposed to how grok.getSite() or a
>> grok.getApplication() appear to come from thin-air.
>> I'm not too fussy on any of these choices, but I would like an easy
>> way to get to the application object itself within Grok.
> +1
> Having a grok.util.application(context) function makes sense to me. It 
> also makes sense to consolidate grok.util.application_url()'s 
> implementation to use grok.util.get_application(context).

I agree we should make application_url use any application-getting 
functionality we'll develop.

I think that application-getting functionality should be called:


That's in parallel to:


Which at least I use quite a bit already.

It should not be dependent on being on the view, as the request is not 
involved in getting the application.

The implementation of getApplication (with that name) can go into util.py.

The alternative would be to call it get_application(), following Grok's 
more lower-casey conventions. I think since the parallel with getSite() 
is so strong here, we should go for getApplication.



More information about the Grok-dev mailing list