Final "plonesocial" sprint report
Kamon Ayeva
This morning I committed the plonesocial.socialgraph code in the collective. https://svn.plone.org/svn/collective/plonesocial.socialgraph/trunk/
I'm sorry, didn't have time to document the code.
The outcome of this is:
1) we are more familiar with the way plone.relations work and it seems really powerful.
2) there is a minimal demo in the code, that you can see by installing it : if you have a plone 3 site with users in it, there is a "My contacts" portlet which let each authenticated member add the other members as his "friends" or "contacts".
Note that the invite case will use the same code, since you create an account for the person you're inviting and at some point he becomes a member.
What seems to be needed now, after reviewing all this, is go ahead to integrate with the work done by Christian and others, and move from "prototype" state to a real implementation for all the "invite" use cases.
Now it's just occured to me that we need to study more requirements such as:
- An invited user should be able to refuse an invitation, so should the plone.relations-based relation be workflowed or we can use the 'state' attribute that exists on it for that purpose.
- Bi-directionnalily ? If I someone adds me as a friend, I should be able to see the relation coming to me, and might want to do something about it.
Cheers,
Kamon
Dylan Jay
> -----Original Message-----
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Kamon Ayeva
> Sent: Monday, 28 April 2008 10:56 PM
> To: plone-socia...@googlegroups.com
> Subject: Final "plonesocial" sprint report
>
> Hi guys,
>
> This morning I committed the plonesocial.socialgraph code in the
> collective.
> https://svn.plone.org/svn/collective/plonesocial.socialgraph/trunk/
> I'm sorry, didn't have time to document the code.
Great work. Haven't got it to work yet though :(
> The outcome of this is:
> 1) we are more familiar with the way plone.relations work and it seems
> really powerful.
> 2) there is a minimal demo in the code, that you can see by installing it
> : if you have a plone 3 site with users in it, there is a "My contacts"
> portlet which let each authenticated member add the other members as his
> "friends" or "contacts".
> Note that the invite case will use the same code, since you create an
> account for the person you're inviting and at some point he becomes a
> member.
I think it would be better to store their email address along with a stored
random key, rather than add a real user. Some reasons for this :-
- adding real users might have other implications... like if ldap was used.
- users need a userid. That would have to be changed during registration.
- users might register using a different email address than
- lots of unneeded users sitting around clogging up user searches.
So instead, the code I've started stores the invite code and sends out a
special url.
> What seems to be needed now, after reviewing all this, is go ahead to
> integrate with the work done by Christian and others, and move from
> "prototype" state to a real implementation for all the "invite" use cases.
Had a chat to Christian about this. The member interfaces you and Christian
are similar so it looks like module just to put all the member stuff would
be a good step. Plonesocial.memeber.common or something. Something that
could potentially go into the core. Ie, all the bits of your code without
Plone.relations.
> Now it's just occured to me that we need to study more requirements such
> as:
> - An invited user should be able to refuse an invitation, so should the
> plone.relations-based relation be workflowed or we can use the 'state'
> attribute that exists on it for that purpose.
Lets we had a state of "pending", "active", "refused" for contact
relationships... at the moment I can't think of a usecase that would be more
complicated than that. In fact for my usecase I want a single state "active"
but I can see "active", "refused" be useful too.
Perhaps for now we should keep it simple with a contact relation being a
name and state both strings?
> - Bi-directionnalily ? If I someone adds me as a friend, I should be able
> to see the relation coming to me, and might want to do something about it.
We can fake bidirection (symmetric) reltations in a higher layer by just
searching the network in both directions. ... actually since Plone.relations
has that nice transitive searching so that might not work.
We can setup relations in each direction but we'd have to take into account
state in both directions.
I think the next steps are
- finish the invite.base
- finalise the member interface stuff
- create a more fully formed contact/social graph ui. Something that can use
out of the box for a lot of sites and repurposed easily for others.
Like I've outlined in
http://groups.google.com/group/plone-social-networking/web/componentmodel
I suggest we use this and the use cases as a document to outline our plans.
Please feel free to change it.
And we probably need to settle on a naming convention.
> Cheers,
> Kamon
>
>
>
>
>
> >
Kamon Ayeva
In a buildout it should work, I suspect you have to get the egg metadata so buildout can see it.
So try, at the root of the plonesocial.socialgraph package, a "python2.4 setup.py egg_info" to generate the egg_info files.
Then you do the usual settings in your buildout.cfg.
Hope that helps.
-- Kamon
Hi Kamon,
I tried to download the plonesocial.socialgraph (I wanted to test)
code from
but I got an error message, I wanted to install it with easy_install
and buildout. I also tried a wget but got another error message.
is the code available for test now?
Gustavo
> This morning I committed the plonesocial.socialgraph code in the collective.https://svn.plone.org/svn/collective/plonesocial.socialgraph/trunk/
Dylan Jay
Here is the buildout fragment I used that got it installed. But nothing appeared in quickinstaller. Haven’t worked out why yet.
[buildout]
index = http://download.zope.org/ppix
# Add additional egg download sources here. dist.plone.org contains archives
# of Plone packages.
find-links =
http://download.zope.org/ppix/
http://download.zope.org/distribution/
eggs =
elementtree
plone.portlet.static
plone.portlet.collection
plonesocial.invite.base
plonesocial.socialgraph
develop =
src/plonesocial.invite.base
src/plonesocial.socialgraph
[plone]
recipe = plone.recipe.plone
[instance]
recipe = plone.recipe.zope2instance
eggs =
${buildout:eggs}
${plone:eggs}
zcml =
plone.portlet.static
plone.portlet.collection
plonesocial.invite.base
plonesocial.socialgraph
Kamon Ayeva
Does the product show up in Zope's products control panel ? If no, I am tempted to say the problem comes from the fact that the egg_info part is missing from what you checked out from the svn. And to correct that, you have generate the egg_info part manually (using the package's setup.py), and then re-run bin/buildout.
-- Kamon