[Grok-dev] Re: What is an application?
faassen at startifact.com
Mon Mar 12 05:27:10 EDT 2007
Tim Terlegård wrote:
>> Application: yes, is a site but also marks the content as a grok
>> application for the grok registry. ie is addable in the grok admin
> So it is that simple? Good :)
> But I guess an application doesn't have to be the root of your site. If
> I write a blog and make it an application and then write a wiki and make
> that an application, I can still use them on the same site (the common
> word, not the zope concept) with /blog and /wiki being subdirectories of
> root which I treat as my actual site.
Yes, the Zope 3 root is the 'application container', so to speak, so
it's as you say.
Besides that, there is also no limit to actually nesting applications.
So, if your blog wants a wiki inside it and provides some way to place
it, that should work.
> Hmm, but I can't access the "super"
> root object using grok, can I?
You can *access* it, by using __parent__ on your applications (that is,
if your applications are installed in root). I think you can also get to
it by using some Zope 3 API I can't recall right now. :)
If you mean install a grok application as the root itself, then yes,
that's not possible right now. It would be nice to have such a feature,
> So an application is the root of your site and you are supposed to
> have apache rewrite somesite.com to /myapplication?
Yes. You should be able to use the Zope 3 rewrite rule pattern and
everything should then work. We should document this for grok somewhere.
After you figure it out, perhaps write and donate a tutorial section?
> I also thought that the application looks a bit like a controller in Ruby
> on Rails. But a rails site can have loads of these controllers, but
> there should only be one application for each site, right?
I'm not familiar enough with Rails to judge this, but I'm glad you know
about it so you can tell us about it. :) Here are my suspicions based on
what I know about TurboGears:
I suspect the closest thing to a rails controller is a Grok 'View',
which is a single component that acts as a controller and view support
code for the template (the template being also part of the view).
Grok's models (including Application and Container) are then more
similar to Rails' objects that represent the relational database.
A difference between Rails (or at least TurboGears) and Grok is that
views are associated with models instead of the model being looked up by
the controller/view. Since views in Grok can be associated by interface
this creates a reusability potential.
> Maybe we should have a glossary?
Feel free to start one! I think we need something broader than that
though: a reference. But, a glossary would be a good start, and if you
can put in mappings to Rails concepts in a document that'd be nice to
>> Site: Not a container as you found, but is initiated with a site manager
>> container (++etc++) - where local utilities are placed by convention.
>> To make a site a container:
>> class MySiteIsAContainer(grok.Application, grok.Container):
> Yes, you can do this. Is anyone ever going to make a site that doesn't
> contain any objects? I guess people will always have to change
> grok.Model to grok.Container in app.py. Couldn't we make this the
You can still make a site contain objects and not be a container if you
use custom traversers.
It's a good point though; in most cases I imagine people will use the
container model for an application as
that tends to be more convenient. If you need control panels for
utilities, you'd probably prefer
to place the utilities directly in the container as well.
> In zope3 I can get the site object and adapt it fo a folder. How come
> the application which is a site object isn't adaptable to IFolder?
I'm not sure I understand what's going on here. What do you get when you
adapt a Zope 3 site object to a folder? (a folder, yes, but what does it
More information about the Grok-dev