分类：Web

免费的可视化的HTML编辑器

Dreamweaver是非常好的可视化HTML编辑器，但必尽是收费软件。虽然这个软件也有Mac版，但我感觉不怎么好用，之后就被我删除了。我一直使用Aptana做为我的主要IDE开发工具，但这种软件也无法达到像Dreamweaver这样的高度，因为Aptana这类软件只能提供一个内嵌的浏览器来预览，但始终不能进行编辑。
像专业的前端开发人员，手写HTML代码不应该是问题，所以可视化编辑并不是必须的。也许更希望看到某一个HTML标记的长宽、padding、margin属性信息。于是我想到了Firebug Lite，如果你不知道Firebug是什么的话，你基本不用做前端的东西了。由于Firebug现在只能在Firefox中运行，其它浏览器无法得到这个扩展带来的帮助，但Firebug有一个Lite版本，可以在任意浏览器中运行。Firebug Lite是用纯JavaScript实现的，并不依赖任务浏览器环境，但在提供的功能上要差许多，但是查看每一个HTML标记的坐标信息还是显示了的。
使用Firebug Lite也非常简单，只需要在页面中加载一段js就可以了。

这样的话就可以结合Aptana + Firebug Lite来做简单的页面设计开发了。

ajaxlibs。。算了吧

jquery已经成为我经常用的东西了，如果不是严格要求的页面的速度的情况下，我肯定会用它的。于是，我使用了google提供了jquery库的host，据说是有CDN的，但在我国网络实际使用中，非常慢，这种免费的午餐还是算了吧，就算放在自己的服务器上，然后打开gzip，这样的速度都会比gogole的强很多。

lighttpd server.error-handler-404问题

在使用Lighttpd部署站点的时候，有可能会设置server.error-handler-404来处理404的错误页面。使用Google管理员工具的时候需要对站点进行验证，有两种验证方法，其中一种是在服务器创建一个特殊的文件。但在验证过程上发现了奇怪的错误，提供“我们检测到您的 404（找不到文件）出错页在标头中返回 200（成功）状态”。根据Google的帮助文档这个问题是一个应该是404的页面返回了200的状态码，这听起来怎么这么绕口。。。Google除了验证特殊文件名的文件之外，还会验证404页面是否正常。

在解决这个问题时，发现原来是Lighttpd的Bug，文档如下：

Versions of lighttpd prior to 1.4.17 contained bugs in the implementation of this directive that meant a 404 status code generated from dynamic content was sent to the error handler. This prevented a 404 status code being sent from the error handler itself, which always returned status 200. If you are using an older version, and want to send a 404 status code please use server.errorfile-prefix; however, server.errorfile-prefix does not allow dynamic handlers.

http://redmine.lighttpd.net/projects/lighttpd/wiki/Server.error-handler-404Details

而服务器上的是1.4.13。

当Python2.4.3碰到Gmail

最近，再使用Django发邮件的时候出现一个问题，就此记下。我是通过gmail的smtp来发送邮件的，但在服务器测试的时候发现The read operation timed out的问题，后来在网上一查，原来是Python2.4.3中smtp库的问题，不过这个问题已经在python2.4.4中fix了。

原文在这。

Ajax的跨域问题

前段时候，碰到了Ajax的跨域问题，这可真是头痛的问题啊。在网上寻找了许多方法，大多数是讲通过相关domain属性来实现。我也看了网上的一个例子，好像可用。但我自己通过这个例子却无法实现。后台想了个更绝的方法来解决这个问题。

基本思想还是通过一个iframe来做代理，参数通过URL传过去。在需要跨域调用ajax时，动态创建一个iframe，然后src是引用需要求域的一个页面，在这个页面中发送ajax请求，然后访问相应的输出。我试的时候，能够在iframe的页面中调用父页面的function，但父页面不能调用iframe中的function。

看了就是一个汗啊

刚才在Google Friend Connect里面看到了social bar的东西，这个东西上面有成员、评论、活动这几个元素酷。这些看起来已经很有威力了，如果一个加入了足够多的Google Friend Connect，信息应该产生惊人的传播。

最终，所有的信息都重新流回了Google，真是高明至极。

Discuz!6.1和jquery的冲突

由于需要在Discuz!6.1中使用jquery库，但后来发现用不了，也找不到原因，之后去网上一找，原来是因为Discuz!6.1的common.js修改Array对象的prototype方法，造成的问题。解决方法是：

if(typeof Array.prototype.push === 'undefined') {
 Array.prototype.push = function(value) {
        this[this.length] = value;
        return this.length;
 }
}

对这个方法进行判断。这解决这个问题的过程中，算是理解了一些奇怪写法的js代码。比如：

(function($){

…….

}){jQuery}

这种写法使用了闭包的一些特性。通过一个匿名函数来隐藏变更的作用域，这样在这个函数体内还是使用$为jQuery对象的引用，呵呵，原来写的代码在有冲突的页面中就不需要修改了。

在其它程序中调用Discuz!的搜索功能

最近，有个项目需要整合Discuz!论坛，有一个主搜索导航，可以直接搜索论坛相关内容。但经过分析源代码后，Discuz!的搜索不是简单的提问查询词，Discuz!中会自己生成一个查询索引，通过那个索引id来做定位查询词。

整体思路是模拟搜索表单的提交，但在模拟时发现一个问题，Discuz!会根据用户生产hash值，当提交后，当然会判断这个hash值，这会非常麻烦，因为这个hash值需要一些Discuz!初始化的变量才能产生。所以先在程序去掉这个验证。程序在：

include/global.func.php文件中的submitcheck函数，在889行开始，有一个条件判断：$GLOBALS[‘formhash’] == formhash()，只要把这个去就可以，但这样会对论坛的安全性造成一些问题。

注意：Discuz!和整合的程序必须是在一个域内才行。

del.icio.us的json数据有问题

今天，尽然又碰到了，记得原来在使用dei.icio.us的json数据输出的时候，就发生过问题。今天好像也碰到了类似的问题，具体还没有分析出现，应该是某个符号造成的.

当标题中有\符号的时候，一般对json decode的时候会报错