|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-09
FastCGI是基于线程的，CGI才是基于进程的。
|
| 返回顶楼 | |
|
发表时间：2008-09-09
ahuaxuan 写道 我的思想一直被0配置控制着,url配置我认为是可以去掉的,基于规则就行了,比如struts2中的zero configuration,而且我也是一直这样做的,如果能把url的规则更精简些对程序的负担会更小些,维护起来就更方便些.而且我坚信,框架应该向着coc的方向发展.
而对应django1.0,我还没有看过,最希望的是url的改变,包括能增加restful. 我觉得这些东西应当和个人的使用习惯有些关系吧。 django的url应当算是一个比较奇怪的功能了。 它的url配置功能非常的强大，在一定程度上说已经不是单纯的配置了，url配置已经成为了模块可重用的一部分。 就如Django提供的Generic views。 你可以不写任何view的代码，直接在url里配置一下就行。
urlpatterns = patterns('django.views.generic.simple',
(r'^foo/$', 'direct_to_template', {'template': 'foo_index.html'}),
(r'^foo/(?P<id>\d+)/$', 'direct_to_template', {'template': 'foo_detail.html'}),
)
此外url配置的工作量很小，我觉得在我可以接受的范围内（SSH的配置多到吐血-_-!）。 |
| 返回顶楼 | |
|
发表时间：2008-09-09
楼主果然是实力强劲，虽然一直说只是看了几天，但是对整个Django的知识体系也算是描述的脉络十分清晰，其实最吸引我回帖的就是楼主也是一个熟悉SSH开发的人，充分体现"Java" "Eye", 用一个Java开发者的眼光去看世界（特别是对Hibernate积怨已久的事情），:P。我也是最近摸了几天Python和Django.0.96，所以也说说自己的小想法。
因为Java的博大精深，所以一个合格的Javaer就会从各个方面考量其他技术，楼主几天的学习成果也可以说是面面俱到。对于现在一堆一堆的Java开发人员，如何突破自己去吸纳其他技术的优秀品质也是一个很重要的能力。 不过也不能完全用Java那一套去套，举个例子来说楼主居然可以很快就"升级"他的urls.py，让它更符合Java开发者的想法，我不是说这样做好与不好，只是这样做挺不"Django"的，Django这个url映射的方式挺有历史的，它强迫开发者用另一种思路去思考问题，因为Django是MVT而不是MVC。 当初选择Python主要是受它宣扬的简洁，单一解决方案的philosophy，但是我认为Python社区太过中庸，社区主要成员也都极力宣扬自由的理念，大家有劲不往一块使，所以发展这么多年也没出现一个非他不可的杀手级应用，以至于每当别人问：Python有什么好，做什么最牛？我都不知道该怎么回答（不知道谁能帮我解答这个问题，谢！） Python目前定位的确很模糊，似乎是干啥都行，但是又没有做的比别人好很多的应用，目前也就Google比较挺它，但不知道它啥时候能杀出重围，我认为它最有潜力的方向还是取代Perl（但谈何容易），至于Django，我用过ROR我就只能说Django需要再重构10次，搞那么多年才升级到1.0，还抱着一堆东西向下兼容，form不行搞个newform，但一样不令人放心，还有那包管理，包括它杀手级的admin模块也都是很受大家诟病的。 所以我的观点是：Python虽好，但选用需谨慎，拿来写写小工具还是挺得心应手的。 |
| 返回顶楼 | |
|
发表时间：2008-09-09
harry 写道 FastCGI是基于线程的，CGI才是基于进程的。
FastCGI是基于线程的?? 我阐述一下我理解的FastCGI内部机制: 由于FastCGI是c所写,所以运行速度是非常快的(相对网络速度来说),它根本没有必要是多线程的,FastCGI使用的模型应该和memcached的模型是一样,应该就是生成者消费者模型,也就是说同时只有一个真正的处理请求的线程,比如说memcached用c接口访问的时候每秒钟可以达到上万次(不过mc里没有什么业务逻辑),就这个速度,它也是单处理线程就可以搞定了,假设我们处理request的速度是50毫秒,那么一秒之内这个fastcgi进程可以处理20个请求.如果我们开50个进程,那么每秒就是1000个请求,当然这个计算是除去网络时间的 而我说的基于进程不是指它内部的实现,是指其对于webserver来说,如果它是基于线程的,那它是否应该象mod_python嵌入到webserver中运行呢,如果不能嵌入,那么fastCGI是独立的进程,如果是独立的进程何来"FastCGI是基于线程的"一说 yueguangyuan 写道 Python虽好，但选用需谨慎，拿来写写小工具还是挺得心应手的。
其实这也是我选择python的原因:它不只是做web应用 |
| 返回顶楼 | |
|
发表时间：2008-09-09
django的orm还是有很多不足,比方说select_related,并不用outer join方式运行,对直接写sql 支持的不是很多(参数化查询),只是简单的支持按位置传入参数
cursor.execute('....',[]) 另外extra方法比较死板,没rails 的 find 来的灵活 但对于不是数据密集型的应用,它是足够的,否则,还是手动写sql的工作会比较多 |
| 返回顶楼 | |
|
发表时间：2008-09-09
python最强大的恰恰是他的无所不能，在语言能力上又做到了严谨和效率的合理平衡，既有Java的强大、成熟，又有动态语言的一切优点，Ruby虽然在web很火，但也仅此而已，python前途无量。
|
| 返回顶楼 | |
|
发表时间：2008-09-09
fight_bird 写道 python最强大的恰恰是他的无所不能，在语言能力上又做到了严谨和效率的合理平衡，既有Java的强大、成熟，又有动态语言的一切优点，Ruby虽然在web很火，但也仅此而已，python前途无量。
无所不能都出来了，听起来很像广告~ 
|
| 返回顶楼 | |
|
发表时间：2008-09-09
ahuaxuan 写道 bluecrystal 写道
urlpatterns = patterns('',
(r'^user/(?P<id>\d+)/$', 'mysite.user.views.detail'),
}
这样的url定义意味着你可以通过诸如：http://localhost/user/23/的形式访问一个用户的信息。 然后定义如下一个函数：
def detail(request, id):
user = User.objects.get(pk=id)
groups = user.groups.order_by("-groupName")
return render_to_response("user_detail.html", {"user":user, "groups":groups})
在上面的函数中,id就是通过url传过来的命名参数,函数获取信息后，将user和groups信息交给模板user_detail.html进行数据渲染后返回客户端。 这种方式能否再进一步,就是正则表达式中包含method的信息,这样我就可以指定执行views中的哪个函数了,比如说 http://localhost/user/23/edit/就表示执行views中的edit方法,虽然看上去比较怪异,不过要比加methodName这种方式好多了,虽然不能restful,那url看起来比正文中看起来好了很多. bluecrystal 写道 一个普通的java程序员，从不懂python和django，在没有任何第三者予以帮助的情况下，如果能够流畅的阅读英语，一般一个星期左右，就能基本掌握基于django的简单的web应用开发。 这个我想式django一大优势之一,入门确实很简单,不过不清楚django为什么没有在国内有运用起来,只有很少的网站在使用django. 事实上,完成整个例子,这个例子中还包括验证码,文件上传等,我只用了周末2天和周一到周五每天1个小时.这么好的东西为啥用的人不多呢? 之前我内心曾激烈斗争过,到底是学ror,还是django,斗争了相当长一段时间之后,我还是选择了django. 在url的正则表达式中包含method的信息，然后直接执行views中对应的某个函数，似乎django的url设计并不是这样考虑的，不过如果你喜欢这样的方式，你可以通过写一个公用函数，根据你传入的method名字，再跳转到不同的函数，不过不管怎么去做，还是得写上一行url映射记录 
|
| 返回顶楼 | |
|
发表时间：2008-09-16
对于JAVAer来说， LIFT更好用
http://liftweb.net/index.php/Main_Page |
| 返回顶楼 | |
|
发表时间：2008-09-16
不支持链接多个数据库
比较不爽 |
| 返回顶楼 | |
