[Grok-dev] Folders for nested pages in Grok

[Martijn Faassen]

Hey,

Dan Jacka wrote:
> What are my choices for simple nested pages in a Grok site?
> 
> For example, I have a Page model and want my logged-in users to be
> able to create/edit/delete Page objects in the UI so that they can
> easily create paths like:
> 
> mysite.com/about mysite.com/about/bio mysite.com/about/contact
> 
> ... all of which are URLs to Pages.
> 
> Coming from Plone, my inclination is to have a Folder model.

> I'll be able to set which of its contained Pages appears as the
> default page. So in the example above, 'about' is a Folder with a
> page (called 'index' maybe?) set as the default.
> 
> What's the Grok way? Do I subclass grok.Container and create all the 
> views and functionality myself, or should I (can I?) start from 
> zope.app.folder? Can I do the latter without my users having to see
> the ZMI?

The idea is indeed to subclass grok.Container and add your own views.
You could use interfaces if you like, but you certainly don't have to
for a simple app. Stay away from zope.app.folder - I don't think it
contains anything you really need.

I have an example here that might be close to what you'd like:

http://startifact.com/grokcourse/

Look at simplecms-0.2.tgz.

Concerning the ZMI, if you just override index and whatnot the ZMI 
should be gone. You can go more sophisticated with layers too, but 
that's probably overkill right now. We're working on removing the old 
ZMI from Grok entirely.

> Or should I be putting my Plone-centric Folder thinking to one side?
> 
> Pointers in the right direction much appreciated. I'm using Grok 1.0.

Plone-centric folder thinking is just fine - it's just that Grok
containers are really simple compared to Plone folders.

I've been devising different approaches for interfacing with relational
databases (and other things) using URL paths (look at traject, 
megrok.traject), but the "default" way I deal with things is container 
too. megrok.rdb is a container centric approach to interfacing with 
relational databases.

Regards,

Martijn