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
--
http://zoomquiet.org 人生苦短? Pythonic!
向靠谱,反脑残! Kaopulity,小白退散! [Kaopulity~= Keep all processes usablity!]
> --http://zoomquiet.org人生苦短? Pythonic!
所以, DiP/LovelyPython 等等,都是使用唯一的一个案例,在不同的学习进展中,追加不同的处理,来表达Pythonic 以及框架的特色;
当然,到了 web.py 这儿,也完全可以反过来,每个 web 开发的关键点,就用 web.py 自个儿原创的简化解决方案,
每一章节(方面)都是特化的条件前提就象多幕无关联的独幕剧组成 PyWDWW ;
嗯嗯嗯,比隃的话,就象 城市猎人, 主角不变,但是不同场景,不同的应对?
>> 3)第五部分,各个python框架的比较,有没有必要写?
如果能够集齐案例一定要写,
而且 Limdou 自个儿也在坚持不断的积累哪,
这也可以是 CPyUG 长期的撰写行为了:
- 每个人将自个儿喜欢用的框架,都贡献出固定案例
- 长期坚持下来,可就是最权威的中文所有Py Web 框架的入门大全了哪!
>> 4)全书大体上没有太大难度,我个人感觉第十六章有点难度,因为webpy本身的文档不全;第十五章也是比较难的。
这一章,感觉正好是最不重要的,
一个框架的使用,入门最重要的不是 API 的熟悉,
而且整个框架的设计意图和适用范畴的理解,
这就好比E文的语感,这些对了,在处置细节时,就能够和框架的特性结合,顺手起来,
API 反正都是从注释抓出来了,大不了看一下代码而已,
>> 5)另外,我对第十章的安排也感觉不太舒服。
这个介绍些和 web.py 对味的契合的好的模块就OK ;-)
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
--
http://zoomquiet.org 人生苦短? Pythonic!
流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
stupidity)http://bit.l...
On 11月22日, 下午11时21分, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:
> 2009/11/22 xrfang <xrf...@gmail.com>:> 我也感觉第五部分有点鸡肋,写了当然好(但会过期),不写也不会影响这本书的完整性。不过我对Z大说的第一部分会过期不太理解。解释一下?
> --http://zoomquiet.org人生苦短? Pythonic!
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>:
--
http://zoomquiet.org 人生苦短? Pythonic!
案例选择的好也是非常妙的事儿,
要不就象 CookBook 系列的,将每个案例约束到一定范畴内,
这就无法体现出 Pythonic 的轻快关联性了...
--
http://zoomquiet.org 人生苦短? Pythonic!
Time is unimportant, only life important!
--
http://zoomquiet.org 人生苦短? Pythonic!
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.
另外,从实用角度说,如何在生产环境中用好webpy也是不让它沦为”玩具“的一个重要方面.....
> --http://zoomquiet.org人生苦短? Pythonic!
--
http://zoomquiet.org 人生苦短? Pythonic!
1) 持续的Refactoring是非常必要的
2)如无必要,勿增实体
3) 对质量的追求最终会带来项目进度上的巨大收益
对于webpy大型应用是否能够适应性能和扩展性要求,这点我不知道,也是我想学习的。另外,我对Z大妈说的2点以及上面"侦探小说"的比喻表示部分赞
同,毕竟项目管理和技术观点千差万别,webpy不是普适性的。有大量的人就是喜欢Django(远超webpy),甚至是Zope3,而我认为这两者
是不符合Pythonic的哲学的 -- 按这论坛的观点--我很同意--就是"大道至简"。
> --http://zoomquiet.org人生苦短? Pythonic!
> 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!
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
--
http://blog.woodpecker.org.cn/planet/
http://qingfeng.github.com/
http://www.zaojiao100.com