w1100n
This site is best viewed in Google Chrome
wiloon, 1/6/2015 3:48 | Tag:

浏览器的后退按钮是AJAX开发时候最让人头疼的一块,有的时候遇到这种问题,实在没有结果的情况下我们只能交给用户去学习适应,本文从缓存、JS跳转等方面阐述了如何绕过此问题,还是很值得我们借鉴的,虽然解释语言是ASP,但估计不会造成理解障碍。如果各位有什么其它的方法,不妨拿出来分享一下:)   浏览器的后退按钮使得我们能够方便地返回以前访问过的页面,它无疑非常有用。但有时候我们不得不关闭这个功能,以防止用户打乱预定的页面访问次序。本文介绍网络上可找到的各种禁用浏览器后退按钮方案,分析它们各自的优缺点和适用场合。 一、概述 曾经有许多人问起,“怎样才能‘禁用’浏览器的后退按钮?”,或者“怎样才能防止用户点击后退按钮返回以前浏览过的页面?”在ASP论坛上,这个问题也是问得最多的问题之一。遗憾的是,答案非常简单:我们无法禁用浏览器的后退按钮。 起先我对于居然有人想要禁用浏览器的后退按钮感到不可思议。后来,看到竟然有那么多的人想要禁用这个后退按钮,我也就释然(想要禁用的只有后退按钮,不包括浏览器的前进按钮)。因为在默认情况下,用户提交表单之后可以通过后退按钮返回表单页面(而不是使用“编辑”按钮!),然后再次编辑并提交表单向数据库插入新的记录。这是我们不愿看到的。 因此我就决定要找出避免出现这种情况的方法。我访问了许多网站,参考了这些网站所介绍的各种实现方法。如果你经常访问ASP编程网站,本文所介绍的部分内容你可能已经见到过。本文的任务是把各种可能的方法都介绍给大家,然后找出最好的方法! 二、禁止缓存 在我找到的许多方案中,其中有一种建议禁止页面缓存。具体是使用服务器端脚本,如下所示: <% Response.Buffer = True Response.ExpiresAbsolute = Now() – 1 Response.Expires = 0 Response.CacheControl = “no-cache” %> 这种方法非常有效!它强制浏览器重新访问服务器下载页面,而不是从缓存读取页面。使用这种方法时,编程者的主要任务是创建一个会话级的变量,通过这个变量确定用户是否仍旧可以查看那个不适合通过后退按钮访问的页面。由于浏览器不再缓存这个页面,当用户点击后退按钮时浏览器将重新下载该页面,此时程序就可以检查那个会话变量,看看是否应该允许用户打开这个页面。 例如,假设我们有如下表单: <% Response.Buffer = True Response.ExpiresAbsolute = Now() – 1 Response.Expires = 0 Response.CacheControl … Continue reading

wiloon, 6/10/2014 7:22 | Tag:

浏览器中F5和CTRL F5的行为区别 作者: JeremyWei | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明 网址: http://weizhifeng.net/difference-between-f5-and-ctrl-f5.html 前言 在印象中,浏览器中的F5和刷新按钮是一样的效果,都是对当前页面进行刷新;Ctrl-F5的行为也是刷新页面,但是会清除浏览器缓存,这在前端调试时候会常用。二者真正的区别是什么呢?在stackoverflow上有人给出了很详细的解释,整理如下。 说明 在不同的浏览器中F5和CTRL-F5的行为是不一样的,但是他们的主要行为还是非常相似的,以下结果是在FF,IE,Opera和Chrome中进行过测试得出。 F5使用缓存,并且只有在资源内容发生变化的时候才会去更新资源。 当刷新一个页面的时候,浏览器会尝试使用各种类型的缓存,并且会发送If-Modified-Since头到服务器,如果服务器返回304 Not Modified,那么浏览器会使用本地的缓存;如果服务器返回200 OK和资源内容,那么浏览器会使用返回的资源内容,并把资源内容进行缓存,待下次使用。 CTRL-F5 强制更新页面资源的缓存。 MSIE会发送Cache-Control: no-cache头,Firefox和Chrome除了发送Cache-Control: no-cache头之外,还会发送Pragma: no-cache头。Opera比较另类,不发送任何和缓存相关的头。 以下表格很直观的表明了F5和CTRL-F5的行为,由于原文中测试的浏览器版本较低,所以进行了更新。 F5 and CTRL-F5 ┌────────────┬───────────────────────────────────────────────┐ │ UPDATED │ Firefox 3.x 4.x │ │2011-04-24 │ ┌────────────────────────────────────────────┤ │ … Continue reading

wiloon, 5/21/2014 3:37 | Tag:

写spring的代码到现在,一直都很习惯性的拷贝web.xml中的内容,没怎么在意里面的内容,最近认真研究了下,很多东西都不是很理解,特别是classpath和classpath*的区别,研究了许久才搞明白,记录下备忘。 classpath 和 classpath* 区别: classpath:只会到你指定的class路径中查找找文件; classpath*:不仅包含class路径,还包括jar文件中(class路径)进行查找. 举个简单的例子,在我的web.xml中是这么定义的:classpath*:META-INF/spring/application-context.xml 那么在META-INF/spring这个文件夹底下的所有application-context.xml都会被加载到上下文中,这些包括META-INF/spring文件夹底下的 application-context.xml,META-INF/spring的子文件夹的application-context.xml以及jar中的application-context.xml。 如果我在web.xml中定义的是:classpath:META-INF/spring/application-context.xml 那么只有META-INF/spring底下的application-context.xml会被加载到上下文中。

wiloon, 2/19/2014 6:28 | Tag:

  Bower是用于web前端开发的包管理器。对于前端包管理方面的问题,它提供了一套通用、客观的解决方案。它通过一个API暴露包之间的依赖模型,这样更利于使用更合适的构建工具。Bower没有系统级的依赖,在不同app之间也不互相依赖,依赖树是扁平的。 Bower运行在Git之上,它将所有包都视作一个黑盒子。任何类型的资源文件都可以打包为一个模块,并且可以使用任何规范(例如:AMD、CommonJS等)。 http://blog.fens.me/nodejs-bower-intro/ http://javascript.ruanyifeng.com/tool/bower.html http://blog.fens.me/nodejs-bower-intro/

wiloon, 1/6/2014 8:48 | Tag:

我的读后感:由于第一次接触WebService,对于很多概念不太理解,尤其是看到各个OpenAPI的不同提供方式时,更加疑惑。如google map api采用了AJAX方式,通过javascript提供API,而淘宝TOP则采用直接的HTTP+XML请求方式,最令我疑惑的是教材上讲的WSDL,UDDI从没有在这些API中出现过。现在知道了WebService原来有两种方式,一是SOAP协议方式,在这种方式下需要WSDL,UDDI等,二是REST方式,这种方式根本不需要WSDL,UDDI等。而且REST方式现在看来是更加流行,更有前途的方式。 在SOA的基础技术实现方式中WebService占据了很重要的地位,通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受,同时各大网站不断开放API提供给开发者,也激起了REST风格WebService的热潮。 在收到新需求Email之前,我对REST的理解仅仅是通过半懂不懂的看了Fielding的REST博士论文,说实话当时也就是希望了解这么一个新概念,对于其内部的思想只是很肤浅的了解了一下。 ASF的最新需求就是可能需要实现REST风格的WebService集成,因此不得不好好的去看看REST的真正思想含义以及当前各大网站的设计方式。后面所要表述的也是我这个初学者的一些看法和观点,抛砖引玉,希望在我将REST融入到ASF之前能够获得更多的反馈和意见。 SOAP 什么是SOAP,我想不用多说,google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案,简单对象访问协议,很轻量,同时作为应用协议可以基于多种传输协议来传递消息(Http,SMTP等)。但是随着SOAP作为WebService的广泛应用,不断地增加附加的内容,使得现在开发人员觉得SOAP很重,使用门槛很高。在SOAP后续的发展过程中,WS-*一系列协议的制定,增加了SOAP的成熟度,也给SOAP增加了负担。 REST REST其实并不是什么协议也不是什么标准,而是将Http协议的设计初衷作了诠释,在Http协议被广泛利用的今天,越来越多的是将其作为传输协议,而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子,SOAP消息完全就是将Http协议作为消息承载,以至于对于Http协议中的各种参数(例如编码,错误码等)都置之不顾。其实,最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查,而互联网上的各种资源就好比数据库中的记录(可能这么比喻不是很好),对于各种资源的操作最后总是能抽象成为这四种基本操作,在定义了定位资源的规则以后,对于资源的操作通过标准的Http协议就可以实现,开发者也会受益于这种轻量级的协议。 自己理解的将REST的思想归结以下有如下几个关键点: 1.面向资源的接口设计 所有的接口设计都是针对资源来设计的,也就很类似于我们的面向对象和面向过程的设计区别,只不过现在将网络上的操作实体都作为资源来看待,同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计,其实是RPC-REST的混合体,并非是REST的思想。 2.抽象操作为基础的CRUD 这点很简单,Http中的get,put,post,delete分别对应了read,update,create,delete四种操作,如果仅仅是作为对于资源的操作,抽象成为这四种已经足够了,但是对于现在的一些复杂的业务服务接口设计,可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题,如果要完全按照REST的思想来设计,那么适用的环境将会有限制,而非放之四海皆准的。 3.Http是应用协议而非传输协议 这点在后面各大网站的API分析中有很明显的体现,其实有些网站已经走到了SOAP的老路上,说是REST的理念设计,其实是作了一套私有的SOAP协议,因此称之为REST风格的自定义SOAP协议。 4.无状态,自包含 这点其实不仅仅是对于REST来说的,作为接口设计都需要能够做到这点,也是作为可扩展和高效性的最基本的保证,就算是使用SOAP的WebService也是一样。 REST vs SOAP 成熟度: SOAP虽然发展到现在已经脱离了初衷,但是对于异构环境服务发布和调用,以及厂商的支持都已经达到了较为成熟的情况。不同平台,开发语言之间通过SOAP来交互的web service都能够较好的互通(在部分复杂和特殊的参数和返回对象解析上,协议没有作很细致的规定,导致还是需要作部分修正) REST国外很多大网站都发布了自己的开发API,很多都提供了SOAP和REST两种Web Service,根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想,因此各个网站的REST实现都自有一套,在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况,在性能和可用性上会大大高于SOAP发布的web service,但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发,因此通用性要求不高。 ASF上考虑发布REST风格的Web Service,可以参考几大网站的设计(兄弟公司的方案就是参考了类似于flickr的设计模式),但是由于没有类似于SOAP的权威性协议作为规范,REST实现的各种协议仅仅只能算是私有协议,当然需要遵循REST的思想,但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。 总的来说SOAP在成熟度上优于REST。 效率和易用性: SOAP协议对于消息体和消息头都有定义,同时消息头的可扩展性为各种互联网的标准提供了扩展的基础,WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。 REST被人们的重视,其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了Http最初的应用协议设计理念。同时,在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式,除了传统的xml作为数据承载,还有(JSON,RSS,ATOM)等形式,这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。 因此在效率和易用性上来说,REST更胜一筹。 安全性: 这点其实可以放入到成熟度中,不过在当前的互联网应用和平台开发设计过程中,安全已经被提到了很高的高度,特别是作为外部接口给第三方调用,安全性可能会高过业务逻辑本身。 SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的,当前已经得到了各个厂商的支持,.net ,php … Continue reading

辽ICP备14012896