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

Philipp von Weitershausen philipp at weitershausen.de
Mon Oct 8 13:34:32 EDT 2007

Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
> [snip]
>>> It's still one extra click but less confusion about installation. It 
>>> might actually help beginners to see the application as a name in the 
>>> URI: http://localhost:8080/myapp as opposed to http://localhost:8080, 
>>> as that makes clear that the app object is an object like all others.
>> That last sentence is very interesting. grok.Application things are 
>> just yet another object in the hierarchy that are traversed over. 
>> They're not really special, which is probably what's causing the 
>> confusion in the first place: Why is the "application" a thing that's 
>> traversed over?
>> Perhaps we should consider giving grok.Application a better name that 
>> explains what it really is. It could be as simple as calling it 
>> grok.ApplicationRoot, indicating it's some sort of root *object* in 
>> the object hierarchy.
> It's an interesting consideration, but I'm not sure it's only the 
> application root conceptually. Right now, it's also the installation 
> point - the object that gets created. Even if you create this object 
> automatically it will remain an installation point. When you create it, 
> presumably the application is also set up in such a state to be usable 
> in some form.
> If we implement the grok.title() and grok.description() directive 
> proposal, you'd expect that you'd see the title and description of the 
> application the UI. The grok.Application subclass seems to be the best 
> place to stick this information.
> 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):

Admittedly, that still sucks. But you get the idea :).

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

More information about the Grok-dev mailing list