nested groups?

[bobhaugen]

Trying to abuse brosner's ingenious groups...

Got the basic pattern working: created Company which has existing
content apps Topics and Wiki, and new content app Resources.

Now I am trying to get Company to have Projects which have Tasks.

Crashing and burning trying to get the task_list for a project.

The projects.project view had a kwarg group_slug, which in this case
(I think) meant the project, and I want to reserver group_slug for the
kwarg to get the content app urls.

So I changed the kwarg to project_url, and changed
Project.get_absolute_url accordingly, but kept Project,get_url_kwargs
as-is - returning {'group_slug': self.slug}

That was apparently unwise. Went into an infinite loop somewhere (or
something) and crashed the browser.

And I am running out of time to play today, so thought I'd leave a
couple of questions here.

1. Do nested groups (e.g, Company->Projects->Tasks) violate the
assumptions of the groups implementation? In other words, is this a
bad idea, or should I be able to do it if I make the proper changes?

2. If it's doable, any tips for what to try next?

If no tips, and brosner doesn't tell me to stop it, I'll keep hacking
tomorrow...

[Daniel Greenfeld]

This sounds pretty neat Bob. My hope is that once I get clear of my
current project due October 19th, I plan to visit the Pinax tutorial
which also works off of the ingenious Pinax groups technology.

Sorry I can't be involved now. :(

Danny

--
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.com
http://dannygreenfeld.blogspot.com

[Chris Babcock]

On Fri, 9 Oct 2009 13:27:34 -0700 (PDT)
bobhaugen <bob.h...@gmail.com> wrote:

> 2. If it's doable, any tips for what to try next?

Either control recursion depth or implement an ancestor table.

The use cases you propose are certainly doable, but you may need to
deal with pressures that come up to implement nested groups that are
user defined and/or where ownership is reassignable. A non-existant
group can't be a parent, but you'll have to check for circular
memberships if you allow users to change the parent id after creation.
If you allow arbitrary depth to nested groups then you'll lose the
ability to fetch all descendants of a group in one query unless you
implement a join table for ancestor relationships. That carries its own
performance penalties, but avoids access time expansion exponentially
proportional to the nesting depth.

Chris Babcock

[bobhaugen]

On Oct 9, 3:58 pm, Chris Babcock <cbabc...@kolonelpanic.com> wrote:
> On Fri, 9 Oct 2009 13:27:34 -0700 (PDT)
>

Hey Chris, thanks. Those are great tips if and when I want to
implement a full-fledged composite pattern.

At this moment, I am just trying to make brosner's current projects
into a group-aware as well as a group app.

In other words, if I can get *one* level of nested groups, I'll be
happy.

Will do some debug tomorrow to see if I'm getting into infinite
recursion now. If so, I'll happily limit the depth.

[bobhaugen]

Clues:

1. task_list.html gets hung in django/template/loader_tags.py(72)render
()
Trying to render <ExtendsNode: extends "tasks/base.html">

2. tasks/base.html {% extends group_base|default:"site_base.html" %}

3. If I set group_base = None, the problem goes away.

4. I think the problem is in templates/projects/content_base.html (the
group_base)

Not sure what to do about it yet (other than disable group_base for
now). Out of time for today.

[bobhaugen]

Ok, found the problem: recursive {% extends group_base|
default:"site_base.html" %} in tasks/base.html and projects/base.html.

Should have been obvious, I feel stupid.

But changed it to {% extends parent_base|default:"site_base.html" %}
in projects and that solved the problem. Or at least that problem,
maybe more to come.

[bobhaugen]

I think I am stuck in trying to abuse pinax groups to allow group apps
also to be content apps, e.g. for Company to have Projects as well as
Topics, Wiki, etc. Don't know what to do next.

Problem as best I can figure it is that all content apps want to have
a group_slug kwarg, but to make a group app into a content app, its
parent needs to have a different kwarg (e.g. parent_slug).

And that kwarg is set in the model's get_url_kwargs method:

def get_url_kwargs(self):
return {'group_slug': self.slug}

If you use the same kwarg in 2 levels of groupness, you get a variety
of errors, including:
redefinition of group name 'group_slug' as group 2; was group 1

If the kwarg is group_slug, that works for all content apps, but not
for group apps that want also to be content apps.

If the kwarg is parent_slug, that works for projects (a group app
trying also to be a content app), but not for pure content apps
(Topics, Wikis, etc.)

I suppose I could still be missing something obvious, and will
continue to think about how to accomplish my goal here, but that's it
for this series of experiments. (Unless I get some great new insight
today...)

If anybody wants my experimental project to see if they can make it
work, let me know.

[bobhaugen]

Only inspiration I came up with today is to start changing the pinax
groups implementation so it allows variant url_kwargs.

If I get that all working, will discuss on pinax-dev.