Thu, 30 Apr 2009 00:52:00 GMT卧居古城，静候伯乐http://blog.csdn.net/Killvin/http://blog.csdn.net/Killvin/archive/2009/04/30/4138354.aspxhttp://blog.csdn.net/Killvin/comments/4138354.aspx0http://blog.csdn.net/Killvin/comments/commentRss/4138354.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=4138354<br />smarttag灵感来源于公司的一个项目，其实早在上一个公司工作的时候项目组就用到过一个第三方的tag来分页展现数据，总的来说还行，但就是扩展性差了点,而目前的公司也存在已有的分页tag，但无论从使用还是架构上来说都是非常失败的，原因在于：<br />1.没有使用原生的Tag表现形式（继承TagSupport），而是采用基于JSTL组合的方法，从实现的角度看灵活性太差。<br />2.没有可扩展的接口。<br />3.没有统一的数据结构而是依赖于java中的List，Map，这样会对已有的业务对象产生干扰。<br />4.没有办法做到对大数据量的缓存和Cache机制。<br />5.缺少文档，难以使用。<br />6.......<br /><br />目前smarttag提供了多种接口用于分页显示数据，并提供了可扩展的接口实现用户的多种需求，而且smarttag还在已有的分页显示的基础上提供了Filter/Preference功能。而且一切用户仅仅只需要实现一种接口大大的进化了用户的学习成本，smarttag并不会破环用户已有的数据接口，完全基于POJO以及Dynamic<img src ="http://blog.csdn.net/Killvin/aggbug/4138354.aspx" width = "1" height = "1" />Thu, 30 Apr 2009 08:52:00 +0800http://blog.csdn.net/Killvin/archive/2009/04/30/4138354.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2009/04/30/4138354.aspxhttp://blog.csdn.net/Killvin/archive/2009/04/30/4138354.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370019/1215170http://blog.csdn.net/Killvin/archive/2007/09/01/1768499.aspxhttp://blog.csdn.net/Killvin/comments/1768499.aspx0http://blog.csdn.net/Killvin/comments/commentRss/1768499.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1768499SUN公司推出了JavaFX，对于JavaFX我不了解，但比较Flex而言我更喜欢后者，原因就在于:Java不适合当今的web应用！web应用发展到了今天已经不在局限于用简单的页面跳转来实现任务，而是转为如何在更好的用户体验上（其实就是现在所说的web2.0）来完成已有的任务，我们不可否认如今的客户已经成熟了，他们需要的不光是简单使用的系统，更多的需求会在以后的若干年间涌现出来，比如更好的交互、更加友好的界面、以及更强的社会网络体验。其实，我们需要肯定的是在web这个领域上，技术已经回归到了当初的c/s层面上！其实在web层面java已经输了，无论你在Apache上看到多少特色的框架（EXT2、Wicket）也改变不了这个现实！如果我们把应用本身做一个比喻:一个等待开启的酒瓶，那java这些个框架就好比是一把榔头，而Ajax就好比是一把起子，虽然都可以打开酒瓶，但用java虽然省力气，可往往会把瓶口弄烂，喝道了美酒的同时有时多少会有一些玻璃渣滓扎伤了嘴；Ajax好一点可以毫不费力的打开酒瓶，但总觉得怪怪的（为了那点动态效果需要熟悉jascript xml dom等等），而且如果<img src ="http://blog.csdn.net/Killvin/aggbug/1768499.aspx" width = "1" height = "1" />Sun, 02 Sep 2007 01:21:00 +0800http://blog.csdn.net/Killvin/archive/2007/09/01/1768499.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2007/09/01/1768499.aspxhttp://blog.csdn.net/Killvin/archive/2007/09/01/1768499.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370020/1215170http://blog.csdn.net/Killvin/archive/2006/07/02/867345.aspxhttp://blog.csdn.net/Killvin/comments/867345.aspx0http://blog.csdn.net/Killvin/comments/commentRss/867345.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=867345在上一篇的文章中，比较仔细的分析了IE对于Cookie处理过程中出现的问题，既然存在问题就要想办法解决，而问题的关键在于IE没有能够"老实"的报告用户对于Cookie的设置问题 IE GET /mail HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon) Host: mail.google.com Connection: Keep-Alive Cookie: gmailchat=killvin.liu@gmai<img src ="http://blog.csdn.net/Killvin/aggbug/867345.aspx" width = "1" height = "1" />Mon, 03 Jul 2006 05:55:00 +0800http://blog.csdn.net/Killvin/archive/2006/07/02/867345.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/07/02/867345.aspxhttp://blog.csdn.net/Killvin/archive/2006/07/02/867345.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370021/1215170http://blog.csdn.net/Killvin/archive/2006/07/02/867342.aspxhttp://blog.csdn.net/Killvin/comments/867342.aspx0http://blog.csdn.net/Killvin/comments/commentRss/867342.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=867342IE在处理COOKIE方面的问题 1。即使你提高了浏览器的隐私登记，在第一次打开窗口的时候，你获取不到任何的Cookies对象（很显然的结果），然而当你再次刷新本页面的，Cookie此时会奇迹般的出现！而在Firefox浏览器中按照以上的步骤，是不会出现这样的情况的。 2。不仅如此，你还可以透过Action的处理，多次的往Cookie中增加Cookie的数量（当然在Action中你依然可以自由的获取到Cookie这个数组，并且不为空），然而让人匪夷所思的是在Cookie的存放目录下你是找寻不到任何的蛛丝马迹的。而在Firefox没有出现以上的情况。 －解决 1。在首次进入页面时查询客户端的Cookie，如果不存在则警告用户，并要求再次的登陆。 2。在用户登陆后，如果更改了浏览器的隐私级别，对于Firefox标准的浏览器，此时肯定不会再找到Cookie数组对象了，你需要做的仅仅只是将页面调转到登陆窗口；而在IE下就非常的麻烦了甚至无法解决，因为你依然可以访问到原来的Cookie数组值，（比如，用IE在CSDN登陆后提高隐私级别，你依然可以登陆到其他的服务区域）此时没<img src ="http://blog.csdn.net/Killvin/aggbug/867342.aspx" width = "1" height = "1" />Mon, 03 Jul 2006 05:54:00 +0800http://blog.csdn.net/Killvin/archive/2006/07/02/867342.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/07/02/867342.aspxhttp://blog.csdn.net/Killvin/archive/2006/07/02/867342.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370022/1215170http://blog.csdn.net/Killvin/archive/2006/05/21/747732.aspxhttp://blog.csdn.net/Killvin/comments/747732.aspx0http://blog.csdn.net/Killvin/comments/commentRss/747732.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=747732一。前言 你在任何一个比较专业的BBS都会看到这样的问题，即使你Google一下，也会发现有很多的人在关注和询问，但大家给出的解决方法却都是千差万别，（有的人主张采用脚本来解决;有的则想重定向到别的页面;有的则将此问题提升到Token的角度）为什么会有如此大的差异呢？ 二。问题场景 首先，我们应该先了解为什么要处理这样的问题？或者专业一点就是它适合的场景是什么？（似乎只有人来问没有人来解释） 1。重复提交、重复刷新的场景 重复提交、重复刷新都是来解决系统重复记录的问题。也就是说某个人在多次的提交某条记录（为什么？也许是闲了没有事情干的;最有可能是用户根本就不知道自己的提交结果是否已经执行了？！）。 但出现了这样的问题并不见得就必须处理，要看你所开发的系统的类别而定。比如你接手的是某个资源管理系统，系统本身从需求的角度根本就不允许出现"重复"的记录，在这样需求的约束条件下，去执行重复的提交动作只会引发“业务级异常”的产生，根本就不可能执行成功也就无所谓避免不避免的问题了。 2。防止后退的场景 了解了重复刷新、重复提交的场景，我们来了解一下"防止后退<img src ="http://blog.csdn.net/Killvin/aggbug/747732.aspx" width = "1" height = "1" />Sun, 21 May 2006 21:23:00 +0800http://blog.csdn.net/Killvin/archive/2006/05/21/747732.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/05/21/747732.aspxhttp://blog.csdn.net/Killvin/archive/2006/05/21/747732.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370023/1215170http://blog.csdn.net/Killvin/archive/2006/04/16/665361.aspxhttp://blog.csdn.net/Killvin/comments/665361.aspx0http://blog.csdn.net/Killvin/comments/commentRss/665361.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=665361有没有想过有一天我们的开发工作不是去分析什么对象的属性、什么是对象的方法，而是在已有的世界里组合我们需要的对象。。。。 采用OO中设计对象往往要从静态和动态的观点去抽象对象，从而产生对象的属性和方法，而且我们往往采用基本的数据类型来表示属性（暂且称之为平面属性）。可是在我们的现实世界里对象的表现形式却不是如此的，往往我们分析的平面属性又是由其他的对象构成的，这就产生了一个问题，纯粹的OO世界（我这里指的纯粹的OO世界意思就是面向构件的世界）是否存在呢？如果这样的世界存在的话，我们所抽象出来的对象都应该是由组合的形式构成的，而对象所表现出来的方法无非是这些组合的对象共同或者单独的行为。那麽，是不是说面向对象中的属性是错误的，或者说是根本不需要的？！ 产生这样的问题的人不是我（我没有这样的思考过），而是我得一个朋友（某个公司的技术经理）。也许是受一些面向构件思想的洗脑，他希望构建出一种纯粹的构件世界，这样任何系统需要的构件都可以依靠组合而产生行为。－是不是听上去非常的清新脱俗？是呀，这样的话我们的系统设计就可以采用构件的形式，象搭积木一样的将系统搭建起来。就如同搭建房屋一样，我<img src ="http://blog.csdn.net/Killvin/aggbug/665361.aspx" width = "1" height = "1" />Sun, 16 Apr 2006 20:53:00 +0800卧古龙（Killvin）http://blog.csdn.net/Killvin/archive/2006/04/16/665361.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/04/16/665361.aspx卧古龙（Killvin）http://blog.csdn.net/Killvin/archive/2006/04/16/665361.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370024/1215170http://blog.csdn.net/Killvin/archive/2006/04/16/665318.aspxhttp://blog.csdn.net/Killvin/comments/665318.aspx0http://blog.csdn.net/Killvin/comments/commentRss/665318.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=665318王咏刚的贵作>是一本很难得的好书，比如看到系统设计篇中的"糟糕的面向对象的设计"，作者采用实例的形式列举我们可能会犯得错误，最后给出的基于策略的解决方案，妙！ 可是在第十章:属性还是方法中，似乎作者欲言又止，很不过瘾的感觉。。。而偶也是这几天刚好也在思考属性和方法的问题，献丑了。 先要统一概念：这里说的属性不是面向对象中的属性的概念。在OO里属性（在这里成为成员变量）是对于对象的静态方面的抽象，而方法是对象动态特性的抽象。借用王的定义：属性是用于定义与某些功能操作关系紧密的数据元素。也就是说这里的属性指的是介于成员变量和方法（或者函数）之间的事物。因而本文将在概念上存在三个词汇：成员变量、属性、方法。 本文在于和大家讨论以下的两个问题（也许更多需要您的智慧加盟） 1。属性和成员变量的区别？ 个人理解： 属性如同上面所说的那样不属于面向对象的概念，而且在JAVA的眼里，在JAVA所推崇的JAVA BEAN规范里也希望我们能有更好的封装成员变量，而采用GET ./ SET的方法来访问和设置成员变量的值。而且在属性的实现上更多的是依靠成员变量 ＋ GET <img src ="http://blog.csdn.net/Killvin/aggbug/665318.aspx" width = "1" height = "1" />Sun, 16 Apr 2006 19:53:00 +0800卧古龙（Killvin）http://blog.csdn.net/Killvin/archive/2006/04/16/665318.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/04/16/665318.aspx卧古龙（Killvin）http://blog.csdn.net/Killvin/archive/2006/04/16/665318.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370025/1215170http://blog.csdn.net/Killvin/archive/2006/04/08/655678.aspxhttp://blog.csdn.net/Killvin/comments/655678.aspx0http://blog.csdn.net/Killvin/comments/commentRss/655678.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=655678摘自：http://shiningray.cnblogs.com/archive/2005/08/13/213802.html 编程范型 一个编程范型是一类典型的编程风格（可以对照方法学，是一个从事软件工程的一类典型的风格）。 一个编程范型提供了（同时决定了）一个程序员对程序执行的看法。例如，在面向对象编程中，程序员认为程序是一系列相互作用的对象，而在函数式编程中一个程序会被看作是一个无状态的函数计算的序列。 正如软件工程中不同的群体会提倡不同的方法学一样，不同的编程语言也会提倡不同的编程范型。一些语言是专门为某个特定的范型设计的（如Smalltalk和Java支持面向对象编程，而Haskell和Scheme则支持函数式编程），同时还有另一些语言支持多种范型（如Common Lisp、Python和Oz） 很多编程范型已经被熟知他们禁止使用哪些技术，同时允许使用哪些。 例如，纯粹的函数式编程不允许有副作用；结构化编程不允许使用goto。可能是因为这个原因，新的范型常常被那些惯于较早的风格的人认为是教条主义或过分严格。然而，这样避免某些技术反而更加证明了<img src ="http://blog.csdn.net/Killvin/aggbug/655678.aspx" width = "1" height = "1" />Sun, 09 Apr 2006 05:59:00 +0800Killvinhttp://blog.csdn.net/Killvin/archive/2006/04/08/655678.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/04/08/655678.aspxKillvinhttp://blog.csdn.net/Killvin/archive/2006/04/08/655678.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370026/1215170http://blog.csdn.net/Killvin/archive/2006/04/06/652428.aspxhttp://blog.csdn.net/Killvin/comments/652428.aspx0http://blog.csdn.net/Killvin/comments/commentRss/652428.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=652428http://www.cnblogs.com/zhenyulu/articles/208799.html 第2章 并发问题及控制手段 什么是并发问题？假设有这么一家书吧，顾客可以到那里喝茶读书。顾客拿着选好要读的图书到柜台登记，然后找个地方去阅读，临走时将图书归还店家。有一天，一个顾客相中了一本书后正要拿去登记，另一个顾客的手也抓住了这仅有的一本书，并发问题出现了。两个顾客要读同一本书，互不相让，这让店主伤透了脑筋。这个案例仅仅是众多并发问题中的一个微小部分，但从中我们可以看出并发问题主要出现在多个用户对有限资源进行访问的时候，如果解决不好会直接影响系统的有效、正常运行。数据库是一个共享的资源，并发问题的出现是必不可免的，如何识别并发类型并加以控制是这一章重点要讲述的内容。 本章将分成两大部分，一部分主要讲Visual FoxPro中并发控制机制。VFP中并发控制相对简单，数据加锁的形式比较单一，非常适合作为初步了解并发问题的切入点。第二部分以SQL Server 2000、ADO.NET以及C#为主要工具，深入了解并发一致性问题、封锁协议、事务隔离等内容，难度<img src ="http://blog.csdn.net/Killvin/aggbug/652428.aspx" width = "1" height = "1" />Thu, 06 Apr 2006 18:52:00 +0800Killvinhttp://blog.csdn.net/Killvin/archive/2006/04/06/652428.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/04/06/652428.aspxKillvinhttp://blog.csdn.net/Killvin/archive/2006/04/06/652428.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370027/1215170http://blog.csdn.net/Killvin/archive/2006/04/03/648832.aspxhttp://blog.csdn.net/Killvin/comments/648832.aspx1http://blog.csdn.net/Killvin/comments/commentRss/648832.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=648832怎么样，心情舒畅多了吧？<img src ="http://blog.csdn.net/Killvin/aggbug/648832.aspx" width = "1" height = "1" />Mon, 03 Apr 2006 20:06:00 +0800Killvinhttp://blog.csdn.net/Killvin/archive/2006/04/03/648832.aspx#Feedbackhttp://blog.csdn.net/Killvin/archive/2006/04/03/648832.aspxKillvinhttp://blog.csdn.net/Killvin/archive/2006/04/03/648832.aspxhttp://blog.csdn.net/Killvin/feed.aspxcsdn.net/Killvin/~1215197/212370028/1215170