[LovPy]PCS框架篇重构 建议
Zoom.Quiet
首先!通告一下大家,根据 Lisa 的要求,相关列表已经调整了编辑的订阅邮箱,迁移到了
xg....@gmail.com
这是为了更好的使用 列表,加强及时回复,所以,大家请修订 回复全部 时的邮箱,
将 yan...@broadview.com.cn 替换成 xg....@gmail.com
!!!!
> 今天分别与周琦和黄毅进行了电话沟通。
>
> 黄毅目前还在考虑框架篇到底该如何来写，今天晚上会给予说明，并尽快列出这一部分内容的大纲。
> 周琦则协助黄毅寻找对其中框架较熟悉的人根据黄毅列出的大纲来写作。
> 黄毅则会统领框架篇，把这些"珠子"串起来。
Lisa 忘记了俺反复强调的最核心的建议 ~ 撰写原则:
0. 对于Python 的 web 框架纵论, 应该中立和系统化,不能因为自个儿熟悉什么而忽视历史发展和现实着力去说,这对读者是种误导;
1. 要从读者角度,而不是开发者角度来叙述,,,
俺建议这章的开发流程是:
0. HY 提交撰写大纲
1. 开放式讨论,确认思路和内容规围和深度后,细化内容定义
2. 分头认领部分小节,组织各个领域专家进行撰写
3. 由HY 重新整合,整体调整成为风格统一的文章来
从俺的想象来看,这章的结构可以是:
Python Web应用框架纵论:
+-- 导论
| +-- 现状
| \-- 为什么Python 中有这么多框架?
+-- 分类
| +-- 如何来理解各种框架?
| +-- 框架的框架
| +-- 轻型框架
| \-- 一站式框架
+-- 细说(按照历史顺序,选择经典框架来介绍,没有PCS独立章节的,和故事没有直接提及的)
| +-- Zope/Plone (请潘俊勇撰写)
| +-- Quixote (请 阿北 撰写)
| +-- Django (HY自写)
| \-- UliWeb (请Limodou撰写)
+-- 选择
| +-- 个人
| +-- 团队
| \-- 企业
\-- 小结
\-- 选择的痛苦
>
>
> 2008-09-23
> ________________________________
> lisa
> ________________________________
> 发件人： Zoom.Quiet
> 发送时间： 2008-09-21 22:46:23
> 收件人： openboo...@googlegroups.com
> 抄送： zeuux-press
> 主题： [OBP:3255]_Re:_[OBP:3174]_Re:_今天的进度以及框架的安排
> 2008/9/21 黄毅 <yi.cod...@gmail.com >:
>> 还有就是考虑到 django 的流行程度，是否给Django来个这样的特殊待遇：Django快速体验教程 ;-)
>>
> 这方面俺建议 HY 单独积累些资料,日后专门出书,
> 因为 ,这本图书面向入门的小白们,突然上来那么多特殊概念吃不消的,
> 而且,故事里都是 Karrigell 突然来个强大多的 DJ, 读者会奇怪,为什么不用 DJ 来作?
>
>
>> 2008/9/21 黄毅 <yi.cod...@gmail.com >
>> >
>> > 恩，终于把自己的想法表达准确了，其实换个角度来说，这些
>>
>> > > web框架所提供的功能其实是一样的，就是做网站嘛，但是既然都是提供这一个功能为什么却产生这么多不同的工具呢？我想这个应该是框架介绍的关键了，就是框架之间的比较，不是介绍它们提供什么样的功能，而是它们都是些什么样的风格，分别适合哪些场景，而这些是需要综合起来看的。
>> >
>> > 我目前粗略的想法是这样的，首先目前框架主要分三大类：
>> > 轻量级框架：cherrypy、Karrigell （以PCS的形式）
>> > 完整的mvc框架：django、UliWeb、turbogears、pylons
>>
>> > > （这个能不能请limodou出山，这个他最有发言权了，顺便宣传他自己的框架那，哈哈）（关于这部份我目前的组织方法可能就是这样了：http://wiki.woodpecker.org.cn/moin/ObpLovelyPython/WebFrameworks）
>> > ZOPE/PLONE
>> >
>> > 这个内容究竟如何组织确实需要相关人员密切沟通才行。下周上7天班，时间又要少了。不过国庆又要来了。
>> >
>> >
>> > 2008/9/21 Zoom. Quiet <zoom....@gmail.com >
>> > >
>> > > 2008/9/21 黄毅 <yi.cod...@gmail.com >:
>> > > > 我对这本书的市场还是有信心的，这本书的方式也很有趣。
>> > > >
>> > >
>> > > > 我的问题只是具体到框架篇这里的组织，我也不喜欢《征服python》那样的书，但我觉得框架篇这里的问题恰恰是太像《征服python》了，列举了很多框架，但每一个都不能讲透。我觉得给读者的感觉就是从书本身看不到什么东西，好像一个索引，具体内容都得到链接里面去看。
>> > > >
>> > > Sure,,, 不过，已经有人说， CPyUG 只说Web 开发的事儿，其它的Python 也NB的都没有人讨论了，，，
>> > > 但是，谁叫Web开发的容易上手和出彩呢？
>> > >
>> > > > >
>> > > > > > 关于创作导向，从现在来看，本书的主线是2个故事，其他的内容都是围绕这2个故 事展开，因此，主次要分明，也是现在的原则。
>> > > >
>> > > >
>> > >
>> > > > 我很认同本书的这个创作意图，那么我建议去除一些无用的框架介绍，因为目前这样的介绍方法是没有抓到web框架的关键，反而可能误导读者，因为从这样的介绍看来，python的web框架世界是如此的杂乱。关键在于web框架不同与一个功能单一的模块，简单的介绍是不能达到目的的，甚至可能有反面效果。
>> > > > 另外又考虑到 web
>> > > >
>> > >
>> > > > 开发的重要地位的话，个人建议以一个附录的形式，系统地介绍python世界web框架的大致情况，主要是通过比较不同框架的异同，给读者一个完整的总体印象。之后读者会知道他需要什么，然后他再去找更详细的信息。
>> > > >
>> > >
>> > > 嗯嗯嗯！这种思路非常赞同,,,
>> > > 那么,就将 故事中提及的 CherryPy 和 Karrigell 以 PCS 的格式进行合理的详细解说,
>> > > 其它的都合并到 Python Web应用框架纵论一节,
>> > > 将我们长期以来对 web 开发方面 Python 能力和特性进行综合的描述,
>> > > 根据 HY 的知识框架,以 Django 和 UliWeb 作为对比主线,
>> > > 公平中立的,将Web 框架和Web 应用的发展和前沿技术都介�一下,
>> > > 在 PyLons 方面 ZSP 有长期的研究,而且对于 Karrigell 的多线程化,高效化也有研究,
>> > > JunYong Pan 对 Zope 体系的开发有最长期的研究,从Zope1 时代到Zope 3 都有企业级的开发体验,
>> > > 昨天在 OSCamp 2008 广州活动中,就对如何从 ZCA 过渡到 WSGI 组件式开发有精彩的分享,,,,
>> > >
>> > > 我想这一章,得多人严密协同,象论文一样的写,最后,还得俺来通俗化,令小白们可以看明白,
>> > >
>> > > 这样,一本图书中,有一节是非常非常有质量的内容,整体图书品质也可以提高一级的哪怕,,,,
>> > >
>> > > > 2008/9/21 Yan Sheng <lizz...@gmail.com >
>> > > > >
>> > > > >
>> > > > > 2008/9/21 Zoom. Quiet <zoom....@gmail.com >
>> > > > > >
>> > > > > > 2008/9/21 Bill Xu <bi...@zeuux.org >:
>> > > > > > > > BillXu ? 哲思社区的看法?
>> > > > > > > > 是想作本全新的面向开导思想的图书,还是复制又一本 "超越Python" 式的杂而全,但是没有灵魂的书?
>> > > > > > > >
>> > > > > > > 一本好书要有自己的思想和主线（创作导向），同时要有一定数量的目标用户（市 场导向）。
>> > > > > > > 关于创作导向，从现在来看，本书的主线是2个故事，其他的内容都是围绕这2个故 事展开，因此，主次要分明，也是现在的原则。
>> > > > > > >
>> > > > > > 是也乎,这是整体图书设计的原则,,,应该遵守,,
>> > > > > >
>> > > > > > > 我的疑问是图书市场是否需要这本书？这是需要我们一起去思考的。我们是否还需
>> > > > > > > 要根据现在的图书市场情况对此书的结构做一个调整？对此，我在想这个问题，大家的意见呢？
>> > > > > >
>> > > > > > 一个成熟的图书市场,必定支持不同层面的读者,
>> > > > > > Python 在中国远没有达到主流的地步,从TIOBE 全球排名来看:
>> > > > > > TIOBE Programming Community Index for September 2008
>> > > > > > http://www.tiobe.com/content/paperinfo/tpci/index.html
>> > > > > > 对应到图书市场根本没有达到相同的比例水平,
>> > > > > > 而且,在中国,对于 Python 还是未知的人群多,也即,初级入门图书的潜在市场从来不小,
>> > > > > > RobertChen 的源码解析,可以说是针对 C/C++资深开发人员了解python 的运行机制,给出了体验分享,
>> > > > > > 但是对于中国最多的 JAVA/PHP/VB/.NET 开发人员来说,快速体验Python 完全不同的开发思路和方式的入门图书,
>> > > > > > 根本没有,,,,
>> > > > > >
>> > > > >
>> > > > 虽然, Lovely Python 写了两年多,很多当时的新人,都已经是老鸟了,但是想一想中国每年计算机专业的大学生新增几十万,
>> > > > > > 而中国所有python 相关技术社区的注册人数加起来也没有超过 5万吧,
>> > > > > > 这是多大的差异和潜在的市场?
>> > > > > >
>> > > > >
>> > > > >
>> > > > > 对于这点，我在学校里待了这么多年，说说我的一些看法吧
>> > > > > 在我学校里，很多学生本科或者研究生，都是从c- >c++- >java这个线来的，之后根据每个人的不同状态或兴趣 选择.net
>> > > > >
>> > > >
>> > > > 或者j2ee系列。基本上是这两大阵营，而这些都不是老师们能教的，很多很多想深入学习的学生们都是通过图书馆借书，同样图书馆里这两块占了很大部分，其他的想php，python，perl，ruby是少之又少。为什么呢？！因为90%的学生和99%老师都不知道这些其他优秀的编程语言，python就是其中之一。像我现在全力鼓动周围，包括新进来的师弟师妹一起学习python，就当是兴趣学习。而他们刚开始连python是什么都不知道，就像是这世界除了c++和java就没其他语言了，可悲啊！！
>> > > > > 所以我觉得，如果有更多的人知道python，学的人自然而然多了。主要还是学生，中国有多多多大学生哪。。。。
>> > > > > 再来说说这本书，我是通过learning
>> > > > >
>> > > >
>> > > > python入门的，而接下来也没看什么其他书，仅仅是通过网上一大堆资料文档，想学什么用到什么时去理解相关内容，其中一大部分是英文文档，有时我都觉得头疼了。python各个部分内容还是非常多的，我想估计还没多少人能把这么多内容全部掌握的，其实也没什么必要一下子全部掌握，而是根据自己确切需要来的，慢慢深入。而这些都是依靠入门之后的！所以对于一个想了解并学习python的的人来说，一本入门级的书是非常非常重要的，就像是师傅领进门，修行靠自身了。而LovelyPython，当初我看得第一遍，尤其是CDays，第一感觉，funny，那种没想到技术书还能这样好玩的感觉，然后是告诉读者如何去解决一个问题的一种通用过程。而后面的PCS，尤其是我整理的那些，基本上都是文绉绉的，就是有种：没什么新意，也就那样，给一星期时间我也能写出来
>> > > > > 的那种感觉，呵呵，事实上，的确如此。所以，我觉得这本书应该是引导读者如何去深入，去思考，而不是直接告诉他该怎么办。
>> > > > > 希望LovelyPython可以实现这个目的。
>> > > > > 大家一起努力！！！
,,,
--
http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
[HR]金山软件常年招聘大量Py/C++人才!
https://groups.google.com/group/python-cn/web/ot-py-c
简历直投俺就好;-)
Zoom.Quiet
已经收录 HuangYi 撰写的相关文档到SVN 中,
请开展重构后, Huang Yi 及时进行SVN 的检入! 必要的话,及时调整PCS 3** 的结构:
+-- 框架篇 (Python 的应用框架介绍 PCS 300~399)
| +-- PCS300 WebAppFramworks 框架纵览
| +-- PCS301 CherryPy
| +-- PCS302 Karrigell
| +-- PCS303 LEO
| \-- PCS304 MoinMoin
...
????
2008/9/23 Zoom. Quiet <zoom....@gmail.com>:
黄毅
Zoom.Quiet
> 我倒是在考虑如何跟本书整体轻松小白的风格融合，所以我觉得可以直接借用
这是个好想法,不过时间真的来不及了哪,,,
> http://bitworking.org/news/Why_so_many_Python_web_frameworks
> 的思路？
> 我的意见是以小白自己写的探索日记的方式，记录小白探索web开发底层世界的经历。
那是小黑了,,,嗬嗬嗬,,,
> 可以放在本书的最后，在走完前面两个故事和所有PCS后，
> 小白逐渐成长了，同时发现自己面临的问题也越来越复杂起来，小白目前主要工作是做web开发的，他发现DB越来越复杂，业务逻辑也越来越多了，团队也大了，页面都有专们的制作人员来负责了。小白希望找到一种最合适自己项目以及团队协作的开发方式。
> 于是他毅然决然抛开当前用着的框架，决定从基本的工具出发，搭建自己的项目解决方案。同时记下了自己的探索历程，希望让后人可以少走弯路。
类似的文章,比如说: 寻找更好的模板系统记 - 魏中华 - 网易博客
http://blog.163.com/cqit_jsj/blog/static/651272200781104735593/
这种文章,我们看的非常爽,但是小白,甚至于小黑,由于没有自主创建/运营/维护过网站,
对于开发/维护效率,运营的访问压力,I/O 瓶颈等等所有层面的 Web 应用隠患都没有体验,
那是任我们装嫩来解说也是白搭的,
就好比和一位天生的盲人来形容什么是红色一样,,,
所以,对于Python 的Web 应用框架,俺的看法是:
0. 不试图令本书的读者变成靠谱的 Web 应用开发者;
1. 给读者展示Python 世界对 Web 应用这一领域生机勃勃的真实情景,进而产生信心和兴趣,就达到了图书的整体目的!
> 第一天，在行者的帮助下了解了 DMVC 的结构，发现了 wsgiref ，学会使用wsgiref自带的开发服务器，初步接触wsgi协议，以及发现了
> http://www.wsgi.org 这个web开发工具的仓库。
>
> 第二天，选择 request response 对象的实现
> 第三天，选择 URL 分发器
> 第四天，选择模板
> 第五天，选择 ORM （sqlalchemy莫属）
> 等等其他工具。
>
> 最后再简单推荐现成成熟框架的思想？
>
这等于是要在有限的篇幅里将一小白的见识,提高到 Limodou 那样的高度,,,
是否可以正确理解现有框架的设计思想,适用范畴都是非常非常困难的事儿!
更不要说精細的分析各种 ORM/模板/URL分发/响应处理/RESTful模式,,,
当然,这个思路,真的可以尝试写下去,成为 "定制自个儿的Web应用框架" 一书的主体内容,
但是,当前,俺推荐使用 PCS 的口气和思路,将 PythonWeb应用框架纵览 写到位,就成凫 ;)
大家看?
BillXu ? 你从现在的图书市场和本书的定位看呢?
--
黄毅
"""对于这点，我在学校里待了这么多年，说说我的一些看法吧
在我学校里，很多学生本科或者研究生，都是从c->c++->java这个线来的，之后根据每个人的不同状态或兴趣 选择.net 或者j2ee系列。基本上是这两大阵营，而这些都不是老师们能教的，很多很多想深入学习的学生们都是通过图书馆借书，同样图书馆里这两块占了很大部分，其他的想php，python，perl，ruby是少之又少。为什么呢？！因为90%的学生和99%老师都不知道这些其他优秀的编程语言，python就是其中之一。像我现在全力鼓动周围，包括新进来的师弟师妹一起学习python，就当是兴趣学习。而他们刚开始连python是什么都不知道，就像是这世界除了c++和java就没其他语言了，可悲啊！！
所以我觉得，如果有更多的人知道python，学的人自然而然多了。主要还是学生，中国有多多多大学生哪。。。。
再来说说这本书，我是通过learning python入门的，而接下来也没看什么其他书，仅仅是通过网上一大堆资料文档，想学什么用到什么时去理解相关内容，其中一大部分是英文文档，有时我都觉得头疼了。python各个部分内容还是非常多的，我想估计还没多少人能把这么多内容全部掌握的，其实也没什么必要一下子全部掌握，而是根据自己确切需要来的，慢慢深入。而这些都是依靠入门之后的！所以对于一个想了解并学习python的的人来说，一本入门级的书是非常非常重要的，就像是师傅领进门，修行靠自身了。而LovelyPython，当初我看得第一遍，尤其是CDays，第一感觉，funny，那种没想到技术书还能这样好玩的感觉，然后是告诉读者如何去解决一个问题的一种通用过程。而后面的PCS，尤其是我整理的那些，基本上都是文绉绉的，就是有种：没什么新意，也就那样，给一星期时间我也能写出来 的那种感觉，呵呵，事实上，的确如此。所以，我觉得这本书应该是引导读者如何去深入，去思考，而不是直接告诉他该怎么办。
希望LovelyPython可以实现这个目的。
大家一起努力！！！"""
黄毅
类似的文章,比如说: 寻找更好的模板系统记 - 魏中华 - 网易博客
http://blog.163.com/cqit_jsj/blog/static/651272200781104735593/
这种文章,我们看的非常爽,但是小白,甚至于小黑,由于没有自主创建/运营/维护过网站,
对于开发/维护效率,运营的访问压力,I/O 瓶颈等等所有层面的 Web 应用�患都没有体验,
那是任我们装嫩来解说也是白搭的,
就好比和一位天生的盲人来形容什么是红色一样,,,
所以,对于Python 的Web 应用框架,俺的看法是:
0. 不试图令本书的读者变成靠谱的 Web 应用开发者;
1. 给读者展示Python 世界对 Web 应用这一领域生机勃勃的真实情景,进而产生信心和兴趣,就达到了图书的整体目的!
这等于是要在有限的篇幅里将一小白的见识,提高到 Limodou 那样的高度,,,
是否可以正确理解现有框架的设计思想,适用范畴都是非常非常困难的事儿!
更不要说精�的分析各种 ORM/模板/URL分发/响应处理/RESTful模式,,,
当然,这个思路,真的可以尝试写下去,成为 "定制自个儿的Web应用框架" 一书的主体内容,
但是,当前,俺推荐使用 PCS 的口气和思路,将 PythonWeb应用框架纵览 写到位,就成凫 ;)
Zoom.Quiet
> ZoomQ 的这个提法我开始也是这么想的，就是把框架知识系统的整出来，但是后来讨论过程中在各位的批评中也确实感觉，跟整本书的调调不太搭，尤其是 liz
> 的评论：
>
>> """
>> 对于这点，我在学校里待了这么多年，说说我的一些看法吧
>> 的那种感觉，呵呵，事实上，的确如此。所以，我觉得这本书应该是引导读者如何去深入，去思考，而不是直接告诉他该怎么办。
>> 希望LovelyPython可以实现这个目的。
>> 大家一起努力！！！
>> """
>
> 所以我觉得保持整本书的有趣还是很重要的，目前web主流应该还是 java、dotnet、php ，其实 python
> 近几年还是吸引了一些眼球的（toibe年度语言，google的app engine
> ），所以听过这个名字的程序员肯定不在少数，但对python究竟有什么特点什么好处还没概念，在这个时候本书的出现很大一部分可以满足一下大家对 python
> 的好奇心，所以保持有趣还是很重要的。
> 对python好奇的观众应该大部分还是web开发人员，所以web框架的介绍是一定要有的，但要有趣，同时讲到点子上。
> 所以我觉得可以弱化对主流框架本身的介绍，主流框架光通过书本也确实很难介绍完全，读者终究要循着链接去找很多详细内容，所以我觉得更重要的是激发大家伙的好奇心和兴趣吧。
>
这应该不是真的卟,
就我们的调查,使用 Python 是因为其 Web 开发能力的,占的并不多,
大多是用来代替妖异的 Perl ,太简单的 Shell ,成为系统管理方面的好助手,
而且很多VB/C 的程序,可以快速通过 Python 重构成更加好维护的小脚本,
不过,有趣这方面俺想起另外的写法:
Python 历史书· GUI 部
http://wiki.woodpecker.org.cn/moin/PyHiStory/PyGuiHistoric
可以参考着组织成
Python 历史书· WEB 部
是也乎?
将 各个框架产生的时代背景,经典应用和网站交待一下,
不用涉及过多的技术细节和深入的思想,
就是将这一精彩的世界进行 纵论 即可!
是也乎?
黄毅
这应该不是真的卟,
就我们的调查,使用 Python 是因为其 Web 开发能力的,占的并不多,
大多是用来代替妖异的 Perl ,太简单的 Shell ,成为系统管理方面的好助手,
而且很多VB/C 的程序,可以快速通过 Python 重构成更加好维护的小脚本,
黄毅
不过,有趣这方面俺想起另外的写法:
Python 历史书· GUI 部
http://wiki.woodpecker.org.cn/moin/PyHiStory/PyGuiHistoric可以参考着组织成
Python 历史书· WEB 部
是也乎?
将 各个框架产生的时代背景,经典应用和网站交待一下,
不用涉及过多的技术细节和深入的思想,
就是将这一精彩的世界进行 纵论 即可!是也乎?
Zoom.Quiet
>> 不过,有趣这方面俺想起另外的写法:
>> Python 历史书· GUI 部
>> http://wiki.woodpecker.org.cn/moin/PyHiStory/PyGuiHistoric
>>
>> 可以参考着组织成
>> Python 历史书· WEB 部
>> 是也乎?
>> 将 各个框架产生的时代背景,经典应用和网站交待一下,
>> 不用涉及过多的技术细节和深入的思想,
>> 就是将这一精彩的世界进行 纵论 即可!
>>
>
好哪! 沈游侠自个儿的 eurasia - Google Code
http://code.google.com/p/eurasia/
本身就是多年不断淘汰各种 Web 应用框架后的产物,,,
可以特邀来 续写 WEB部的, 而且其它 部 一直有计划写的,,,
http://wiki.woodpecker.org.cn/moin/PyHiStory
比如说 Core部 可以陈濡来写
Module 部 可以由 ZSP 来写
,,,
黄毅
>> 不过,有趣这方面俺想起另外的写法:> 这个太强悍了，强烈要求请沈大侠出山那！！哈哈。
>> Python 历史书· GUI 部
>> http://wiki.woodpecker.org.cn/moin/PyHiStory/PyGuiHistoric
>>
>> 可以参考着组织成
>> Python 历史书· WEB 部
>> 是也乎?
>> 将 各个框架产生的时代背景,经典应用和网站交待一下,
>> 不用涉及过多的技术细节和深入的思想,
>> 就是将这一精彩的世界进行 纵论 即可!
>>
>
好哪! 沈游侠自个儿的 eurasia - Google Code
http://code.google.com/p/eurasia/
本身就是多年不断淘汰各种 Web 应用框架后的产物,,,
可以特邀来 续写 WEB部的, 而且其它 部 一直有计划写的,,,
比如说 Core部 可以陈濡来写
Module 部 可以由 ZSP 来写
Zoom.Quiet
> 2008/9/23 Zoom. Quiet <zoom....@gmail.com>
>>
>> 2008/9/23 黄毅 <yi.cod...@gmail.com>:
>> >> 不过,有趣这方面俺想起另外的写法:
>> >> Python 历史书· GUI 部
>> >> http://wiki.woodpecker.org.cn/moin/PyHiStory/PyGuiHistoric
>> >>
>> >> 可以参考着组织成
>> >> Python 历史书· WEB 部
>> >> 是也乎?
>> >> 将 各个框架产生的时代背景,经典应用和网站交待一下,
>> >> 不用涉及过多的技术细节和深入的思想,
>> >> 就是将这一精彩的世界进行 纵论 即可!
>> >>
>> > 这个太强悍了，强烈要求请沈大侠出山那！！哈哈。
>> >
>> 好哪! 沈游侠自个儿的 eurasia - Google Code
>> http://code.google.com/p/eurasia/
>> 本身就是多年不断淘汰各种 Web 应用框架后的产物,,,
>>
>> 可以特邀来 续写 WEB部的, 而且其它 部 一直有计划写的,,,
>> http://wiki.woodpecker.org.cn/moin/PyHiStory
>> 比如说 Core部 可以陈濡来写
>> Module 部 可以由 ZSP 来写
>
>
> 这个就确定这么来安排了么？编辑意见如何？
> 找人的事情还是ZoomQ来吧，我都不熟啊。
>
不过,内容责任人还是HY哪,
和另外撰写方式一样,先写出提纲来哪,,,
以便给其它大牛一个可以参考的框架?!??!
...
黄毅
Zoom.Quiet
>
>> 大家看?
>> BillXu ? 你从现在的图书市场和本书的定位看呢?
>>
>
> 一本书要有定位和特色，大而全（虽然也是特色）无论在写作难度和读者体验上看 都是不好的。
>
> 如果大家认为此书的读者群是入门的，点到为止也未尝不可，深入内容可以在下一 本书里讲。在下一本书里，我们可以讲小白长大了，认为之前理解的东西有问题，
> 需要重新思考，重新认识所谓的框架的问题，然后又开始了新的旅程。。。。。。
这方面是可以组织的,思路是通的,但是时间问题了,,,
实例故事要有代码支撑的,无法一蹴而就的,,,
Zoom.Quiet
0. 是否有时间来写?
1. 怎么写是在我们的PCS框架之内的?
2. 什么时候交付?
3. 交付指标如何?
4. 是否合理合情?
,,,
这相关非常宽广的技术见识,不是出版社文字编辑,和技术校对团队可以担当的,
如果,按照这个思路想快速撰写完成,
必定要有位热心的技术责编的,从现在来看 就黄毅 你思考这方面最久,只能由你担当哪,,,,
得及时/有效的协调 沈崴, 在PCS 框架介绍的思想范围内,将确认了的技术背景/设计思想等等有趣顺畅的组织成文,,,
是也乎!?
,,,
Zoom.Quiet
>
>> 这方面是可以组织的,思路是通的,但是时间问题了,,,
>> 实例故事要有代码支撑的,无法一蹴而就的,,,
>>
>
> 所以这是一本新书的工作量，在现在这本书里就没有精力去展开了。
是也乎，是也乎，已经建议HY继续收集和努力，争取形成另外的原创图书，
不过，现阶段，已经确认进行 精简化的 Python Web 应用框架纵览 的组织，
大致框架 Lisa 逐一确认中，俺得到的消息是:
0. 重点介绍 Zope/Quxoite/Django/UliWeb 框架
1. 简介一批有特色的框架
2. CherryPy/Karrigell 独立用 PCS 条目进行解说
俺强调的 组织原则:
0. 对于Python 的 web 框架纵论, 应该中立和系统化,不能因为自个儿熟悉什么而忽视历史发展和现实着力去说,这对读者是种误导;
1. 要从读者角度,而不是开发者角度来叙述,,,
所以，得在纵览中体现:
A: 这么多框架间的关系,设计思想脉络
B: 模板系统可以说是开发过程中直接面对的最大工作量方面了,应该有所介绍,,,
以上!
请 Lisa HY 继续补充,,,
yang lisa
导论
介绍历史和现状，然后简单地分类。
框架细述
三个轻量级框架（按PCS格式来写）
PCS cherrypy
PCS Karrigell
PCS Web.py
完整的mvc框架
Django（黄毅撰写）
概述
特性介绍
快速起步（新建项目）
案例讲解
小结（比如说适用范围）
Zope/Plone (请潘俊勇撰写)
概述
特性介绍
快速起步（新建项目）
案例讲解
小结（比如说适用范围）
Quixote (请 阿北 撰写)
概述
特性介绍
快速起步（新建项目）
案例讲解
小结（比如说适用范围）
UliWeb (请Limodou撰写)
概述
特性介绍
快速起步（新建项目）
案例讲解
小结（比如说适用范围）
_______________________________________________
zeuux-press mailing list
zeuux...@zeuux.org
http://www.zeuux.org/mailman/listinfo/zeuux-press
yang lisa
Zoom.Quiet
> 忘了改，黄毅建议把"完整的mvc框架"改为"重量级框架"，与轻量级框架对应。
>> 框架篇
什么意思? PCS 的框架篇,整理到一个大文章中了?
那么故事中,引发的 CharryPy 和 Karrigell 的扩展解说,怎么指引?
>> 导论
>> 介绍历史和现状，然后简单地分类。
怎么分类?按照以下的轻重划分? 这忒不负责了吧,,,
>>
>> 框架细述
>> 三个轻量级框架（按PCS格式来写）
>> PCS cherrypy
>> PCS Karrigell
>> PCS Web.py
>>
>> 完整的mvc框架
>> Django（黄毅撰写）
>> 概述
>> 特性介绍
>> 快速起步（新建项目）
>> 案例讲解
>> 小结（比如说适用范围）
>> Zope/Plone (请潘俊勇撰写)
>> 概述
>> 特性介绍
>> 快速起步（新建项目）
>> 案例讲解
>> 小结（比如说适用范围）
>> Quixote (请 阿北 撰写)
确认阿北太忙,没有空,由豆瓣算法组的 "Qiangning Hong" <hon...@gmail.com> 代笔,
需要编辑正式电话和邮件确认,,,
>> 概述
>> 特性介绍
>> 快速起步（新建项目）
>> 案例讲解
>> 小结（比如说适用范围）
>> UliWeb (请Limodou撰写)
>> 概述
>> 特性介绍
>> 快速起步（新建项目）
>> 案例讲解
>> 小结（比如说适用范围）
>>
没有总结性的建议?综论?学习建议?
没有模板系统的介紹?
>>> >> >> > 2008/9/23 Zoom. Quiet <zoom....@gmail.com>
,,
,,,
黄毅
Zoom.Quiet
所以,俺有个选择,决策建议的小节哪,,,
Pythonic 的工程观点是够用就好,简单为佳,
这也是可以引出的好话题,
不过,时间不足,先保证交付吧,
然后在电子版本释放时,追加进来,接受意见,合并到再版 LovPy 中吧,,,
> UliWeb 的话 Limodou 不是说还在开发中？
>
早已可用了,而且是综合了多年框架使用的体验的独立思考成果,有经验介绍的价值;
黄毅
Zoom.Quiet
> 忘了又回复全部了。
> 关于框架之间的不同风格和设计思路，我觉得 django、turbogears、pylons三个比较还是体现得比较突出的。
> python最好的几个模板系统的代表也恰恰就是django、turbogears、pylons三个框架默认带的三个（django的弱点，但jinja很好，jinja是直接继承django的模板语法）。
> 开始给我安排的这章是 django、turbogears、pylons
> 一起讲，我觉得体例上又不太和谐，而且我觉得6个大框架3个小框架太多了，对读者来说选择起来是个难题。所以就只说 django 了。
> UliWeb 的话 Limodou 不是说还在开发中？
> 总之，这么多框架，读者会不会反感？学模块篇的话好歹每一个模块都是干不同的事情的，每学一个模块都是学到了新东西。
> 但框架篇，学来学去，都是在学做一件事情。
所以,哪,框架篇的重点传达是:
0. 故事中提及的框架的深入使用
1. Python 世界中其它的优秀框架作品有哪些?
2. Pythonic 的web 应用理念
整个图书的核心述求就是: 开拓视野,认识Python ,引发兴趣,建立信心!
黄毅
Zoom.Quiet
> 所以我又想，咱别整框架了吧，框架跟这本书不太合，咱还是整web模块吧，wsgiref、sqlalchemy、mako
> 等，每一个都是实实在在的知识，框架讲起来有点虚。模块篇可以整多一点，对读者来说，不断学习新的东西还是比较愉快的。
>
对于模块，还是框架，俺就想问一声，是直接用模块来完成网站方便，还是框架？
黄毅
>> >>> 没有模板系统的介�?