我使用的最后一个框架是Django。我喜欢这里的很多东西，比如：
但是有一些限制：
是否有另一个具有django优点的Web框架，并且没有列出的限制？或者是否可以解决django中的一些问题？
ps：我会根据答案更新列表。我相信还有更多方面需要讨论......
我可以自由地使用任何其他语言的框架，只要我可以在linux服务器上安装这些东西
答案 0 :(得分：14)
没有试图为Django辩护（这不是我的工作！:-)）只是试图给你一些关于你的限制列表的指示......
截至2009年12月没有模型验证
你到底是什么意思？验证在表单级别可用...并且您始终可以覆盖save()方法以实现您想要的任何逻辑并停止保存操作...您能举例说明一个场景吗？
只要您不需要自定义模板标记，模板系统就会很好 将设计与逻辑分开的想法似乎很好，令人沮丧的是，我无法在视图中总结2个数字
那就是说，你没有和Django的模板系统结婚。例如，您可以使用Jinja2。
呃......为什么？我工作的大多数设计师使用模板语言没有问题，比Django更复杂......你能举一个你认为不友好的例子吗？也许有一种解决方法。模板语言不是设计师友好的
自定义模板标记中ex的堆栈跟踪是无用的（如果与python 2.6一起使用）。有一个补丁，但它将在1.2
进入django
我没有遇到你讨论过的堆栈跟踪问题。你可以随时安装补丁，直到Django 1.2出现。所以看来你有一个解决方案。
django的orm（连接遗留系统） 无法处理blob字段
如果您正在处理在数据库中存储文件的需要，也许您应该查看django-storages'DatabaseStorage。
无法处理多列pk字段
这与多个数据库支持一起，是真正需要改进的领域 - 我同意。
我认为你不能对具有多列pk要求的模型使用模型（只是直接的SQL）（是的，它会杀死管理员，但它是可行的）。坦率地说 - 我的模型中没有这个问题，因为我更喜欢代理主键 - 如果遗留模型在我的路上，我会添加一个代理主键 - 所有遗留代码应该继续工作，Django会很开心。但我确实可以完全控制数据库表，这可能不是你的情况。
多列主键are medium priority for the 1.2 release。
Multidb是high priority for 1.2 release。
1.2版本是expected by March 2010。当然，约会不是一成不变的。
鉴于我对其他框架的经验，我宁愿解决我的问题并坚持使用Django。
答案 1 :(得分：5)
虽然你可以在某种程度上交换掉你不喜欢的Django，但是其他框架比Django更容易实现。
假设您想坚持使用Python，那么下一个最佳选择就是Pylons。你有SQLAlchemy + Formencode进行验证; Mako / Jinja / Genshi都提供了更灵活的Django模板替代品。
另一种选择是使用“反框架”或用于WSGI处理，数据映射等的库工具包。我最喜欢的技巧包括Werkzeug + SQLAlchemy + Jinja2但是真的适合您的需求和编程风格
值得注意的是，Pylons和更多DIY框架需要比Django更好地理解Python，即使是琐碎的项目也是如此。这并不是一件坏事：但是我会建议Python新手首先使用Django，因为它具有更好的文档和更少的粗糙边缘。一旦你更自信，那就去看看吧，因为你发现Django并不总是最好的工具。
答案 2 :(得分：3)
我仍在使用django的原因，即使存在大量其他粗糙区域，也是因为框架的最基本的核心功能，即请求/响应调度系统。杀手功能是urlresolvers.reverse()功能。这意味着，只要您需要计算链接，就可以强有力地执行此操作，而无需担心您在框架中的其他位置所做的任何更改都不会破坏任何计算链接。虽然在其他语言中可能存在类似的框架功能，但肯定没有像django的python调度系统那样完美，而且对于我尝试过的其他语言的框架，它肯定似乎是例外，而不是规则。我将继续单独使用django，即使我正在使用其他东西进行ORM，模板，表格处理，序列化，脚手架或任何其他功能。
答案 3 :(得分：1)