
function fun() { return 1; } var a = fun; var b = fun(); JavaScript中我们把下面的代码叫做函数: function fun() { return 1; } 函数是一种叫做function引用类型的实例,因此函数是一个对象。对象是保存在内存中的,函数名则是指向这个对象的指针。 var a = fun 表示把函数名fun这个指针拷贝一份给变量a,但是这不是指函数本身被复制了一份。 即:a是fun函数,b是1 如果函数名后面加上圆括号就表示立即调用(执行)这个函数里面的代码(花括号部分的代码)。 不加括号的,都是把函数名称作为函数的指针,一个函数的名称就是这个函数的指针,此时不是得到函数的结果,因为不会运行函数体代码。它只是传递了函数体所在的地址位置,在需要的时候好找到函数体去执行。 例如: window.onload=init; init函数并不会在这行代码时就执行,浏览器加载文档时这句话会被加载,会被告知文档加载完要执行哪个函数,但实际上没有当时就执行,等到整个文档加载完成之后才会通过init这个指针去执行init()。 小注:本文部分内容参考: https://www.zhihu.com/question/31044040 http://blog.csdn.net/yyx19941129/article/details/49642515 作者:jiankunking 出处:http://blog.csdn.net/jiankunking
与当前系统的用户用户组集成,可以使用视图。 用sql组织现有系统的用户组织等信息,只需要保证与之前activiti物理表名称结构一致即可。 通过视图过渡实现与现有系统中用户组织等的集成(这样就不需要同步用户数据了)。 图片摘自《Activiti实战》 Activiti实战下载地址:这里写链接内容 作者:jiankunking 出处:http://blog.csdn.net/jiankunking
什么是 Spring 视图和视图解析器? Spring MVC(Model View Controller)是 Spring 中一个重要的组成部分,而 Spring 视图和视图解析器则是 Spring MVC 中的组成部分。在介绍 Spring 视图和视图解析器前,我们先了解下在 Spring MVC 框架中,一个 Web 请求所需经历的六个阶段: 请求会首先被 Spring MVC 的前端请求分发器(Dispatcher)拦截。该拦截器是一个 Servlet, 需要在 web.xml 中配置,所有符合所配置的 URL 样式的访问请求,将都会被该拦截器拦截。Spring 提供了默认的分发器 org.springframework.web.servlet.DispatcherServlet,您可以根据需要,决定是否需要定制自己的分发器。 在接收到访问请求后,分发器会根据开发人员在 Spring 配置文件或代码中的注解(Annotation),来查找合适的控制器。 分发器在查找到合适的控制器后,将请求转交给该控制器处理。 通常,控制器会调用相应服务类来处理业务逻辑,在将请求处理后,控制器需返回处理后的结果数据模型(Model)以及下一个需要显示的视图名。 在控制器处理结束并返回模型和视图名之后,Spring 会依次调用 Spring 容器中所注册的视图解析器,来查找符合条件的视图。 在获得 Spring 视图后,Spring 会根据该视图的配置信息,显示该视图。 图 1.Spring MVC 处理流程 通过以上 Spring MVC 的介绍,我们可以发现,视图和视图解析器将出现在整个请求处理流程中的最后部分。那么到底什么是视图和视图解析器?简而言之,视图是指 Spring MVC 中的 V(View),而视图解析器的功能则是依据指定的规则来查找相应的视图。 常用视图和视图解析器简介 在开发中,视图通常就是 JSP、Velocity 等。Spring 默认提供了多种视图解析器,比如,我们可以使用最常用解析器 InternalResourceViewResolver 来查找 JSP 视图(与之相对应的视图类为 InternalResourceView)。通常,一个视图解析器只能查找一个或多个特定类型的视图,在遇到 Spring 不支持的视图或者我们要自定义视图查找规则的情况下,我们就可以通过扩展 Spring 来自定义自己所需的视图解析器。目前,视图解析器都需要实现接口 org.springframework.web.servlet.ViewResolver, 它包含方法 resolveViewName,该方法会通过视图名查找并返回 Spring 视图对象。表 1 列出了常用的 Spring 视图解析器。 表 1.Spring 常用视图解析器列表 视图解析器 描述 XmlViewResolver 接口 ViewResolver 的实现,从 XML 配置文件中查找视图实现(默认 XML 配置文件为 /WEB-INF/views.xml) ResourceBundleViewResolver 接口 ViewResolver 的实现,用于从 properties 文件中查找视图。 UrlBasedViewResolver 接口 ViewResolver 的实现,用于根据请求的 URL 路径返回相应的视图,该视图需为抽象类 AbstractUrlBasedView 的实现,它还有些子类,如 InternalResourceView 和 JstlView 等 . InternalResourceViewResolver UrlBasedViewResolver 的子类,通常用于查找 JSP(类 InternalResourceView)和 JSTL(类 JstlView,InternalResourceView 的子类)等视图。 VelocityViewResolver /FreeMarkerViewResolver UrlBasedViewResolver 的子类分别用于支持 Velocity(类 VelocityView)和 FreeMark 视图(类 FreeMarkerView)。 ContentNegotiatingViewResolver 接口 ViewResolver 的实现,用于根据请求文件的后缀名或请求的 header 中的 accept 字段查找视图。 在多数项目中,InternalResourceViewResolver 是最常用的,该解析器可以返回指定目录下指定后缀的文件,它支持 JSP 及 JSTL 等视图技术,但是用该视图解析器时,需要注意设置好正确的优先级,因为该视图解析器即使没有找到正确的文件,也会返回一个视图,而不是返回 null,这样优先级比该视图解析器低的解析器,将不会被执行。 在 Web 开发中,我们的前端显示可以是 JSP、Excel、Velocity 等,在 Spring 中,不同的前端显示技术都有其对应的 Java 视图类,正如表 1 所提到的,InternalResourceView 可以代表 JSP 视图,FreeMarkerView 代表 FreeMarker 视图。目前,Spring 支持多种技术开发的视图,包括 JSP、JSTL、Excel,Velocity 等,在多数项目中,用户并不需要自定义自己的视图。 本文整理自:开发 Spring 自定义视图和视图解析器 整理人:jiankunking 出处:http://blog.csdn.net/jiankunking
疑问: 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种“迁移的变化”? 如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口? 定义: 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 ——《设计模式》GoF 一、对象适配器 对象适配器采用对象组合,通过引用一个类与另一个类接口 在对象适配器中通过组合获得Adaptee对象 通过调用Adaptee对象的方法,转换后返回Target结果。 二、类适配器 类适配器通过多继承对一个接口与另一个接口进行匹配。 Target定义了Client使用的与特定领域相关的接口,Client通过调用Target实现某一个特定的操作。Adaptee是一个已经存在的类,需要与Target协同工作,这个接口需要适配。Adapter适配器适配Adaptee和Target接口。在类适配器中,通过继承获得Adaptee中的方法。 .NET不支持多重继承,因此当Target是一个类,而不是一个接口时无法实现类适配器,这时需要使用对象适配器。 三、生活中的例子 在国内使用的电源供电电压为220V,美国为380V,当你出差到美国,你的电器需要220V的电压,但旅馆里不提供220V,只提供380,所以,你到市场买了一个电源适配器,在接上适配器后,旅馆里的电源就可以使用在你的电器上了。 Target:标准电源 Adaptee:美国电源 Adapter:适配器 1、实现-Target /// <summary> /// 目标:Target /// </summary> public class StandardPower { /// <summary> /// 供电 /// </summary> /// <returns></returns> public virtual int SupplyPower() { Console.Write("正常SupplyPower,电压:"); return 220; } } 2、实现-Adaptee /// <summary> /// 要适配的对象:Adaptee /// </summary> public class AmericanPower { public int SupplyPower() { Console.Write("在美国供给380V电压"); return 380; } } 3、实现-Adapter /// <summary> /// 适配器:Adapter /// </summary> public class PowerAdapter : StandardPower { /// <summary> /// 当地电源 /// </summary> private AmericanPower localPower = new AmericanPower(); public override int SupplyPower() { int v = localPower.SupplyPower(); if (v != 220) { //这里做一些转换工作 v = 220; } Console.WriteLine("转换后的电压:{0}", v.ToString()); return v;//转换后,即适配后 } } 4、实现-使用 StandardPower power = null; //在中国的时候 power = new StandardPower(); Console.WriteLine(power.SupplyPower()); //到美国以后,买一个适配器 power = new PowerAdapter(); Console.WriteLine("适配后提SupplyPower源电压为:{0}", power.SupplyPower()); //让控制台 等待 Console.ReadLine(); 四、.NET中的Adapter模式 1.适配器模式在.NET Framework中的一个最大的应用就是COM Interop。 COM Interop就好像是COM和.NET之间的一座桥梁(关于COM互操作更多内容可以参考我的互操作系列)。COM组件对象与.NET类对象是完全不同的,但为了使.NET程序 象使用.NET对象一样使用COM组件,微软在处理方式上采用了Adapter模式,对COM对象进行包装,这个包装类就是RCW(Runtime Callable Wrapper)。RCW实际上是runtime生成的一个.NET类,它包装了COM组件的方法,并内部实现对COM组件的调用。如下图所示: 2..NET中的另外一个适配器模式的应用就是DataAdapter。 ADO.NET为统一的数据访问提供了多个接口和基类,其中最重要的接口之一是IdataAdapter。DataAdpter起到了数据库到DataSet桥接器的作用,使应用程序的数据操作统一到DataSet上,而与具体的数据库类型无关。甚至可以针对特殊的数据源编制自己的DataAdpter,从而使我们的应用程序与这些特殊的数据源相兼容。 五、实现要点 适配器模式重在转换接口,它能够使原本不能在一起工作的两个类一起工作,所以经常用在类库复用,代码迁移等方面,有一种亡羊补牢的味道 类适配器和对象适配器可以根据具体实际情况来选用,但一般情况建议使用对象适配器模式 六、效果 通过类的继承或者对象的组合转换已有的接口为目标接口 七、适用性 需要使用一个已经存在的类,但接口与设计要求不符。 希望创建一个可以复用的类,该类可以与其他不相关的类或者是将来不可预见的类协同工作。 八、总结 Adapter模式主要应用于“希望复用一些现存的类,但是接口又与复用环境要求不一致的情况” ,在遗留代码复用、类库迁移等方面非常有用。 GoF 23 定义了两种Adapter模式的实现结构:对象适配器和类适配器。但类适配器采用“多继承”的实现方式,带来了不良的高耦合,所以一般不推荐使用。对象适配器采用“对象组合”的方式,更符合松耦合精神。 Adapter模式可以实现的非常灵活,不必拘泥于Gof23中定义的两种结构。例如,完全可以将Adapter模式中的“现存对象”作为新的接口方法参数,来达到适配的目的。 Adapter模式本身要求我们尽可能地使用“面向接口的编程”风格,这样才能在后期很方便地适配。 作者:jiankunking 出处:http://blog.csdn.net/jiankunking 源码下载:http://download.csdn.net/detail/xunzaosiyecao/9543274 小注: 本文部分资料整理自网络,在此表示感谢。 1、 C#设计模式(7)——适配器模式(Adapter Pattern) 2、本杰.NET 张波的PPT资料
最近搞坏了一次TFS,在修复的过程中发现TFS的安装复杂程度(与其他源码管理工具对比))令人发指啊。 此处以在windows server 2008上的安装Team Foundation Server 2010为例: 一、搭建IIS 此处安装默认的勾选项即可: 二、新建Windows 账户 a) TFSADMIN – 用于安装SQL Server,TFS等,该账户要求管理员权限,也就是将其加入到Administrators组中。 b) TFSSERVICE – 这个账户用于所有服务账户,不要加入到Administrators组中。 三、安装Sql Server 1、设置角色选择:SQL Server功能安装 2、必须安装报表服务 3、实例配置:默认实例 4、将空白账户选择到我们之前创建的账户,正确输入密码(Windwos 用户账户密码),将SQL Server Browser选择到自动启动: 5、这里身份验证可以选择只使用Windows验证,也可以选择混合模式,但建议选择只使用Windows验证,安全性高,另外将Admin组和之前创建的账户加入到管理员中: 6、Analysis账户设置同样: 接下来配置Reporting Service,这里可以选择默认配置或不配置,如果选择不配置那么等一下需要手动配置报表服务: 等待Sql Server安装完成。 四、安装TFS 1、如果单服务器的话建议选择所有角色: 2、安装完成后进入配置界面,这里我们选择高级: 3、配置数据库: 4、配置账户: 5、配置应用层(使用默认设置即可): 6、配置报告 Reporting Services(使用默认设置即可): Analysis Services (使用默认设置即可): 报表读者账户: 7、配置SharePoint服务: 8、项目集合(使用默认设置即可): 9、检测通过后开始安装 安装完成搞定! 本文参考:http://www.cnblogs.com/WilsonWu/archive/2011/11/24/2261674.html 至于为什么已经有一篇了,还要重写一篇?难道你没发现网上的资料不是木有图片就是图片超级小,根本看不清楚吗? 作者:jiankunking 出处:http://blog.csdn.net/jiankunking