Tag: RazerBlog

Added:

1:Sidebar RecentPost

2:Sidebar Blogroll

Fixed:

1:评论内图片宽度超过固定宽度

没什么复杂的东西，不过这个snippet或许发出来有人能用到。

Dependency:

1:jQuery

2:jQuery Lightbox

Function:

1:传入一个jQuery提取的图片对象 如 $('img') 后，对该图片数组进行分析，若图片宽度超过固定大小后则修改图片宽度到固定值，并将该节点包装入一个lightbox中，使得可浏览正常尺寸。

Demo:

参照评论＃18 

Code:

CustomImage=function(jquery_pic_instance)
{
    this.fitWidth=450;
    this.toBeFixedPics=jquery_pic_instance;
    this.resizeCommentPic();
}
CustomImage.prototype={
testCommentPic : function()
{
    var picReady=true;   
    $.each(this.toBeFixedPics,function(i,pic)
    {

var flag=false;
        if (pic.width>0)
        {
            flag=true;
        }
        picReady= flag && picReady;
    });
     return picReady;
},
wrapWithLightbox : function(img_dom)
{
    var tempNode=$('<a rel="lightbox" title=""></a>');
    tempNode.append($(img_dom).clone());
    tempNode.attr('href',img_dom.src);
    $(img_dom).replaceWith(tempNode);
    tempNode.lightBox();
},
resizeCommentPic : function()
{
    var ci=this;
    flag=this.testCommentPic();
    if ( ! flag )
    {
        setTimeout(function(){
            this.resizeCommentPic();
        },100);
    }
    else
    {
        $.each(this.toBeFixedPics,function(i,pic)
        {
            var w=ci.fitWidth;
            var ratio= pic.height/pic.width;       
            var flag = ci.fitWidth < pic.width;     
            if ( flag )
            {
                pic.width = ci.fitWidth ;
                pic.height = ci.fitWidth * ratio ;
                ci.wrapWithLightbox(pic);
            }
        });
    }
}
}

How to use:

在jQuery加载函数中加入如下代码：

其中toBeFixed是要控制的图片对象，FixImage是新建的CustomImage对象。

$().ready(function(){
var toBeFixed=$('#comments').find('img').not('.smiley').not('.avatar');
        FixImage=new CustomImage(toBeFixed);
});

Sum up:

1:很简单的一段代码，不过有个地方调错浪费了我不少时间。就是setTimeout这个函数，最初传入的setTimeout(this.resizeCommentPic,100);却提示空指针，于是反映过来——setTimeout是一个全局函数，this指向的window,所以需要传入一个闭包匿名函数，将私有变量传入。也就是写成如下的形式：

setTimeout(function(){
            this.resizeCommentPic();
        },100);

就可以解决问题。

P.S.:明天8点半起来围观刑场，虽言胜败乃兵家常事，不过明天是输不起的一场比赛。Sometimes we must bite the bullet.

升级1.3其实是自己早就想作的事了，更新内容不少，不过对自己而言尤其重要的3点更新是：

1：ContentFile的支持，可以在后端直接从request里读文件了，也就是说支持纯ajax上传了。

2：原生Logging的支持，之前Django必须用三方的logging组件，现在可以用python原生的logging机制了。

3：支持多数据库和某新兴的pylibmc。

对于2和3是自己一直期待已久的东西，其实还有多数据库和多cache的支持，这个对于大型站点而言可谓是重中之重口牙，django越来越成熟了，happy~

废话完毕。借着这次更新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(这个才是噩梦）

1.博主提醒取消EMAIL提醒，替换成JABBER信息

def send_jabber_message(username,password,sendTo,message):
    '''Username must be jabberId looks like example@example.com'''
    try:
        jid=xmpp.protocol.JID(username)
        cl = xmpp.Client(jid.getDomain(), debug=[])
        conn = cl.connect()
        if conn:
            auth = cl.auth(jid.getNode(), settings.JABBER_PASSWORD, resource=jid.getResource())
            if auth:
                cl.send(xmpp.protocol.Message(sendTo,message))
                cl.disconnet()
            else:
                print "Login jabber error"
        else:
            print "Get Jabber Instance Error"
    except:
        print "Get Jabber Instance Error"
        

利用xmpppy进行JABBER提醒，替换掉原来EMAIL的NEW MESSAGE提醒，同样方法可以写一些类似EMAIL LISTENER之类的功能，配合JABBER服务器可以获得很好的效果，后期考虑加入WEB聊天室的功能（无限延期中

2.加入HTML5特性，本地CACHE。

参考了幸福收藏夹的“http://sofish.de/1449”一文，将页面的JS，PNG，CSS全部写进cache.manifest文件中，并且在nginx中加入了manifest文件的MIME类型，在模版中添加iframe来加载CACHE实现选择性缓存。

3.代码部分改用Prettify来显示。

未完成部分：

1.Comment Saniize部分，考虑后决定听从トトロ巨巨的建议，不通过BBCODE而是用正则去替换标签。

2.SMILE，对于SMILE是否直接利用RAZERGALLERY而迷茫中，自分还是希望直接建立一个GALLERY然后仍进去，不过这样做会造成额外的依赖性问题。再考虑考虑再说。

3.豆知识围脖，这个目前只有雏形，对于API的支持，自己是想做的，不过，看精力了，最近更愿意看代码，实际写的量不是很多，很多风格上的问题，急于写最后再改会变得非常麻烦，所以，先学习学习再继续动笔了。

4.保存草稿和自动保存的问题，这个需要手动写一个ADMIN的VIEW了和一点JSCODE了，虽然很简单，不过短期内不太想动笔，有不少需要考虑的地方，包括主页的CSS也想进行一些变动。

晚上吃完饭做了个测试，比较了一下MOD_WSGI和UWSGI，虽然知道UWSGI有一定的BUG，最后还是咬牙放弃了MOD_WSGI,原因就是11区的VPS的CPU并不是很好，从纯APACHE转移到NGINX SERVE STATIC到彻底放弃APACHE，差距还是能够体现出来的，尤其是内存吃紧的时候。

搞完了这个看了一集I‘S，居然是英文字幕（非INFINITE STRATOS），记得初一的时候看的漫画，现在再回去看桂老师的画风感觉好怀念（其实最初还是因为樱花通信？），不过下面的字幕真的是太囧了，记得看过的第一部英文字幕动画貌似是GTASTE（大雾）？。

压制效果感觉还是可以的（老物不强求了）

昨天下午测试了下准备拜入的MAC AIR（其实只是测试，拿回来也不会这么用），在PARALLEL下用无缝模式播放了BDMV和启动STARCRAFT2，让我比较惊讶的是，居然都没问题。。。。看了下CPU是SL9800，VIRTUALIZATION OPTIMIZER：TRUE，主频相差不大，不过CORE1和CORE2真的相差很多，当然加上虚拟优化就更不错了。

其次就是散热，比我想象的要好的多，明显没有说热的跟火炭一样，只是稍微有一点点发烫而已，但是绝对不明显，至于上面能COOKING云云，就更不可信了。

测试结果反正是比较满意的，过两天就准备从HK那边订回来，不过鉴于AIR的内存是焊死的，所以还是要上邪恶的TB找人代购（否则只有默认的2G内存）。

顺便搞定了DJANGO管理页面下的TEXTAREA，给默认加载的TINYMCE增加了SOURCETAB，不用再点开HTML窗口看源码了，方便的多。

该来的会来，不该来的也要来，这就是残酷的现实。下午听说地震了，我第一个想到的是东京震级8.0，不过今天的震级却远远高于这个8.0这个数字，新闻播报的背后，人们的一张张嘴脸，让人们认清了什么叫人心。

6年前的事让我知道了什么叫世态炎凉，3年前的汶川地震让我知道了什么叫万众一心，但是而后随着天灾人祸的发生率逐渐升高，人们开始习惯了，对受灾者的援助，同情也降到了一个史无前例的冰点，不过该过去的还是会过去，历史就是这样。

释放一下负面情绪，其实这几天除了手头这点活以外，偷闲搞定了RAZERBLOG的GALLERY，名曰RAZERGALLERY，实现功能为批量上传图片，批量删除分类图片，增删图片分类（GALLERY和ALBUM），双击添加进富文本编辑器图片，根据分类，上传日期整理图片等等功能，全盘采用JQUERY＋后台JSON的形式完成。

这里测试下添加图片的功能。

下午用了3个小时左右搞定，最近除了看连续剧外，花了比较多的时间在整理英语写作中的常见错误。下一个准备搞的就是可分类整理的豆知识笔记。主要参考TWITTER的模式，以可分类TAG的形式写TWITTER来可随时更新整理自己的豆知识。TWITTER对于交流，广告还有××来说还是很不错的，对于这种用途就显得有些局限了。虽然LIST和FAVORITE可以解决一部分问题，不过还是显得有些麻烦。

伪春菜的实现还是比较简单的，前台直接抄用了WP插件的CSS和主体布局。仅仅重写了JS加载部分和后台的JSON FEED部分。目前仅仅剩下安装后自动初始化春菜的一个CONFIG没有完成。因为短期内不打算把BLOG抽象化出来，所以暂时不着急补充。源代码估计也会在RAZERBLOG彻底完成后一起放出来。

这里仅仅做一个简单的记录。

JSON传输形式：

publicMessages:[],

ukagakaList:[],

returnData:{},

ukagaka:{defaultMessage:"Welcoming Here!",

title:"Ukagaka",

image:"/static/Ukagaka/images/default.png",

messageList:["Welcoming Here!","Go Mavs!"]},

这是传输过程中的主体传输部分。WP的插件大致看了下，往返传输的对象包括春菜名成，春菜图片地址和春菜的MESSAGE LIST。本身想仿照那个来写，后来因为考虑到可能在未来的应用上加上SOAP应用，所以最终放弃了原计划，写成了如上的形式。

这里不仅感慨下，DJANGO的GENERAL FOREIGNKEY真是好用，后台ADMIN如果再用JS来简化一下操作的话，就更是PERFECT了。

顺便感慨下，数组解析这个API，实在是太方便了。这个语句

defaultMpu=Ukagaka.objects.get(pk=1)

defaultMpu={"defaultMessage":defaultMpu.default_message,"title":defaultMpu.title,"description":defaultMpu.description,"image":defaultMpu.image.url,    "privateMessages":[msg.text for msg in defaultMpu.privatemessage_set.all()]}

如果用JAVA来写的话，至少需要走1个循环而且包括很多看着麻烦的赋值语句。代码数量和复杂度要比这两行要复杂的多。而这两行却包括了下列内容：

第一句比较简单，通过DJANGO包装的ORM取回了一个UKAGAKA对象，也就是一个春菜对象。

因为前后台数据传输是JSON数据，第二行通过一个简单的字典解析对第一句取回的春菜对象进行了重构，取出了需要传输的部分 。

下面简单说一下：

外面的大括号代表返回的是一个字典对象。其中defaultMessage,title等等都是字典的KEY，冒号后面的值是字典解析过程中的变量。这样一次字典解析就可以把一个复杂的对象还原成一个可通过JSON简单读取处理的可SERIALIZE对象。而其中的privateMessages的 VALUE部分则应用了数组解析的技巧，外面一个[]说明返回的是一个数组，同时内部数组解析走了一次循环，同样的技巧还可以包括一个或多个IF语句来进行属性判定，来筛选最后返回的数据。

不管是 看起来还是写起来，PYTHON只给人一种感觉，那就是EASY BETTER THAN DIFFICULT，CONCISE BETTER THAN VERBOSE。 对于METATYPE的动态元类，自己还掌握的不够，有时间去读一读PYTHON的源码，估计会有一些感受。

还有，过一阵还得把GALLERY的功能从POST里分离出来，现在这个管理图片太麻烦了。。。。。

昨天又花了一天的时间，整理的下资料，顺便查了查最佳的PAGE页面动态化解决方案，当然最节省资源的方案是每次更新后FLUSH数据库写入数据即可。包括LINK，ABOUT，和以后为写的部分“静态“页面的处理方案。不过考虑来考虑去，最终决定选择了适应性相对较差，但是可控性较强的动态页面AJAX加载的方式来解决。

缺点呢，就是不支持JS或对支持JS相对较差的浏览器在静态页面看不到动态内容，但是对于现在多数的浏览器而言，JS已经成了必不可缺的一环（IE众的各种傲娇我只能表示遗憾，对于逐年在流失的市场，这么硬派最终失掉的可能是整个江山，当UBUNTU已经上升成WINDOWS的竞争对手的同时，我只能说这个是WINDOWS的失败，而不是LINUX图形的胜利）。

优点，对于后台开发的全部插件，都尽量采用JSON+JS加载的方式来控制少量的动态内容，优点是当对于数据无验证需求时，这样可以保证对源代码的耦合性降到最低。

于是一期基本结束，这2天又DEBUG掉了不少虫子，不出意外的话应该不会有太多问题了。如果再出错误的话如果合适的话请尽量EMAIL我并告诉我出错的原因，我将会灰常的感谢的，嗯。

折腾了3周整的东西终于上线了。用了一周的时间学习WP的数据库和并还原成PYTHON对象，用了半周的时间熟悉了2个PYTHON的当红架构DJANGO和WEB2PY，最终还是决定走回类JAVA的JANGO的路途中。

WEB2PY对象的声明属于典型的数据库驱动型，而且页面模板也可直接用PYTHON语句，对于习惯用编程语言写界面的人来说确实能方便不少，不过对于习惯MVC的整洁感的人来说这个很可能带来很致命的安全性问题的弊病。而且对于页面的整洁感也会带来一些影响。不过不管怎么说，每个人都有自己的习惯，也不会出现对错的问题，只是实践的方法不同了而已。

今天花了大半天的时间来折腾WSGI和PYTHON_MOD,因为服务器是CENTOS，所以默认的PYTHON版本是2.4，升到2.6后对YUM产生了一定的影响，解决方法呢，更改/usr/bin/yum的第一行的env python为python2.4然后全部解决。

扔到生产环境下PRINT语句就失效了，感觉真是难受，BUG主要出在了三个地方：

1：TWITTE栏为空。这点可以说是折腾我时间最久的BUG。DEVELOP环境下没问题，但是APACHE下就有。最后多方DEBUG后发现，居然是CACHE文件夹的读写权限出了问题，暂时解决方案chmod 777 /cache/python*username后解决。

2：部分页面提示数据库不可随机写入。这个问题，当时就想到是读写权的问题了，直接目录CHMOD 777解决。

P.S.:这些解决方案都是临时解决方案，最佳解决方案是重设APACHE用户名和组，然后对文件夹设定适应的权限而非给与777，这个只是为了DEBUG而在偷懒而已。

3：AKISMET的问题。。。

这点太纠结人了。偶尔提示说unicodedecodeerror: 'ascii' codec can't decode byte 0xe4 in position 5: ordinal not in range,这个错误总见了，因为ENVIRONMENT的区码带来的问题。于是跟代码，重新作判断，type(string)==str的话对其作string.decode('utf-8').encode('utf-8')后全线解决。最后给下AKISMET的提交参数：

blog(required)

user_ip(required)

user_agent (required)

referrer(note spelling)

permalink

comment_type

comment_author

comment_author_email

comment_author_url

comment_content

这里在实质判断上可以说除了permalink和comment_type以外都很重要。做了大概有20-30个SPAM测试，大概抓取率有40%左右吧，先扔生产环境测试一阵，如果有问题的话再考虑是加CAPTCHA还是通过默认FALSE来解决了。 嗯，废话就到这里。到周末剩余的几天作为测试环境，整理DOC和API，下一步准备写一个GALLERY出来，然后把THEME功能给实现了。至于插件，实现其实也比较简单，后台，这个我比较纠结。以后有时间慢慢再弄吧。 这里感谢一下在写代码的过程中帮忙调试的众位童鞋，回去一定要请你们吃火锅>_<。 以上，躺尸，累死了～