09年9月4日工作记录
SNS总体计划、时间大概估计和沟通
相册的详细计划
状态更新的详细计划
邀请的详细计划
新鲜事的设计思路
Pinax的邀请注册
主要涉及的apps：friends_app 和 friend，其中friends_app负责提供models JoinInvitation 和 Contact。
流程：
用户首先要从 google 或者 yahoo 引人联系人，或者从vCard上传联系人 Contact。地址：/invitations/contacts/
脱钩步骤，应该是可能邀请所有的 Contact 进入网站的。不过目前还没有这个功能，只能发送邀请给单个用户。
邀请一个用户的机制，访问 /invitations/ ，可以输入 email 和消息，邀请一个人加入。
friends.forms.JoinRequestForm首先会检测使用该邮箱的用户是否已经注册，如果有就raise(friends.forms)
调用 friends.models.JoinInvitationManager.send_invitation 发送邀请邮件，建立JoinInvitation。
用户点击邀请注册链接，将被导向 friends_app.views.accept_join。
使用 account.forms.SignupForm 表单、account.views.signup 来处理，如果有邀请码，调用 friends.models.Join_invitation.accept(new_user)。
相册计划
预计时间：3天
models
相册包含：
标题
描述
封面图片
到图片的多对多关系
用户
……
图片包含：
标题
描述
……
功能
添加相册
删除相册
编辑相册
设置封面图片
给相册添加图片
从相册删除图片
编辑相册的图片
全站相册
好友相册
我的相册
指定用户的相册
暂时就想到这么多。
状态更新计划
新建image size
models
用户
时间
文字
图片
功能
ajax化
给状态添加图片
ajax化图片上传
采用人性方式显示时间，例如：1分钟前，2小时前，1天前。
……
邀请注册计划
预计时间：5－10天
Models
参考friends.models.JoinInvitation, InvitationManager
Forms
参考account.forms.SignupForm
流程
一个页面，两个view
view1 从 google 导入联系人或者，
view2 从 yahoo 导入联系人。
不采用 Pinax 的 Contact model 设计，另外设计 model 来存储导入的联系人。
邀请view
显示所有的联系人，区分是否已经注册，对未注册的联系人显示复选框，选择是否邀请。
点击邀请之后给每一个选中的联系人的邮箱发送邀请(应该是form完成)。
检验是否有的被邀请者已经注册，如果有就不发送邀请。
用户点击邀请url
邀请的 url 使用修改的 register view 处理，使用专门的 register form。
区别于 Satchmo 的内置 register view 和 form，直接 activate。
要验证邮箱是否已经注册，否则可能有逻辑错误。
将邀请者与被邀请者直接加为好友。
新鲜事设计
已有设计
找到了一个比较好的新鲜事设计：
http://www.javaeye.com/wiki/Python/1361-django-39-s-use-of-signals-and-the-realization-of-new-features-contenttypes
给出了部分代码，创建新鲜事的代码已经有了，但是至少还需要有删除新鲜事的代码。
优点
1. 这个设计的好处就是 signals 比较灵活，修改的代码量比较小。
2. 而且 description 接口很简单。
缺点
1. 但是如果采用这个设计数据库的压力会比较大，因为读取一个新鲜事列表可能要涉及 n 个表。
2. 修改量小，但是还是需要修改所有想要支持新鲜事的models的代码，部分models在satchmo的源代码中，不太适合更改。
我的设计
基本维持原来的设计，但是 description 接口要将描述记录在数据库中，而不是从object里动态读取出来，这样可以减小数据库的压力。
另外，想办法将 description 从 model 定义中移出来，不然还要去挨个app的改源代码，不太现实。
（暂时还没想到办法，大概思路是类似notification的模板机制。）
和上面的方案相比：
优点
1. 数据库压力会小很多，而且保留了 signal 的灵活性。
2. (如果能实现的话)将所有的逻辑集中于一处，不需要把代码散落在各个app里(notification就是散落在各个app里的)。
缺点
1. 和上面的方案对比，牺牲了一定的灵活性。比如说，想修改某个事件的description，上面的方案的修改会应用到所有的新鲜事，
而我的设计，只会应用到设置变更之后建立的新鲜事。