[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