蟒样Web开发，TOC第二版
xrfang
1）部分的名字有点不伦不类，和下面章的名字风格不一致。我只是想到了这个用以分类，暂时用一下
2）原来想写一个案例系列的，现在我想有点不好安排（因为读案例的同时有很多用到的概念、技术，如果不详细说，读者要翻到后面具体章节（例如
Sessions）查看；如果详细说了，后面说什么去？）我想这样，整个案例系列揉合到第二部分和第三部分的各个章节中。
3）第五部分，各个python框架的比较，有没有必要写？
4）全书大体上没有太大难度，我个人感觉第十六章有点难度，因为webpy本身的文档不全；第十五章也是比较难的。
5）另外，我对第十章的安排也感觉不太舒服。
希望大家看看有什么漏掉的，分类不合理的地方。如果大的部、章定下来了，我下一步会细化每一章的内容再提交大家提意见！谢谢！
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
蟒样Web开发（Pythonic Web Development with Web.Py）
前言（本书的目的、如何使用本书等）
第一部分 进入蟒记餐馆
第一章 Web系统是如何工作的
第二章 Python语言简介
第三章 为什么要用Python写Web应用程序
第四章 为什么我们选择Web.Py
第二部分 Web.Py菜谱
第五章 Web.Py应用架构（URL架构、sub-application、Static File等等）
第六章 输入和输出（介绍web.input()、web.ctx、改变输出类型（例如输出XML）、文件上传、forms等）
第七章 状态管理（Session和Cookie）
第八章 模板系统（Templator和其他第三方模板系统）
第九章 使用数据库（包括WebPy自己的系统和使用第三方库例如SQLAlchemy）
第十章 外部接口（发送邮件、WebService、Ajax应用）
第十一章 国际化的Web.Py应用
第三部分 Web.Py工程
第十二章 开发和测试Web.Py应用（开发环境、如何Debug、如何测试等）
第十三章 源代码管理和持续集成
第十四章 布署Web.Py应用（包括Apache、NginX、Lighttpd、SSL、Auth系统）
第十五章 高性能Web.Py应用（用后台进程提高客户端反应速度、数据库连接池、Memcached、前端优化、AB测试、搜狐闪电邮的案例等等）
第四部分 Web.Py秘籍
第十六章 Web.Py API详解
第十七章 FastCGI和SCGI技术规范介绍
第十八章 WSGI技术规范介绍
第五部分 蟒记餐馆菜系大比拼（都以一个HelloWorld或略为复杂一点点的基本的Tutorial方式来写，加上Pros/Cons的评价。）
第十九章 Django
第二十章 Pylons
第二十一章 Web2Py
第二十二章 TurboGears
第二十三章 CherryPy
第二十四章 Karrigell
第二十五章 PyHP
Zoom.Quiet
> 以下是我经过考虑略为细化的TOC。在诸位细看之前，我先说明一下目前的问题：
>
soo great!
只是第一和第五部分，只要写出来就会过期;
而且必须广邀各个框架领域的大牛来执笔，这是个挑战 ;-)
而且建议加上 Zope3...
--
http://zoomquiet.org 人生苦短? Pythonic!
向靠谱,反脑残! Kaopulity,小白退散! [Kaopulity~= Keep all processes usablity!]
xrfang
> --http://zoomquiet.org人生苦短? Pythonic!
Zoom.Quiet
> 2009/11/22 xrfang <xrf...@gmail.com>:
>> 以下是我经过考虑略为细化的TOC。在诸位细看之前，我先说明一下目前的问题：
>>
> soo great!
> 只是第一和第五部分，只要写出来就会过期;
> 而且必须广邀各个框架领域的大牛来执笔，这是个挑战 ;-)
> 而且建议加上 Zope3...
>
>> 1）部分的名字有点不伦不类，和下面章的名字风格不一致。我只是想到了这个用以分类，暂时用一下
可以先用章节先切开固定学习时间的内容，
给出这一范畴的核心主题；
最后定名都好;
>> 2）原来想写一个案例系列的，现在我想有点不好安排（因为读案例的同时有很多用到的概念、技术，如果不详细说，读者要翻到后面具体章节（例如
>> Sessions）查看；如果详细说了，后面说什么去？）我想这样，整个案例系列揉合到第二部分和第三部分的各个章节中。
所以， DiP/LovelyPython 等等，都是使用唯一的一个案例，在不同的学习进展中，追加不同的处理，来表达Pythonic 以及框架的特色；
当然，到了 web.py 这儿，也完全可以反过来，每个 web 开发的关键点，就用 web.py 自个儿原创的简化解决方案，
每一章节(方面)都是特化的条件前提就象多幕无关联的独幕剧组成 PyWDWW ;
嗯嗯嗯，比隃的话，就象 城市猎人， 主角不变，但是不同场景，不同的应对?
>> 3）第五部分，各个python框架的比较，有没有必要写？
如果能够集齐案例一定要写，
而且 Limdou 自个儿也在坚持不断的积累哪，
这也可以是 CPyUG 长期的撰写行为了：
－ 每个人将自个儿喜欢用的框架，都贡献出固定案例
- 长期坚持下来，可就是最权威的中文所有Py Web 框架的入门大全了哪！
>> 4）全书大体上没有太大难度，我个人感觉第十六章有点难度，因为webpy本身的文档不全；第十五章也是比较难的。
这一章，感觉正好是最不重要的，
一个框架的使用，入门最重要的不是 API 的熟悉，
而且整个框架的设计意图和适用范畴的理解，
这就好比E文的语感，这些对了，在处置细节时，就能够和框架的特性结合，顺手起来，
API 反正都是从注释抓出来了，大不了看一下代码而已，
>> 5）另外，我对第十章的安排也感觉不太舒服。
这个介绍些和 web.py 对味的契合的好的模块就OK ;-)
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Zoom.Quiet
> 我也感觉第五部分有点鸡肋，写了当然好（但会过期），不写也不会影响这本书的完整性。不过我对Z大说的第一部分会过期不太理解。解释一下？
>
正是整个图书想传达的，
象侦探小说，你先将结果说了，说的再精彩，别人也没有兴趣继续看了哪;
何况，各种框架的 FANS 非常可能就抓住第一部分的某些判定就不满意了，就不愿意继续看了哈...
--
http://zoomquiet.org 人生苦短? Pythonic!
流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
stupidity)http://bit.l...
xrfang
少？
On 11月22日, 下午11时21分, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:
> 2009/11/22 xrfang <xrf...@gmail.com>:> 我也感觉第五部分有点鸡肋，写了当然好（但会过期），不写也不会影响这本书的完整性。不过我对Z大说的第一部分会过期不太理解。解释一下？
> --http://zoomquiet.org人生苦短? Pythonic!
jeff jie
自个最不想买的技术类图书就是官方文档的翻版，偶觉得精心编排的故事（情景由小到大，复杂程度由简到繁，读者可以跟着故事从上手到熟悉）很讨好，会更受
读者欢迎。像DIP，可爱的Python，张教主未完的那个站。。。当然，编故事很讲究。
Cookbook是翻译原版？个人意见是可以把这部分内容放到最后面，作为参考手册，组织同《可爱的python》，把更多的篇幅作为舞台，留给咱们编
的故事。
On 11月22日, 下午11时18分, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:
> 2009/11/22 Zoom.Quiet <zoom.qu...@gmail.com>:> 2009/11/22 xrfang <xrf...@gmail.com>:
zhaoweikid
zhaoweikid
api部分，我觉得可以的，查询方便嘛，而且官方并没有这个东西，注释也未必详细，所以对于初学者来说，还是很有用的。
xrfang
巴，不知道书要说什么，也不知道这本书对我来说是不是恰到好处？还是太浅、太深？覆盖面广度/深度是不是符合我的需求？这些购书的决策都没有办法下。
jeff jie
故事的用意是更生动地描述某种技术使用的场景，不用像小说那样精彩，只求像胶水那样把一些表面上看来生冷并无关联的技术点连接起来变得有生气和实在就OK了。
--
185cm‘s自然卷：http://fallever.com
twitter:http://twitter.com/jeff_jie
试手机网,最好的在手机在线体验门户：http://shishouji.com
聪明的python主机webfaction：http://jeffjie.webfactional.com
xrfang
得不宜放在最后，其实我本来第一版TOC就是把它视为一个参考手册的。现在想来，它仍然是参考手册，不过地位就提高了，增加了教科书的成分。
jeff jie
Zoom.Quiet
> Cookbook基本上是原版，但我意向当中不是"翻版"，而是改版。原文cookbook有的地方语焉不详，而且组织上来说也不太理想。这些东西我觉
> 得不宜放在最后，其实我本来第一版TOC就是把它视为一个参考手册的。现在想来，它仍然是参考手册，不过地位就提高了，增加了教科书的成分。
>
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet
> 我同意，对LovelyPython这书我的意见是，TOC不好，我喜欢案例，但我不喜欢TOC里面是Day1，Day2，。。。这样我只能重头看到尾
> 巴，不知道书要说什么，也不知道这本书对我来说是不是恰到好处？还是太浅、太深？覆盖面广度/深度是不是符合我的需求？这些购书的决策都没有办法下。
>
不过副标题都是关键引入技术要点的说明了...
案例选择的好也是非常妙的事儿，
要不就象 CookBook 系列的，将每个案例约束到一定范畴内，
这就无法体现出 Pythonic 的轻快关联性了...
--
http://zoomquiet.org 人生苦短? Pythonic!
Time is unimportant, only life important!
xrfang
题(web.py)80%以上的快速入门+参考手册的书。以“实用”为主旨。
Zoom.Quiet
> 我设想的书的风格是面向熟练开发者，首次接触webpy或者python、python web编程，但又不是那种特别喜欢钻研框架底层细节的、覆盖主
> 题(web.py)80%以上的快速入门+参考手册的书。以“实用”为主旨。
>
只是 web.py 80% 以上的...
建议关注到 20% 最常用和核心模块，以及其它 80% 模块的索引式简介...
--
http://zoomquiet.org 人生苦短? Pythonic!
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.
xrfang
session等。也正是这一点，我希望大家群策群力补遗补缺。
另外，从实用角度说，如何在生产环境中用好webpy也是不让它沦为”玩具“的一个重要方面.....
> --http://zoomquiet.org人生苦短? Pythonic!
Zoom.Quiet
> 80/20法则 :-) "最常用“这话非常重要。所以我在构思章节的时候都以web编程中最常用、必用的概念组织，比如web.input()和
> session等。也正是这一点，我希望大家群策群力补遗补缺。
>
> 另外，从实用角度说，如何在生产环境中用好webpy也是不让它沦为”玩具“的一个重要方面.....
>
但是有"玩具"感觉的原因在于:
- web.py 无法承载大型应用的长期维护
- web.py 无法简化系统开发的工作量
所以，蟒样 一定要说明白，什么情况下用 web.py 比其它框架要好，
同时，也要给出大规模运营时，web.py 的最佳体验;
从俺的角度，建议重点:
- web.py 在业务固定，性能要求高，开发周期可控，的场景中非常好用
- web.py 体积不大有利与和应用系统一同进行版本管理和发布部署
--
http://zoomquiet.org 人生苦短? Pythonic!
xrfang
Pragmatic Programmer这本书。我相信：
1) 持续的Refactoring是非常必要的
2）如无必要，勿增实体
3) 对质量的追求最终会带来项目进度上的巨大收益
对于webpy大型应用是否能够适应性能和扩展性要求，这点我不知道，也是我想学习的。另外，我对Z大妈说的2点以及上面"侦探小说"的比喻表示部分赞
同，毕竟项目管理和技术观点千差万别，webpy不是普适性的。有大量的人就是喜欢Django（远超webpy），甚至是Zope3，而我认为这两者
是不符合Pythonic的哲学的 －－ 按这论坛的观点－－我很同意－－就是"大道至简"。
> --http://zoomquiet.org人生苦短? Pythonic!
Zoom.Quiet
> 对于"简化系统开发工作量、长期维护"这2点我不同意Z大妈的看法，我是Agile的追随者，我喜欢scrum和Dave Thomas的
> Pragmatic Programmer这本书。我相信：
>
> 1) 持续的Refactoring是非常必要的
> 2）如无必要，勿增实体
每一个种应用冲突问题,都可以通过增加一个中间层,解决;
所以,长期运维时,最频率的就是这种决策...
> 3) 对质量的追求最终会带来项目进度上的巨大收益
>
但是,多数团队无法获得高层的耐心,等待质量因素的积累发韧时...
> 对于webpy大型应用是否能够适应性能和扩展性要求，这点我不知道，也是我想学习的。另外，我对Z大妈说的2点以及上面"侦探小说"的比喻表示部分赞
这点不用怀疑, Reddit 曾经用的就是 web.py
> 同，毕竟项目管理和技术观点千差万别，webpy不是普适性的。有大量的人就是喜欢Django（远超webpy），甚至是Zope3，而我认为这两者
> 是不符合Pythonic的哲学的 －－ 按这论坛的观点－－我很同意－－就是"大道至简"。
>
大道至简 ~ 对象是用户或是开发人员,大道本身是否是由简单组件构成的,并没有要求;
象M$ 系统,将超复杂的问题,封闭在 dll 之后,给开发人员和用户一个简洁的界面,这也是道行...
当然 Pythonic 追求的是简单凝练, 提炼问题域的通用组件,简单靠谱的复用下去,合理的堆积而不会出问题,
就是出问题也可以简单的处理掉,,,
Zope3 通过不断的PK掉自个儿的整个结构 ,来探索复杂和简单的平衡;
Django 通过坚持自个儿的思想,绝对不轻易加入任何叫好的特性,来保持自个儿内外接口的简单稳定;
PyLons/Turbogeas 通过最宽容的 mixin 结构,确保自身的简单>...
都是非常好的解决之道;
CherryPy 和 web.py 则是坚持只提供最常用的核心 web 应用能力,从而将注意力收敛到web 应用的最核心非可用性领域,
从而逐渐成为各种框架的基础框架....
这也是很禅的解决之道, 而且是个趋势 ~ 专用的永远比通用的要稳定;
但是,现实中的项目开发,真的是在拼速度而不是质量哪!
所以,谁提供最多的模块的同时,可以兼顾给出一定的质量和性能,谁就是明星框架...
--
http://zoomquiet.org 人生苦短? Pythonic!
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Qing Feng
> 2009/11/24 xrfang <xrf...@gmail.com>:
>> 对于webpy大型应用是否能够适应性能和扩展性要求，这点我不知道，也是我想学习的。另外，我对Z大妈说的2点以及上面"侦探小说"的比喻表示部分赞
>
> 这点不用怀疑, Reddit 曾经用的就是 web.py
>
>> 同，毕竟项目管理和技术观点千差万别，webpy不是普适性的。有大量的人就是喜欢Django（远超webpy），甚至是Zope3，而我认为这两者
>> 是不符合Pythonic的哲学的 －－ 按这论坛的观点－－我很同意－－就是"大道至简"。
>>
>
> 大道至简 ~ 对象是用户或是开发人员,大道本身是否是由简单组件构成的,并没有要求;
> 象M$ 系统,将超复杂的问题,封闭在 dll 之后,给开发人员和用户一个简洁的界面,这也是道行...
>
> 当然 Pythonic 追求的是简单凝练, 提炼问题域的通用组件,简单靠谱的复用下去,合理的堆积而不会出问题,
> 就是出问题也可以简单的处理掉,,,
>
> Zope3 通过不断的PK掉自个儿的整个结构 ,来探索复杂和简单的平衡;
> Django 通过坚持自个儿的思想,绝对不轻易加入任何叫好的特性,来保持自个儿内外接口的简单稳定;
> PyLons/Turbogeas 通过最宽容的 mixin 结构,确保自身的简单>...
>
--
http://blog.woodpecker.org.cn/planet/
http://qingfeng.github.com/
http://www.zaojiao100.com