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

TIm Terlegård tim.terlegard at valentinewebsystems.se
Tue Oct 9 07:44:31 EDT 2007


On Oct 8, 2007, at 8:17 PM, 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)
>
> * 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
>
> * is addable in admin UI
>
> * could potentially have a title and description that show up in UIs

I think it is still confusing. :)

I come from the zope2/cmf world and there you add sites, not  
applications.
And adding sites makes perfect sense to me. In the site I can add  
indexes
and whatever. Why do I need an application for that? When would it be
useful to add an application inside an application?

Why not let all objects providing ISite or ISiteRoot be addable in  
the admin
UI?

/Tim


More information about the Grok-dev mailing list