升级1.3其实是自己早就想作的事了,更新内容不少,不过对自己而言尤其重要的3点更新是:
1:ContentFile的支持,可以在后端直接从request里读文件了,也就是说支持纯ajax上传了。
2:原生Logging的支持,之前Django必须用三方的logging组件,现在可以用python原生的logging机制了。
3:支持多数据库和某新兴的pylibmc。
对于2和3是自己一直期待已久的东西,其实还有多数据库和多cache的支持,这个对于大型站点而言可谓是重中之重口牙,django越来越成熟了,happy~
忘记了mark非常重要的一点:
从1.2.5开始django删除对象不会默认删除文件。这是自己的解决方案如下:
利用post_delete.connect(handler,sender=Class)的方法,
再handler函数内删除文件,如:
os.path.exists(object.file.path):
os.remove(object.file.path)
django可以说对文件的处理有点让人感觉哭笑不得,不过信号机制还是可以解决这个问题的wwwww
另外还有的问题就是有关非django 1.3(如1.2.5下)如何处理ajax上传文件?
这里借用alex的脚本一用(要求python2.5+,有with需求)
with BufferedWriter( FileIO( filename, 'wb' ) ) as dest:
if raw_data:
foo = uploaded.read( 1024 )
while foo:
dest.write( foo )
foo = uploaded.read( 1024 )
不过这个方法有个弊端,就是上传文件大小只能限制再20m之内,20m之外就会出问题。
1.3引入ContentFile后则可以这么写:
from django.core.files.base import ContentFile
object.file.save(filename,ContentFile(uploaded.read()))
可以解决20m问题,万事大吉。
以上留作备忘,后续添加相关链接和原文。
废话完毕。借着这次更新1.3,自己把之前一直边唾骂边在用的uploadify给换掉了(这丫就一个坑爹插件,win下莫名奇妙crash,mac下直接io error,linux下也总有奇怪的惊喜),从而启用纯javascript上传的ajax插件File Uploader,从此以后不用担心浏览器再crash了之类的了,太好了。。。(其实自己曾经下了个决心,我要学会用flash写点snippet,结果翻了flex4不到5分钟,就扔一边了,语法来说,flash很正统不像某肥猪流语言,不过,表现上,还有复杂度上,还有效率上,这东西根本不配用这么高的复杂度来写,我个人宁愿用scriplet)
表情方面纠结来纠结去,最后用了2个小时把django的插件smiley进行了扩充,添加了views和前台的加载表情脚本。过一阵进行简单的抽象后可以放出来进行复用。没有扩用RazerGallery来写表情也是因为怕这样作会导致项目的耦合性过高最终会影响单元测试。
正则过滤评论也写完了,不过没用用正则来实现,而是通过BeautifulSoup来进行HTML分析和净化,没有对特殊符号进行替换。原因,有不少,其实从我个人因素,我更喜欢bbcode,而不是标签,尤其是对于复杂度很高的并且可能带有恶意尝试任意三方输入来讲。不过还是通过这个进行一个尝试吧,如果实在不行以后再作替换好了,暂时就先这样了。
也就是说,这个项目目前唯一还坑着的就是一个围脖系统和一个文件发布管理平台。这2个系统从逻辑上来讲则并不属于RazerBlog的项目范围内,算是协同作业吧,以后陆续抽时间会完成他们。
于是可以说,到现在为止,RazerBlog就彻底竣工了。构建前理想的功能目前也全部包括了,至于pingback,我暂时还想不到这东西对我有什么意义,所以,暂时就先不管它了。
之后的闲暇作业就是陆续把项目中自己整理的几个应用从程序中分离出来,实现复用,整理文档备后需。还有就是数据导出供Wordpress导入。
除此之外就是发生以外时的debug(这个才是噩梦)
总算是脱身了,今天搞完了这个感觉各种神清气爽,可以说是又解决一件事,虽然没花多少时间,但是没有完成就总舒不下这口气。
顺带提一下,水果的更新站点就一坑爹。直接点Mac update,告诉我要下载70个小时(爷爷,就1.6G的文件你下70个小时?!)
结果找了下help,发现proxy居然要改配置文件,结果找了下配置文件,却发现那丫事Mac Server的配置文件,**!
得,最后抓包获得了升级包的下载地址,1.4g的update pack,如今已经安装完毕,明天就能用上app store了,终于。。。泪目[:cry]
最后,测试下表情,[:bye] RazerBlog终于完结了.....(圆姐,qb,神马时候能再见口牙,啊啊啊啊啊)
Comments (29)
[:daunted]玩脱了么。。。233
@kita:
网通?我也是网通口牙......
呃,其实偶是北方人>_<
不过现在其实南电信北网通的说法也不像以前那么明显了,这里反而现在感觉电信的市场要比网通广,因为网通的fttb到现在都没开始铺设。。。
传说中的cable么。。。价格不菲,速度不如光纤,嘛,暂时没多大需求,先这么用着好了,下午开vpn从mac store下东西发现有100多的速度,也基本满足了~
我这边是路由7*24小时接续ssh作二级代理,不过对水果的proxy设置有点困惑,感觉有点像是全局设置,搞得有点不敢7*24设置代理~
嗯,switchy,foxy proxy都起作用,还有某个ppp-up脚本。不过自己还是偷懒有的时候懒得连,嘛,水果真该改善改善大陆这个线路了....~
[:what]什么东西有够纠结?
嘛呐
@shekck:
[:triumphy]嗯,就是这些东西。
Django是一个通过Python语言写的web服务搭建框架,这个Blog是用这个框架写成的。
其实个人理解,Wordpress也算是一个基于PHP的web开发框架了,虽然多数人只用这个作Blog站点的说~
google大神是万能的[:deny]
@lovee:
[:locked] 神呐救救我吧
不过我也通知了敏哥,希望搞出稳妥的方法。
其实习惯了java的web mvc编程习惯,对根路径曝露的安全性有所质疑是正常的,所以这个其实对于开发者而言根本就不是问题,可能仅仅是php开发者会感觉比较awkward吧,我也不太喜欢直接曝露directory root给用户,之前nginx就出过严重的安全漏洞,在php的解释问题上,还有之前asp的安全漏洞问题。所以我觉得在nginx上把conf做好就可以了,这个都不算是问题。
我想80%的人都知道wp-config.php的位置吧。
开发者应该站在用户角度考虑问题!
隐藏不是很NB的东西,知道的,一样可以分析出来。
Nginx本来就有跨站问题。
和用户有神马关系,服务端配置好了对用户是透明的啊,开发者又不是严格意义的用户,把权限控制在自己手里又什么错误。再说这不是隐藏,这只是控制权限而已。root问题从web有的那天就有各种问题了。所以只是降低风险,是一种开发理念而已。并不是nb不nb的问题,用来部署的东西最优考虑的就应该是安全和高效。自己也是从bash到perl到php走过这条路,虽然不怎么会写,不过说实话我很不喜欢php的开发和部署风格,因为太直白了,让人感觉有点难受。
直白是我的爱好,就像我写C/C++一般,不过汇编会更直白。
在我眼里没有什么封装的必要,漏洞才是被入侵的关键。
说实话,PHP在我眼里就是解释型的C/C++……
嘛,用户的问题。我和你们指的什么?
比如你是WP博客的拥有者,你应该算是WP的用户呢?还是开发者呢?
易于部署,直白,都没错。不过就是有人不喜欢而已,开发风格,就像OO和Function Oriented,争吵数十年了,也不会有结果,这个就是开发者的风格而已。Do as the romans do.如果不习惯这种开发风格,就可以转而走它径。
而且Php说成解释型的C/C++无所谓,Python,java,何尝不是?而且我所谓的直白,不是说直接,php的执行效率并不高,少有人用只是懒得用c去写cgi而已。
说这些不打算争,这就是一个开发者的习惯取向问题。我现在用mac也在习惯objc,我不能因为这个这个东西很难以接受就不用,就像那边的所谓路径问题,如果单纯说nginx配置有问题,这个很正常,如果说是django设计机制有问题,这个就让人听着感觉很难受了,就是这样。
我向来直白,对什么不满就说出来,django的机制什么的,我不喜欢的地方,就是不喜欢,你无法接受,那是你的事。
嘛,无所谓了,这也是我单方面的情绪,完全不用在意。
不过话是既然说出来就是为了交流,这么单方面的推脱让人感觉很难受而已。就像下载一款工具说它不好用之前应该先去读一读manual,贴bug应该贴出log一样。否则单方面的抱怨只会让人感觉难受,仅此而已。
P.S. 其实web.py的url rewritting个人觉得更麻烦,目前python的几个主流框架里,还有limoudou様写的uliweb,其实个人更倾向于uliweb,不过目前还不成熟而已。django包装的合理,比较符合j2ee开发习惯,web2py属于数据库驱动的,不过url writting很糟糕。web.py可能是写法上最接近php的了,如果喜欢可以去看看。
1.对于django上传文件,我一直有个疑问没太搞明白,比如用户新建了一篇博客,在博客的新建页面上,用户上传了一张图片,这时候图片应该已经被上传到服务器上了,但是博客本体还没有被save,那么博客save的时候怎么和这张图片绑定在一起呢?
2.还是刚才的情况,假设博客最后没有save,而是取消或者直接关闭窗口了,博客不会存在于数据库中,但是这个图片却还在服务器硬盘上,这应该怎么办?
归结一下,就还是如何在文件上传后,怎么访问到那个文件的问题。
初来乍到,问题粗浅,求指教。
另外,吼姆啦最棒了!
嗯?大概意思就是上传图片后如何管理?
Django对上传的File和Image有过包装,如果你后台是用的Django的文件类型包装的话根据你上传的ID之类的来寻找就可以,文件地址通过文件变量的aboslute_url来获取就可以。
至于说没博客,但是图片存在服务器上,可个问题具体分析了,看你怎么传的图片,如果图片数据库入库了,直接在后台管理删掉图片对象就可以。不过Django 1.3已经删掉了自动删除文件的功能,你需要手动删除或者增加一个Signal删除文件也是可行的。
Django对于后台包装的比较好,如果对Web开发比较陌生的话最好别一开始就用这些框架,因为对开发中可能遇到的问题会产生比较大的误解。
Leave a comment