[Grok-dev] Re: Admin UI name change suggestion

Philipp von Weitershausen philipp at weitershausen.de
Tue Oct 9 00:04:23 EDT 2007

Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
> [snip]
>>> grok.Application by itself isn't implying it's necessarily a root of 
>>> anything; it's a mixin class and it's up to the person who writes the 
>>> application to make it some form of containerish thing.
>> True. So, if it's entirely up to the application author to give it 
>> meaning, then what's in grok.Application currently? It really just 
>> gives us an "add menu item" in the admin UI, doesn't it.
>> Then why don't we name it so? grok.AddableInAdminUI. Now, that 
>> obviously sucks. But perhaps we can make it a class-level directive::
>>   class TodoList(grok.Container):
>>       grok.addable_in_admin_ui()
>> Admittedly, that still sucks. But you get the idea :).
> Yes, but it all sucks more than grok.Application. If you mix in 
> grok.Application, you imply:
> * it's an ISite thingy
> * it's the root thingy of the application (even if it's not a container,
>   which typically it is)

Hence my earlier suggestion to call it grok.ApplicationRoot rather than 
grok.Application, simply to indicate what purpose it serves.

> * typically contains utilities with configuration state, typically with 
> some form of end-user configuration UI
> * typically contains some indexes
> * can get to it using application_url() and such

This is a good point.

> * is addable in admin UI
> * could potentially have a title and description that show up in UIs
> Moreover, you can say:
> If you want to make some object into a new standalone application with 
> Grok, start with mixing in grok.Application.
> I really think the word's just fine. :)

I'm convinced :). I still think grok.ApplicationRoot would be slightly 
more appropriate.

http://worldcookery.com -- Professional Zope documentation and training

More information about the Grok-dev mailing list