>
> This is a followup to http://groups.google.com/group/pinax-core-dev/browse_thread/thread/bd6f5d4df6a78e8
>
> I now have working proofs of concept at:
> http://github.com/bhaugen/pinax-groups-experiments
> of:
> * nested groups (e.g. company/projects/tasks)
> * content app instances associated with 2 different groups
> * some navbar improvements
I will definitely take look.
> Navbar improvements include:
> * Project/tasks retains the Project maintab hilite (that's a bug fix)
> * Likewise Company/Project/Tasks retains the Company maintab hilite
> * Current subnav links are hilit (related to http://code.pinaxproject.com/tasks/task/115/
> )
From the sounds of it these can likely get moved back upstream. I'll
take a closer look and let you know.
> My goal in these experiments to see if Pinax was ready to work for an
> upcoming real project. The various apps in the experimental project
> are not the ones for the real project, but very simple placeholders.
This is common. We've done this in a few cases on internal projects at
Eldarion.
> I posted this mostly to do my duty. Don't know if anybody else is
> very interested, but I got the stuff to work well enough to meet my
> personal requirements for now, and you never know about anybody
> else...
This need has cropped itself up in an internal project so it is a very
real requirement for myself. I've moved Pinax's group support out into
an external app that I'll get hooked up in Pinax once I've done the
nested group support. You can follow along on my branch — http://github.com/brosner/django-groups/tree/nested_groups
I've already begun making some fixes. I still have some more to go,
but one change I've made that seemed to be a sticking point in your
research was dealing with multiple group_slug groups in URLs which
Django complains and rightfully so. I've solved this by use the group
model _meta.object_name.lower(). See http://github.com/brosner/django-groups/commit/142b6bea6d0fb6b3efbd9b58a840b4baea75cb70
.
Brian Rosner
http://oebfare.com
http://twitter.com/brosner