[IDEA]使用Django开发一个协作平台
limodou
2.0式的平台，而且是使用django开发的，它可以有：
message交流系统，象豆瓣，比论坛可能简单些
group管理，不要求有太多的权限控制。以前我曾经想实现细粒度的角色，权限，发现管理很麻烦。还是简单的：系统管理员，小组管理员，成员就可以了
文档管理
任务管理
日程管理
问题管理
...
主要想法是在实现这个平台的同时把一些基本的东西转为可复用的东西，同时有一个源代码可以随时增加新的功能。
--
I like python!
UliPad <<The Python Editor>>: http://wiki.woodpecker.org.cn/moin/UliPad
My Blog: http://www.donews.net/limodou
刘鑫
--
欢迎访问：
http://blog.csdn.net/ccat
刘鑫
March.Liu
刘鑫
limodou
> 非常有用的东西，Google不就在发展类似的平台么？源代码服务器我们也可以嵌入SVN。
>
> 在06-12-1，limodou <lim...@gmail.com> 写道：
> > 在一个团队中，如果有一个协作平台我想会非常方便。目前常有的方式可能有：论坛，wiki,
> Trac等。但我更希望有一个web
> > 2.0式的平台，而且是使用django开发的，它可以有：
> >
> > message交流系统，象豆瓣，比论坛可能简单些
> >
> group管理，不要求有太多的权限控制。以前我曾经想实现细粒度的角色，权限，发现管理很麻烦。还是简单的：系统管理员，小组管理员，成员就可以了
> > 文档管理
> > 任务管理
> > 日程管理
> > 问题管理
> > ...
> >
> > 主要想法是在实现这个平台的同时把一些基本的东西转为可复用的东西，同时有一个源代码可以随时增加新的功能。
因为我想这样的平台涉及到了许多方面的内容，有web
2.0的东西，有django本身的东西，我还想使用jQuery作为ajax的应用层，再有一些常见的web处理，如：定制基本的web元素，css等，form处理，错误处理，ajax通讯格式等，再有一些常见的web功能，如认证码什么的。这样随着发展，可以有越来越多可重用的东西，再开发类似的东西，可以把它做为一个代码仓库，可以节省许多的时间了。
woodlog有许多东西都没有实现，也许这个平台可以去做许多有趣的东西。
limodou
>
你的这个建议目前可能太具体了，现在主要是在协作上的设计。
小河
limodou
> 非常愿意参加....呵呵，这样django的发展就快了许多了，学习起来也快许多....
>
现在还是一个IDEA，还没有发展到开发一个项目。我手头到是有一些基础的代码，里面还乱七八糟呢，问题百出，许多功能还都没有，有时间放出来给感兴趣的人看一看。基本界面我都是copy
basecamp的。
Zoom.Quiet
> On 12/1/06, 小河 <hek...@gmail.com> wrote:
> > 非常愿意参加....呵呵，这样django的发展就快了许多了，学习起来也快许多....
> >
首推 trac 平台哪!
协作平台的要点在协作,而不是管理;
使用ISSUEtrcker 系统追踪一切;
使用维基组织一切文本和附件;
利用可定制的reporter 进行各种统计;
利用SVN 进行版本管理;
利用mailist来统一交流,
此平台堪用矣！
> 现在还是一个IDEA，还没有发展到开发一个项目。我手头到是有一些基础的代码，里面还乱七八糟呢，问题百出，许多功能还都没有，有时间放出来给感兴趣的人看一看。基本界面我都是copy
> basecamp的。
>
> --
> I like python!
> UliPad <<The Python Editor>>: http://wiki.woodpecker.org.cn/moin/UliPad
> My Blog: http://www.donews.net/limodou
>
--
'''Time is unimportant, only life important!
blog@ http://blog.zoomquiet.org/pyblosxom/
wiki@ http://wiki.woodpecker.org.cn/moin/ZoomQuiet
douban@ http://www.douban.com/people/zoomq/
____________________________________
Please use OpenOffice.org to replace M$ office.
http://zh.openoffice.org
Please use 7-zip to replace WinRAR/WinZip.
http://7-zip.org/zh-cn/
You can get the truely Freedom from software.
'''
tdus lost
limodou
> On 12/1/06, limodou <lim...@gmail.com> wrote:
> > On 12/1/06, 小河 <hek...@gmail.com> wrote:
> > > 非常愿意参加....呵呵，这样django的发展就快了许多了，学习起来也快许多....
> > >
> 作为DJ 的应用产品,可以参考已经成熟的相似产品的结构进行DJ化重构,
> 首推 trac 平台哪!
> 协作平台的要点在协作,而不是管理;
> 使用ISSUEtrcker 系统追踪一切;
> 使用维基组织一切文本和附件;
> 利用可定制的reporter 进行各种统计;
> 利用SVN 进行版本管理;
> 利用mailist来统一交流,
> 此平台堪用矣！
>
2.0。甚至不能转到其它的数据库(当然我并不一定需要)。还有许多功能，如日程表等没有。主要是扩展起来可能没有django方便。不过我的确没有读过trac的代码，而且它许多地方的确做得不错。不过，我考虑在更多的情况下，我需要的是一种开发能力，而不是一种使用能力。有些东西现成的没有，改造的话就要看你对它的了解程度了，而且trac本身有自已的定位。如果可能的话，自已做一个，既锻炼了开发能力，而且在开发过程中可以积累许多重用的东西，再实现或改造的时候要感觉轻松的多。开发与使用的差别很大。会用并不一定会做。
Zoom.Quiet
> On 12/1/06, Zoom. Quiet <zoom....@gmail.com> wrote:
> > On 12/1/06, limodou <lim...@gmail.com> wrote:
> > > On 12/1/06, 小河 <hek...@gmail.com> wrote:
> > > > 非常愿意参加....呵呵，这样django的发展就快了许多了，学习起来也快许多....
> > > >
> > 作为DJ 的应用产品,可以参考已经成熟的相似产品的结构进行DJ化重构,
> > 首推 trac 平台哪!
> > 协作平台的要点在协作,而不是管理;
> > 使用ISSUEtrcker 系统追踪一切;
> > 使用维基组织一切文本和附件;
> > 利用可定制的reporter 进行各种统计;
> > 利用SVN 进行版本管理;
> > 利用mailist来统一交流,
> > 此平台堪用矣！
> >
> 如果不考虑定制的话Trac可能不错了。但它不够web
> 2.0。甚至不能转到其它的数据库(当然我并不一定需要)。还有许多功能，如日程表等没有。主要是扩展起来可能没有django方便。不过我的确没有读过trac的代码，而且它许多地方的确做得不错。不过，我考虑在更多的情况下，我需要的是一种开发能力，而不是一种使用能力。有些东西现成的没有，改造的话就要看你对它的了解程度了，而且trac本身有自已的定位。如果可能的话，自已做一个，既锻炼了开发能力，而且在开发过程中可以积累许多重用的东西，再实现或改造的时候要感觉轻松的多。开发与使用的差别很大。会用并不一定会做。
>
trac-admin 的工具作的就非常好，整个trac 没有所谓后台，
仅仅有一 trac-admin 的命令行工具来进行唯一的DB字段控制，非常干净，
但是可制程度也非常的高，
关键是已经得到认可，越來越多的项目启动trac 来管理；
就是因为安装和使用简单，没有过多的学习过程；
这种多合一的，预先功能完整支持的的结构，应该进行仿制
> --
> I like python!
> UliPad <<The Python Editor>>: http://wiki.woodpecker.org.cn/moin/UliPad
> My Blog: http://www.donews.net/limodou
>
limodou
> > 2.0。甚至不能转到其它的数据库(当然我并不一定需要)。还有许多功能，如日程表等没有。主要是扩展起来可能没有django方便。不过我的确没有读过trac的代码，而且它许多地方的确做得不错。不过，我考虑在更多的情况下，我需要的是一种开发能力，而不是一种使用能力。有些东西现成的没有，改造的话就要看你对它的了解程度了，而且trac本身有自已的定位。如果可能的话，自已做一个，既锻炼了开发能力，而且在开发过程中可以积累许多重用的东西，再实现或改造的时候要感觉轻松的多。开发与使用的差别很大。会用并不一定会做。
> >
> 是也乎，就是这意思，
> trac-admin 的工具作的就非常好，整个trac 没有所谓后台，
> 仅仅有一 trac-admin 的命令行工具来进行唯一的DB字段控制，非常干净，
>
> 但是可制程度也非常的高，
>
> 关键是已经得到认可，越來越多的项目启动trac 来管理；
> 就是因为安装和使用简单，没有过多的学习过程；
> 这种多合一的，预先功能完整支持的的结构，应该进行仿制
>
这是一个我现在手头做的一个界面，用户信息：
http://blog.donews.com/images/blog_donews_com/limodou/88791/o_ppp.jpg
phen...@gmail.com
我也一直希望我们实验室可以有这样的一个管理的系统.
期待可以得到进一步的信息
Nick Cen
在 06-12-1，phen...@gmail.com<phen...@gmail.com> 写道：
> 恩, 的确很不错的想法,
> 我也一直希望我们实验室可以有这样的一个管理的系统.
> 期待可以得到进一步的信息
>
limodou
> 是不是一定要推倒重来了？能不能使用类似mashup的方法，把你想要的功能架在一些已经有的系统上面，反正都是web应用。
>
首先我的平台建立在django上。目前在django上已经存在了论坛，wiki，还有图片服务(不知道是不是开源)。但协作平台好象还没有，而且它们的界面风格与我想像得不同。所以要做，我喜欢白手起家。这不算是扒推倒重来，因为根本自已还没有现成的。我认为这正好是一个积累经验的过程。而且我不希望是简单地通过链接联在一起，而是底层也是一致的(django)。所以如果没有可以参考的，只能是重来。
不过web这东西与操作，体验，界面密切相关，能重用的只是一些代码片段，css,
js等，太完整的东西很难重用，除非你不想怎么改它，只能用一部分。所以这种重用需要自已本身有很深的体会和经验，不然都不知道哪些可以重用。我还是更看重在开发中积累经验，而不是在使用中积累。需要有自已的东西。
Nick Cen
在 06-12-1，limodou<lim...@gmail.com> 写道：
limodou
>
我的出发点当然不主要是从用户角度出来，因为这个项目还没有呢，我将既是用户又是开发者。作为用户我希望它简单，好用。但作为开发者我要关心我使用什么样的平台。我当然希望使用有前途，自已又熟悉的东西来做了。
Nick Cen
在 06-12-1，limodou<lim...@gmail.com> 写道：
limodou
>
太绝对也不好。可以适量。至于rest，django目前还不支持。而你可以在django中实现近似的功能。使用ajax是不错，但会增加编程的复杂度，所以可以有选择的使用。很理想的模式很难。我想只要够方便，适合自已的习惯，结合一下也无所谓，只要能够理解清晰一些就好了。以前我也很想理想设计一些，但发现现实中的风格差异非常大，很难做到。
Nick Cen
在 06-12-1，limodou<lim...@gmail.com> 写道：
头太晕
limodou
limodou
> 我觉得rest的实现不会太困难，当然绝对了我也觉得不好。我觉得用django现在比较大的一个问题就是你不能在template里面直接嵌入python代码，而tag和filter又有一定限制，虽然django提供了比较大部分通用的tag，但是我觉得django如果不能解决这个问题，还是会受到一定限制的。
>
gas...@gmail.com
> > 是不是一定要推倒重来了？能不能使用类似mashup的方法，把你想要的功能架在一些已经有的系统上面，反正都是web应用。
> >
> 首先我的平台建立在django上。目前在django上已经存在了论坛，wiki，还有图片服务(不知道是不是开源)。但协作平台好象还没有，而且它们的界面风格与我想像得不同。所以要做，我喜欢白手起家。这不算是扒推倒重来，因为根本自已还没有现成的。我认为这正好是一个积累经验的过程。而且我不希望是简单地通过链接联在一起，而是底层也是一致的(django)。所以如果没有可以参考的，只能是重来。
>
> 不过web这东西与操作，体验，界面密切相关，能重用的只是一些代码片段，css,
> js等，太完整的东西很难重用，除非你不想怎么改它，只能用一部分。所以这种重用需要自已本身有很深的体会和经验，不然都不知道哪些可以重用。我还是更看重在开发中积累经验，而不是在使用中积累。需要有自已的东西。
>
有时候不见得推倒重来是个坏方法.
所有项目都是从无到有.
特别是这个语言上还没人整合过的时候.
如果要建在已有内容整合平台上,Java 的 Joomla
是很好的选择, 但 Joomla 也是在已经有现成的 PHPNuke ->
Xoop 这种 PHP 整合平台发展许久之后另起炉灶的.
提到 python 协作平台我第一个想到的是 WSGI , WSGI
的概念是不用管后端是使用哪个 Python web 框架,
只要支援 WSGI 介面, 这些 web 服务就可以合作.
用共同的 WSGI 介面, 让大家可以用偏好的 python web
工具制作模组.
如果要规划作长期项目的话, 大家该组织一下研究
WSGI, 不要在各个 python 框架中还各自划山头.
这是我的想法
安装配置部份, python 有很优雅的解决方法,
感兴趣的人可以看看 TurboGears 文件中关于发布 egg
跟如何在程式中插入 entrypoint 使程式更有弹性的作法.
(下面的文件与框架本身无关, pylons 等框架也适用)
http://docs.turbogears.org/1.0/DeployWithAnEgg
http://docs.turbogears.org/1.0/MakingYourAppExtensible
包装好 egg 简单的传上 cheeseshop,
要安装的时候用 easy_install, 要什么功能就抓什么功能.
感觉起来就很 pythonic.
Nick Cen
在 06-12-1，limodou<lim...@gmail.com> 写道：
limodou
> 还是一个度的问题吧。至于界面的话我觉得就是一个控件定义的方式问题，好像turbogear是支持定义服务器端的控件，如果是ajax的话，我知道的是dojo可以定义客户端的控件，这两种方式都可以比较好的分离表现与内容。
>
limodou
tg我都不太了解。django现在发展得也很快，有些东西都没有时间关注呢。我相如果在底层构建上如果已经有比较周到的解决方案，也许可以考虑。但如果是我做，可能没有这个能力。而且这样的网站，界面与功能更重要，而且之所以我希望使用django，一方面是因为我个人比较了解，另外我就是希望可以有一个统一的底层，不希望有不同的技术，这样需要了解和掌握的东西太多了。以后项目的维护会是一件麻烦的事。虽然都是python的东西，但差别还是很大的，组织方式，思想都不同。如果有兴趣，到是可以先并行，然后再考虑如何结合。如果一上来就想到结合，拿不出一个东西来的话，很有可能项目做不下去。我不想在底层的框架上花费太多时间，因为这一方面是本人不擅长，而一方面我不希望这个项目变得复杂，不可控。