[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:
>>> 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::
Admittedly, that still sucks. But you get the idea :).
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev