followup on nested groups etc

[bobhaugen]

In #pinax-dev, brosner and jtauber wanted to do something about nested
groups but also mentioned a "more general solution".

Did that refer to a more general solution than my hack for supporting
nested groups? Or did you also have in mind other changes to the
current groups implementation?

Regardless, how can I help get this on the road? I got a project
coming up soon that wants nested groups, and some other groupish edge
cases as well. (More below...)

I can always finish off my hack, but would much prefer to spend my
time on a generally-agreed solution.

I think I understand the innards pretty well now, but I figure y'all
have ideas about how you would like things to evolve.

I'd be happy to run with your ideas and get at least a working set of
changes out there.

Other use cases that I have in mind, that I think are doable (but have
not done yet):

* Content app instances linked to 2 groups
* Member roles and role-permissions

[bobhaugen]

P.S. I'd also like to see the behaviors of base.Group refactored.

That is, I want the behavior of having content objects and bridges to
be split off from having members, so that objects with no members can
have pluggable content objects and bridges.

Seems simple, I can do it in my fork, but think it wd make sense for
groups/base.

[bobhaugen]

Oops, looks like I picked the wrong time to try to get a rise out of
brosner or jtauber:
http://twitter.com/eldarion_team/status/4818797484

Oh well, I guess I am glad they are having such success, and will go
ahead and fork groups so I can keep moving...

[James Tauber]

I'm wondering if a group without members is something all together
different, though.

The intention of a "group" is to be a set of members + content objects.

James

[bobhaugen]

On Oct 23, 5:19 am, James Tauber <jtau...@jtauber.com> wrote:
> I'm wondering if a group without members is something all together  
> different, though.
>
> The intention of a "group" is to be a set of members + content objects.

Forget the name "group" for a minute. The implementation affords 2
behaviors:
1. having content objects
2. having members

They are separatable. I'll be experimenting with the separation next
week to see what I can do with it.

(Along with a bunch of other groups experiments, all of which I am
willing to share, but wd prefer to wait until they have fewer bugs...)

[James Tauber]

On Oct 23, 2009, at 11:24 AM, bobhaugen wrote:
> On Oct 23, 5:19 am, James Tauber <jtau...@jtauber.com> wrote:
>> I'm wondering if a group without members is something all together
>> different, though.
>>
>> The intention of a "group" is to be a set of members + content
>> objects.
>
> Forget the name "group" for a minute. The implementation affords 2
> behaviors:
> 1. having content objects
> 2. having members
>
> They are separatable. I'll be experimenting with the separation next
> week to see what I can do with it.

Oh, I agree they are separable, I'm just not (yet) convinced that
level of abstraction is useful.

One could also have abstract mixins for "things with names", "things
with slugs", "things with creator/creation metadata". It's just not
clear a priori where to draw the line.

So I'm just being cautious about over abstraction. Sometimes copy-
pasting *is* the cleanest solution to do-not-repeat-yourself :-)

Happy to be persuaded on an individual case-by-case basis, though :-)

James

[bobhaugen]

On Oct 23, 5:28 am, James Tauber <jtau...@jtauber.com> wrote:
> Oh, I agree they are separable, I'm just not (yet) convinced that  
> level of abstraction is useful.
>
> One could also have abstract mixins for "things with names", "things  
> with slugs", "things with creator/creation metadata". It's just not  
> clear a priori where to draw the line.

What got me started was not the abstract idea, but having some content
app instances that I think want to be linked to two groups and some
other objects that are not groups - but their use of the content
objects is a lot like groups. That is, they want bridges, and the
content app views etc are all set up to be bridged.

As I wrote, I will be trying this next week, and maybe I'll find
technical roadblocks or hate it when I see it running.

[James Tauber]

On Oct 23, 2009, at 11:36 AM, bobhaugen wrote:
> As I wrote, I will be trying this next week, and maybe I'll find
> technical roadblocks or hate it when I see it running.

And I reserve the right to love it when I see it :-)

James

[bobhaugen]

P.S. I'm currently a little stuck on the stacked navbars and main tab
hilite when I get to company/project/tasks.

Not even sure stacked navbars are a good idea in that situation, so I
have put it aside and am working on content objects linked to 2
groups.

If you got any ideas on the navbars, however vague, I'll run with
them...

[bobhaugen]

P.P.S. the current sample_group_project also punts on the project tab
hilite for project/tasks...

[James Tauber]

Yes, that's a bug :-)

James

[bobhaugen]

I can fix that one. Haven't figured out how to go one more step to
heaven, though.

[James Tauber]

For 3+ level of navigation with active one marked at each level, I'm
not even sure the best way to do the HTML and CSS much less the
template inheritance.

James

[bobhaugen]

On Oct 23, 8:03 am, James Tauber <jtau...@jtauber.com> wrote:
> For 3+ level of navigation with active one marked at each level, I'm  
> not even sure the best way to do the HTML and CSS much less the  
> template inheritance.

Only practical UI I can think of is a left-side outline.

But then I start wondering if it's a good idea (hierarchical
navigation beyond a couple of levels - don't know where to draw the
line there, either).

[Skylar Saveland]

I've been thinking of a more interwoven system of generic relations where content objects could have members (watchers/fans/followers...) and could be related to other content objects. 

I'm thinking about a use case - say a content object, Geometry (Geom).  A Geom could be attached to a Post/Project/Image or what have you it.  Then, users could come along and attach members(themselves)/pics/Projects/Posts to that Geom object.  The Geom content object itself could serve as an ad hoc 'group'.

Perhaps if we could arrive at some simple convention essentially all content objects could become groups.  Maybe I'm too far out on a limb here?

[bobhaugen]

On Oct 23, 12:06 pm, Skylar Saveland <skylar.savel...@gmail.com>
wrote:

> I've been thinking of a more interwoven system of generic relations where
> content objects could have members (watchers/fans/followers...) and could be
> related to other content objects.

Skylar, do you envision these content objects having bridges and
stacked navbars like groups and their content objects? Or are they
just generic relationships?

[Skylar Saveland]

> I've been thinking of a more interwoven system of generic relations where
> content objects could have members (watchers/fans/followers...) and could be
> related to other content objects.

Skylar, do you envision these content objects having bridges and
stacked navbars like groups and their content objects?  Or are they
just generic relationships?

Yeah, not really thinking of stacked navbars.  But maybe these nested relations shouldn't have to be crammed into the stacked navbar relations and should have a more event-driven (user clicks) way of revealing themselves... I think of modal dialogs perhaps.

0)proj1
     |
1)Geom-
2)Blogs
   --users following, pictures attached, oembeds,
                                        |
                                       / \
                                proj1   proj2
                                  /
                              Geom

Hmm, that diagram is probably more confusing than enlightening ... short on time atm though 0o.

[bobhaugen]

Skylar,

I think the existing pinax groups implementation has two main
behaviors:
1. having members
2. bridging, which handles urlpattern and navbar relationships (to an
extent, that is, partially through 2 levels: group and content objects
belonging to the group).

I'm (for now) trying to stay roughly within that pattern, but
extending the bridging relationships thru one more level, and allowing
non-group objects to have content objects with bridges (in other
words, separating the main behaviors).

If I understand correctly, you are thinking about a different set of
relationships.