iUI: iPhone User Interface Framework

iUI is a framework consisting of a JavaScript library, CSS, and images for developing iPhone webapps.

Makes WebApps Look and Feel Like iPhone Native Apps

iUI has the following features:

Create Navigational Menus and iPhone interfaces from standard HTML
Use or knowledge of JavaScript is not required to create basic iPhone pages
Ability to handle phone orientation changes
Provide a more “iPhone-like” experience to Web apps (on or off the iPhone)
For more information, see the Introduction page.

框架主页：http://code.google.com/p/iui/

IUI是iPhone web开发前端框架，用css，html，js打造iPhone app界面，IUI内置了很多应用，如音乐站，购物站，digg站，资讯站…..这些你都可以在IUI上找到……..

测试截图：





相信上面是WEB界面吗？试试IUI吧。

关于iPhone web开发可以参考：
使用 Aptana 的 iPhone Development 插件开发 iPhone Web 应用程序

Apple 的 iPhone 平台为开发人员提供了一个有趣的机会。借助其小型的交互式触摸屏，iPhone 和 iPod Touch 在很短的时间内迅速吸引了数百万用户。但是这种新颖的设计和专利平台给应用程序开发人员带来了一系列新的挑战。幸运的是，使用一系列新的开源工具可以更轻松地完成这项工作。Aptana 的针对 Eclipse 的 iPhone Development 插件可以生成特定于 iPhone 的项目，并在可旋转取景器中预览应用程序。

官方网站：http://www.aptana.org/

在开始设计iPhone浏览界面 之前，一定要先了解 iPhone 开发与普通 Web 开发的不同之处。来自 Apple 的 iPhone Dev Center（请参阅 参考资料）(上图)，很好地总结了两者的不同之处：手指不是鼠标。这样做得不到桌面应用程序中的像素精度，但是通过轻敲、轻弹和轻压将开启一个丰富的新用户交互模型。此外，iPhone 与用户一起移动并且通常用于有干扰的环境中，因此应用程序需要能够快速容易地访问目标信息。

这里可以参考我以前写过的一篇文章：http://www.ieliwb.com/myiphones-iphone-site/

安装 Aptana Studio, 及iphone开发插件：

首先安装Aptana Studio V2.0.2，完成后在 Aptana Studio V2.0.2中，选择 Help > Software Updates > Find and Install。
选择 Search for new features to install。此窗口列出了可以从中下载插件的站点以及 Eclipse 预定义的插件。
单击 New Remote Site 将 iphone插件 添加到此列表中，并使用 URL http://update1.aptana.org/iphone/3.2/ 对其进行定义。
从列表中选择新定义的 Aptana 站点，单击 Next，然后安装所有可用功能。完成此窗口安装基本的 Aptana Editor。
重新启动 Aptana Studio。新建一个项目就可以看到有iPhone web development的选项了。

详细步骤就不写了（英文原文：http://update1.aptana.org/iphone/3.2/index.html），一路点下去就可以，注意打勾和不打勾的。

调试界面：

注意由 Aptana 的基本编辑器提供的突出显示的语法，它支持 HTML、CSS 和 JavaScript。
在文本编辑器的底部，您将看到 Source、iPhone 、IE等 选项卡，可以自己添加浏览器模式，建议安装Safari浏览器并设为默认浏览器，这样你调试的页面基本和iPhone上浏览的一摸一样，我这是用默认的IE调试有点错位，单击 iPhone Preview 查看示例应用程序在 iPhone 中的外观。在浏览器外部单击可以旋转电话，单击电话标题栏可以隐藏导航栏。

使用 iPhone Preview 模式可以节省大量时间：可以快速测试新设计想法并重复进行开发而无需离开计算机。

习惯于Eclipse开发的可以使用Aptana 的Eclipse插件来开发也可以，可以参考：IBM

最后推荐一个开源UI框架iUi：

User Interface (UI) Framework for Safari development on iPhone
地址：http://code.google.com/p/iui/

Comet（彗星：某人给服务器推送技术起的名字）

核心图解：

最近在看“服务器推送技术”，在B/S结构中，通过某种magic使得客户端不需要通过轮询即可以得到服务端的最新信息（比如股票价格，聊天室，webQQ、开心网、白社会），这样可以节省大量的带宽。

传统的轮询技术对服务器的压力很大，并且造成带宽的极大浪费。如果改用ajax轮询，可以降低带宽的负荷（因为服务器返回的不是完整页面），但是对服务器的压力并不会有明显的减少。

而推技术（push）可以改善这种情况。但因为HTTP连接的特性（短暂，必须由客户端发起），使得推技术的实现比较困难，常见的做法是通过延长http连接的寿命，来实现push。

基本实现原理：

接下来自然该讨论如何延长http连接的寿命，最简单的自然是死循环法，如果使用观察者模式则可以进一步提高性能。

但是这种做法的缺点在于客户端请求了这个servlet后，web服务器会开启一个线程执行servlet的代码，而servlet由迟迟不肯结束，造成该线程也无法被释放。于是乎，一个客户端一个线程，当客户端数量增加时，服务器依然会承受很大的负担。

要从根本上改变这个现象比较复杂，目前的趋势是从web服务器内部入手，用nio（JDK 1.4提出的java.nio包）改写request/response的实现，再利用线程池增强服务器的资源利用率，从而解决这个问题，目前支持这一非J2EE官方技术的服务器有Glassfish和Jetty。目前也有一些框架/工具可以帮助你实现推功能，比如pushlets。不过没有深入研究。还有就是通过设置超时来解决。

在客户和服务器之间保持“心跳”信息 —–无事件导致超时处理：

因为服务器为了保持请求（阻塞请求），必须有一个无限循环，循环的结束条件就是获取到了返回结果，如果客户端关闭了（客户端浏览器的关闭不会发消息给服务器），服务器无法知道客户端已经关了，这个请求没必要处理下去了，最终会造成资源过度浪费。还有服务器中间可能存在各式各样配置怪异的网关和代理，它们上面可能有各式各样的超时规则，因此Comet最好设计为定期重连。只要用一个折中的办法，限制超时时间。一般情况下，如果30秒没有任何事件发生，服务器端就应该通知客户端确实没有事件发生，结束掉本次请求，然后重新开始一次新的请求以便继续等待。这里可以不必设置客户端ajax的超时时间，但进行请求的时候传递一个超时值给服务器，服务器在处理的时候，如果超时时间到了的话，还没有客户端需要的结果，这时传递一个超时信息给客户端，客户端接收到了此信息，根据情况重新进行ajax请求，也就是进入下一个轮询……….当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。

服务器端事件队列管理以及如何保持可靠的消息队列:

由于ajax的LongPoll是拉的方式(不同的客户端拉取的参数可以根据客户端不同而不同)，服务器端根据客户选择的方式在读取事件队列（fetchEvents）时进行不同的处理，会把“heartbeat”与“refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。拉的同时也解决了发送目标的返回值。

在这里我们可以想象一个可能发生的情况，服务器端向你发送一个消息，你没有成功接收，但是服务器端认为发送了就成功了，消息从队列删除了，然后这个消息就永久丢失掉了。可能有人会强调TCP多么可靠，服务器端发送的消息如果在TCP的层面发生问题了，肯定会引发Socket级别的Exception，这个Exception冒泡上来，服务器端就能截获，从而得知发送失败，然后先不删除队首消息。可是别忘了，中间是可能存在代理的，如果代理成功把消息收回去了，可是代理发送到客户端这一步失败了，服务器端就不一定会发生异常了。

因此，我们需要制定一种策略，来确保下行消息总能发送到客户端。在这里，我们选择了引入逐个ACK的机制，来确认消息的接收。也就是说，服务器端发送给客户端的消息带有一个序号，在客户端收到消息后就将该序号发回给服务器端，已确认它受到了该消息。在下次请求时就将该序号加1的值通过sequence参数传递回去，让服务器知道我们期望下一条消息的编号是这个。例如我们收到Message，其Sequence属性为836，那么下一次调用的时候就传给服务器837。服务器端此时应该保留了编号为836的Message在对首，如果客户端继续请求836号消息，证明它上次没收到，这次仍然发送836号消息给它；如果客户端请求837号消息，证明它成功收到836号消息的，这次就发送837号消息给它。看到这里是不是感觉有点熟悉了，不错，这有点类似经典的TCP三握手原理。如果都不是，那该怎么办？那意味着，这是一个错误的请求，甚至可能是攻击请求，因为正常情况下不应该出现这样的请求的，服务器端可以考虑抛个无关紧要的Exception（不要告诉攻击者你知道他在攻击了），甚至直接给个400 （bad request）的响应代号。

国外一个简单的聊天室例子：
我们需要4个文件:
A file to exchange data (data.txt)
A PHP script that will handle the persistent http request (backend.php)
A HTML file that will load Javascript code and that will show the data coming from the server (index.html)
The prototype library that will help us to write simple JS code

服务端backend.php：
做2件事：
Write into “data.txt” when new messages are sent
Do an infinite loop as long as “data.txt” file is unchanged

客户端index.html：

例子完整源码下载：down

你可以用浏览器打开多个index.html，你在其中一个页面提交的聊天内容同时也被推到其他的页面。
这只是一个推的简单的例子，关于超时处理的相关功能就不贴了，自己研究。

总之。ajax模拟http长连接就是在第一次ajax发出请求的时候，服务端一直在等待有更新的数据，当然在等待过程中你可以加入超时重新开始下一个轮询来降低服务器压力(见上面的核心图)。

参考文章：
Erik Burckart：Comet 的诱惑
Comet：基于 HTTP 长连接的“服务器推”技术
How to implement COMET with PHP

贴代码吧：

直接复制上面html保存运行即可看到。
google的演示地址：go

实现方法很简单：
1.修改CMS发布系统编辑器，在上传图片时自动加上 onclick=”gonext();”
2.修改CMS模板，在头部加上如下的JavaScript函数gonext
3.修改CMS程序分页部分代码，在生成的下一页链接时加上 id=’nextid’

实现效果演示：http://aion.houdao.com/200909/26455.html

最近页面效果：

附我的一个解决Comment发表时间的函数：

都很好用的。

建立了号称“Web 2.0”的应用，也实现了富内容（rich content）和交互，我们期待着css和javascript扮演更加重要的角色。为使应用干净利落，我们需要完善那些渲染页面的文件，优化其大小和形态，以确保提供最好的用户体验——在实践中，这就意味着一种结合：使内容尽可能小、下载尽可能快，同时避免对未改动资源不必要的重新获取。

由于css和js文件的形态，情况有点复杂。跟图片相比，其源代码很有可能频繁改动。而一旦改动，就需要客户端重新下载，使本地缓存无效（保存在其他缓存里的版本也是如此）。在这篇文章里，我们将着重探讨怎样使用户体验最快：包括初始页面的下载，随后页面的下载，以及随着应用渐进、内容变化而进行的资源下载。

我始终坚信这一点：对开发者来说，应该尽可能让事情变得简单。所以我们青睐于那些能让系统自动处理优化难题的方法。只需少许工作量，我们就能建立一举多得的环境：它使开发变得简单，有极佳的终端性能，也不会改变现有的工作方式。

好大一沱
老的思路是，为优化性能，可以把多个css和js文件合并成极少数大文件。跟十个5k的js文件相比，合并成一个50k的文件更好。虽然代码总字节数没变，却避免了多个HTTP请求造成的开销。每个请求都会在客户端和服务器两边有个建立和消除的过程，导致请求和响应header带来开销，还有服务器端更多的进程和线程资源消耗（可能还有为压缩内容耗费的cpu时间）。

（除了HTTP请求，）并发问题也很重要。默认情况下，在使用持久连接（persistent connections）时，ie和firefox在同一域名内只会同时下载两个资源（在HTTP 1.1规格书中第8.1.4节的建议）（htmlor注：可以通过修改注册表等方法改变这一默认配置）。这就意味着，在我们等待下载2个js文件的同时，将无法下载图片资源。也就是说，这段时间内用户在页面上看不到图片。

（虽然合并文件能解决以上两个问题，）可是，这个方法有两个缺点。第一，把所有资源一起打包，将强制用户一次下载完所有资源。如果（不这么做，而是）把大块内容变成多个文件，下载开销就分散到了多个页面，同时缓解了会话中的速度压力（或完全避免了某些开销，这取决于用户选择的路径）。如果为了随后页面下载得更快而让初始页面下载得很慢，我们将发现更多用户根本不会傻等着再去打开下一个页面。

第二（这个影响更大，一直以来却没怎么被考虑过），在一个文件改动很频繁的环境里，如果采用单文件系统，那么每次改动文件都需要客户端把所有css和js重新下载一遍。假如我们的应用有个100k的合成的js大文件，任何微小的改动都将强制客户端把这100k再消化一遍。

分解之道
（看来合并成大文件不太合适。）替代方案是个折中的办法：把css和js资源分散成多个子文件，按功能划分、保持文件个数尽可能少。这个方案也是有代价的，虽说开发时代码分散成逻辑块（logical chunks）能提高效率，可在下载时为提高性能还得合并文件。不过，只要给build系统（把开发代码变成产品代码的工具集，是为部署准备的）加点东西，就没什么问题了。

对于有着不同开发和产品环境的应用来说，用些简单的技术可以让代码更好管理。在开发环境下，为使条理清晰，代码可以分散为多个逻辑部分（logical components）。可以在Smarty（一种php模板语言）里建立一个简单的函数来管理javascript的下载：

（htmlor注：wordpress中会把“src”替换成不知所谓的字符，因此这里只有写成“SOURCE”，使用代码时请注意替换，下同）

就这么简单。然后我们就命令build过程（build process）去把确定的文件合并起来。这个例子里，合并的是foo.js和bar.js，因为它们几乎总是一起下载。我们能让应用配置记住这一点，并修改模板函数去使用它。（代码如下：）

模板里的源代码没必要为了分别适应开发和产品阶段而改动，它帮助我们在开发时保持文件分散，发布成产品时把文件合并。想更进一步的话，可以把合并过程（merge process）写在php里，然后使用同一个（合并文件的）配置去执行。这样就只有一个配置文件，避免了同步问题。为了做的更加完美，我们还可以分析css和js文件在页面中同时出现的几率，以此决定合并哪些文件最合理（几乎总是同时出现的文件是合并的首选）。

对css来说，可以先建立一个主从关系的模型，它很有用。一个主样式表控制应用的所有样式表，多个子样式表控制不同的应用区域。采用这个方法，大多数页面只需下载两个css文件，而其中一个（指主样式表）在页面第一次请求时就会缓存。

对没有太多css和js资源的应用来说，这个方法在第一次请求时可能比单个大文件慢，但如果保持文件数量很少的话，你会发现其实它更快，因为每个页面的数据量更小。让人头疼的下载花销被分散到不同的应用区域，因此并发下载数保持在一个最小值，同时也使得页面的平均下载数据量很小。

压缩
谈到资源压缩，大多数人马上会想到mod_gzip（但要当心，mod_gzip实际上是个魔鬼，至少能让人做恶梦）。它的原理很简单：浏览器请求资源时，会发送一个header表明自己能接受的内容编码。就像这样：

服务器遇到这样的header请求时，就用gzip或deflate压缩内容发往客户端，然后客户端解压缩。这过程减少了数据传输量，同时消耗了客户端和服务器的cpu时间。也算差强人意。但是，mod_gzip的工作方式是这样的：先在磁盘上创建一个临时文件，然后发送（给客户端），最后删除这个文件。在高容量的系统中，由于磁盘io问题，很快就会达到极限。要避免这种情况，可以改用mod_deflate（apache 2才支持）。它采用更合理的方式：在内存里做压缩。对于apache 1的用户来说，可以建立一块ram磁盘，让mod_gzip在它上面写临时文件。虽然没有纯内存方式快，但也不会比往磁盘上写文件慢。

话虽如此，其实还是有办法完全避免压缩开销的，那就是预压缩相关静态资源，下载时由mod_gzip提供合适的压缩版本。如果把压缩添加在build过程，它就很透明了。需要压缩的文件通常很少（用不着压缩图片，因为并不能减小更多体积），只有css和js文件（和其他未压缩的静态内容）。

配置选项会告诉mod_gzip去哪里找到预压缩过的文件。

mod_gzip_static_suffix .gz
AddEncoding gzip .gz

新一点的mod_gzip版本（从1.3.26.1a开始）添加一个额外的配置选项后，就能自动预压缩文件。不过在此之前，必须确认apache有正确的权限去创建和覆盖压缩文件。

可惜，事情没那么简单。某些Netscape 4的版本（尤其是4.06-4.08）认为自己能够解释压缩内容（它们发送一个header这么说来着），但其实它们不能正确的解压缩。大多数其他版本的Netscape 4在下载压缩内容时也有各种各样的问题。所以要在服务器端探测代理类型，（如果是Netscape 4，就要）让它们得到未压缩的版本。这还算简单的。ie（版本4-6）有些更有意思的问题：当下载压缩的javascript时，有时候ie会不正确的解压缩文件，或者解压缩到一半中断，然后把这半个文件显示在客户端。如果你的应用对javascript的依赖比较大（htmlor注：比如ajax应用），那么就得避免发送压缩文件给ie。在某些情况下，一些更老的5.x版本的ie倒是能正确的收到压缩的javascript，可它们会忽略这个文件的etag header，不缓存它。（thincat友情提示：尽管压缩存在一些浏览器不兼容的现象，由于这些不能很好的支持压缩的浏览器数量现在已经非常少了，我认为这种由于浏览器导致的压缩不正常的情况可以忽略不计。这些过时的浏览器还能不能在现在流行的windows或unix环境下面安装都存在不小的问题）

既然gzip压缩有这么多问题，我们不妨把注意力转到另一边：不改变文件格式的压缩。现在有很多这样的javascript压缩脚本可用，大多数都用一个正则表达式驱动的语句集来减小源代码的体积。它们做的不外乎几件事：去掉注释，压缩空格，缩短私有变量名和去掉可省略的语法。

不幸的是，大多数脚本效果并不理想，要么压缩率相当低，要么某种情形下会把代码搞得一团糟（或者两者兼而有之）。由于对解析树的理解不完整，压缩器很难区分一句注释和一句看似注释的引用字符串。因为闭合结构的混合使用，要用正则表达式发现哪些变量是私有的并不容易，因此一些缩短变量名的技术会打乱某些闭合代码。

还好有个压缩器能避免这些问题：dojo压缩器（现成的版本在这里）。它使用rhino（mozilla的javascript引擎，是用java实现的）建立一个解析树，然后将其提交给文件。它能很好的减小代码体积，仅用很小的成本：因为只在build时压缩一次。由于压缩是在build过程中实现的，所以一清二楚。（既然压缩没有问题了，）我们可以在源代码里随心所欲的添加空格和注释，而不必担心影响到产品代码。

与javascript相比，css文件的压缩相对简单一些。由于css语法里不会有太多引用字符串（通常是url路径跟字体名），我们可以用正则表达式大刀阔斧的干掉空格（htmlor注：这句翻的最爽，哈哈）。如果确实有引用字符串的话，我们总可以把一串空格合成一个（因为不需要在url路径和字体名里查找多个空格和tab）。这样的话，一个简单的perl脚本就够了：

print $data;然后，就可以把单个的css文件传给脚本去压缩了。命令如下：

site.compress.css

做完这些简单的纯文本优化工作后，我们就能减少数据传输量多达50%了（这个量取决于你的代码格式，可能更多）。这带来了更快的用户体验。不过我们真正想做的是，尽可能避免用户请求的发生——除非确实有必要。这下HTTP缓存知识派上用场了。

缓存是好东西
当用户代理（如浏览器）向服务器请求一个资源时，第一次请求过后它就会缓存服务器的响应，以避免重复之后的相同请求。缓存时间的长短取决于两个因素：代理的配置和服务器的缓存控制header。所有浏览器都有不同的配置选项和处理方式，但大多数都会把一个资源至少缓存到会话结束（除非被明确告知）。

为了不让浏览器缓存改动频繁的页面，你很可能已经发送过header不缓存动态内容。在php中，以下两行命令可以做到：

听起来太简单了？确实如此——因为有些代理（浏览器）在某些环境下将忽略这些header。要确保浏览器不缓存文档，应该更强硬一些：

这样，对于我们不想缓存的内容来说已经行了。但对于那些不会每次请求时都有改动的内容，应该鼓励浏览器更霸道的缓存它。“If-Modified-Since”请求header能够做到这点。如果客户端在请求中发送一个“If-Modified-Since”header，apache（或其他服务器）会以状态代码304（没改过）响应，告诉浏览器缓存已经是最新的。使用这个机制，能够避免重复发送文件给浏览器，不过仍然导致了一个HTTP请求的消耗。嗯，再想想。

与If-Modified-Since机制类似的是实体标记（entity tags）。在apache环境下，每个对静态文件的响应都会发出一个“ETag”header，它包含了一个由文件修改时间、文件大小和inode号生成的校验和（checksum）。在下载文件之前，浏览器会发送一个HEAD请求去检查文件的etag。可ETag跟If-Modified-Since有同样的问题：客户端仍旧需要执行HTTP请求来验证本地缓存是否有效。

此外，如果你使用多台服务器提供内容，得小心使用if-modified-since和etags。在两台负载平衡的服务器环境下，对一个代理（浏览器）来说，一个资源可以这次从A服务器得到，下次从B服务器得到（htmlor注：lvs负载平衡系统就是个典型的例子）。这很好，也是采用平衡负载的原因。可是，如果两台服务器给同一个文件生成了不同的etag或者文件修改日期，浏览器就无所适从了（每次都会重新下载）。默认情况下，etag是由文件的inode号生成的，而多台服务器之间文件的inode号是不同的。可以使用apache的配置选项关掉它：

使用这个选项，apache将只用文件修改日期和文件大小来决定etag。很不幸，这导致了另一个问题（一样能影响if-modified-since）。既然etag依赖于修改时间，就得让时间同步。可往多台服务器上传文件时，上传时间差个一到两秒是常有的事。这样一来，两台服务器生成的etag还是不一样。当然，我们还可以改变配置，让etag的生成只取决于文件大小，但这就意味着如果文件内容变了而大小没变，etag也不会变。这可不行。

缓存真是个好东西
看来我们正从错误的方向入手解决问题。（现在的问题是，）这些可能的缓存策略导致了一件事情反复发生，那就是：客户端向服务器查询本地缓存是否最新。假如服务器在改动文件的时候通知客户端，客户端不就知道它的缓存是最新的了（直到接到下一次通知）？可惜天公不做美——（事实）是客户端向服务器发出请求。

其实，也不尽然。在获取js或css文件之前，客户端会用< script >或 标记向服务器发送一个请求，说明哪个页面要加载这些文件。这时候就可以用服务器的响应来通知客户端这些文件有了改动。有点含糊，说得再详细点就是：如果改变css和js文件内容的同时，也改变它们的文件名，就可以告诉客户端对url全都永久缓存——因为每个url都是唯一的。

假如能确定一个资源永不更改，我们就可以发出一些霸气十足的缓存header（htmlor注：这句也很有气势吧）。在php里，两行就好：

我们告诉浏览器这个内容在10年后（10年大概会有315,360,000秒，或多或少）过期，浏览器将会保留它10年。当然，很有可能不用php输出css和js文件（因此就不能发出header），这种情况将在稍后说明。

人力有时而穷
当文件内容更改时，手动去改文件名是很危险的。假如你改了文件名，模板却没有指向它？假如你改了一些模板另一些却没改？假如你改了模板却没改文件名？还有最糟的，假如你改动了文件却忘了改名或者忘了改变对它的引用？最好的结果，是用户看到老的而看不到新的内容。最坏的结果，是找不到文件，网站没法运转了。听起来这（指改动文件内容时修改url）似乎是个馊主意。

幸运的是，计算机做这类事情——当某种变化发生，需要相当准确地完成的、重复重复再重复的（htmlor注：番茄鸡蛋伺候～）、枯燥乏味的工作——总是十分在行。

这个过程（改变文件的url）没那么痛苦，因为我们根本不需要改文件名。资源的url和磁盘上文件的位置也没必要保持一致。使用apache的mod_rewrite模块，可以建立简单的规则，让确定的url重定向到确定的文件。

这条规则匹配任何带有指定扩展名同时含有“版本”信息（version nugget）的url，它会把这些url重定向到一个不含版本信息的路径。如下所示：

使用这条规则，就可以做到不改变文件路径而更改url（因为版本号变了）。由于url变了，浏览器就认为它是另一个资源（会重新下载）。想更进一步的话，可以把我们之前说的脚本编组函数结合起来，根据需要生成一个带有版本号的< script >标记列表。

说到这里，你可能会问我，为什么不在url结尾加一个查询字符串（query string）呢（如/css/main.css?v=4）？根据HTTP缓存规格书所说，用户代理对含有查询字符串的url永不缓存。虽然ie跟firefox忽略了这点，opera和safari却没有——为了确保所有浏览器都缓存你的资源，还是不要在url里用查询字符串的好。

现在不移动文件就能更改url了，如果能让url自动更新就更好了。在小型的产品环境下（如果有大型的产品环境，就是开发环境了），使用模板功能可以很轻易的实现这点。这里用的是smarty，用其他模板引擎也行。

对每个链接到的资源文件，我们得到它在磁盘上的路径，检查它的mtime（文件最后修改的日期和时间），然后把这个时间当作版本号插入到url中。对于低流量的站点（它们的stat操作开销不大）或者开发环境来说，这个方案不错，但对于高容量的环境就不适用了——因为每次stat操作都要磁盘读取（导致服务器负载升高）。

解决方案相当简单。在大型系统中每个资源都已经有了一个版本号，就是版本控制的修订号（你们应该使用了版本控制，对吧？）。当我们建立站点准备部署的时候，可以轻易的查到每个文件的修订号，写在一个静态配置文件里。

当我们发布产品时，可以修改模板函数来使用版本号。

就这样，不需要改文件名，也不需要记住改了哪些文件——当文件有新版本发布时它的url就会自动更新——有意思吧？我们就快搞定了。

只欠东风
之前谈到为静态文件发送超长周期（very-long-period）的缓存header时曾说过，如果不用php输出，就不能轻易的发送缓存header。很显然，有两个办法可以解决：用php输出，或者让apache来做。

php出马，手到擒来。我们要做的仅仅是改变rewrite规则，把静态文件指向php脚本，用php在输出文件内容之前发送header。

这个方案有效，但并不出色。（因为）跟apache相比，php需要更多内存和执行时间。另外，我们还得小心防止可能由path参数传递伪造值引起的exploits。为避免这些问题，应该用apache直接发送header。rewrite规则语句允许当规则匹配时设置环境变量（environment variable），当给定的环境变量设置后，Header命令就可以添加header。结合以下两条语句，我们就把rewrite规则和header设置绑定在了一起：

考虑到apache的执行顺序，应该把rewrite规则加在主配置文件（httpd.conf）而不是目录配置文件（.htaccess）中。否则在环境变量设置之前，header行会先执行（就那没意义了）。至于header行，则可以放在两文件任何一个当中，没什么区别。

眼观六路
（htmlor注：多谢tchaikov告知“skinning rabbits”的含义，但我不想翻的太正式，眼下的这个应该不算太离谱吧。）

通过结合使用以上技术，我们可以建立一个灵活的开发环境和一个快速又高性能的产品环境。当然，这离终极目标“速度”还有一段距离。有许多更深层的技术（比如分离伺服静态内容，用多域名提升并发量等）值得我们关注，包括与我们谈到的方法（建立apache过滤器，修改资源url，加上版本信息）殊途同归的其他路子。你可以留下评论，告诉我们那些你正在使用的卓有成效的技术和方法。

引用地址：http://www.xufeng.org/?action=show&id=30

效果图：

像不像画的图啊，其实是DIV+CSS写的。DIY过程更像是在操作iPhone手机。嘿嘿。

已完成及正在完成的功能：
1.ICON路径等入库
2.生成ZIP文件下载
3.网友上传文件入库，格式转换png
4.与DEDECMS主题频道的接口
5.解剖已发主题内置ICON并入库
6.与通行证的接口（未完成）
就目前的形式看，程序估计要扼杀在摇篮里。衰……

基本思路提示：
代码就不发了，说下思路。首先根据素材库选择主题图标，点击生成按钮将获取所有图标的ID和地址，接着PHP开始上场，根据提交过来的图标地址和ID，开始获取所有图标，并压缩生成ZIP文件，再根据手机主题的编码方式生成主题。在这过程中同步生成缩略图，并发布到主题频道下载。

目前几个主题在线生成网站：
www.moxiu.com
www.qzhuti.com
www.ownskin.com
思路都差不多。

验证码作为防止表单垃圾信息普遍采用的方法，一直被广泛使用。但是同时它造成了很不好的用户体验，为合法用户的正常操作带来不便。本文介绍了一种抛弃使用验证码的方法，来防止自动程序进行垃圾信息的提交。
原文链接：（http://15daysofjquery.com/examples/contact-forms/），简单试验了一下效果不错。

原理：
核心部分就是在页面被载入时，采用AJAX动态创建一个特定的隐藏表单元素（姑且叫令牌吧），该元素只有在真正用户访问时才会存在，对于自动化的“机器人”来说是不存在的。通过客户端提交的隐藏表单的令牌和服务器端的对比来验证是否机器人。

1、当表单被载入后，我们创建一个到PHP文件的AJAX调用；
2、该PHP文件将取得当前时间（依靠服务器，并不是访问者的浏览器）；
3、该PHP文件将结合时间戳，加上一个加密的字（用户自定义的一个字符串——译者注），产生一个32位的“哈希”并把它作为cookie存储到访问者的浏览器上；
4、jQuery将接收这个从AJAX调用来的时间戳信息，并将该哈希值或“令牌”作为表单的隐藏标签而存储；
5、当该表单为处理而被发送，这个时间戳的值（表单中的——译者注）将和存储在cookie中的32位字符“令牌”做比较；
6、如果信息不匹配，或是丢失，又或者时间戳过期，我们将终止表单处理的执行，同时这个垃圾邮件发送者将会把目标转移到另一个简单的猎物上（放弃我们这个目标——译者注）。

实战演习：
核心就3个文件：
1.前端提交发表页面：demo.htm
2.产生令牌页面：token.php
3.提交处理页面：test.php

1.前端提交发表页面：demo.htm

这里用jQuery实现AJAX，在页面加载完毕后从token.php获取“令牌”,相当于获取验证码图片。
上面的令牌从下面的文件获取token.php

2.产生令牌页面：token.php

3.提交处理页面：test.php

到此全部ALL了，测试吧！不过验证码也不是毫无用处，比如可以为那些手动提交垃圾信息的人带来阻碍等。大家可以尝试一下，具体情况当然还得具体对待:)，不过图片验证码用户体验确实不好，下篇我将介绍简单的计算运算验证码。