在为服务器端组件编程时，你很可能要从相对于web根的路径来取得某个文件的真实路径，但此文件实际上在站点的一个虚拟路径上。
什么是虚拟路径？
在一个web服务器上，虚拟路径将物理上分离的各文件组合在一起，放在同一个站点路径上，在应用服务器上，每个应用定位于其自己的虚拟路径上，实际上相互之间有着完美地分离。
getRealPath()方法
JSP servlet API提供了getRealPath(path)方法，返回给定虚拟路径的真实路径，如果转换错误，则返回null。
getRealPath语法定义：
public java.lang.String getRealPath(java.lang.String path)
返回一个字符串，包含一个给定虚拟路径的真实路径。例如，虚拟路径 "/index.html"
不管在服务器文件系统上具有怎样的真实路径，使用"/index.html"总可以找到它。返回的真实路径使用了相近于servlet容器(srvlet container)所在计算机或操作系统的格式，包含了适当的路径分隔符。如果servlet容器无法转换则这个方法将返回null。
参数：
path -一个描述了虚拟路径的字符串
返回值：
描述真实路径的字符串或者null
遗憾的是，getRealPath常常返回不同的东西，这取决于服务器或jsp文件调用此方法 ......
一、JSP EL语言定义
E L（Expression Language） 目的：为了使JSP写起来更加简单。
表达式语言的灵感来自于 ECMAScript 和 XPath 表达式语言，它提供了在 JSP 中简化表达式的方法。它是一种简单的语言，基于可用的命名空间（PageContext 属性）、嵌套属性和对集合、操作符（算术型、关系型和逻辑型）的访问符、映射到 Java 类中静态方法的可扩展函数以及一组隐式对象。
EL 提供了在 JSP 脚本编制元素范围外使用运行时表达式的功能。脚本编制元素是指页面中能够用于在 JSP 文件中嵌入 Java 代码的元素。它们通常用于对象操作以及执行那些影响所生成内容的计算。JSP 2.0 将 EL 表达式添加为一种脚本编制元素。
二、JSP EL简介
1、语法结构
${expression}
2、[ ]与.运算符
EL 提供“.“和“[ ]“两种运算符来存取数据。
当要存取的属性名称中包含一些特殊字符，如.或?等并非字母或数字的符号，就一定要使用“[ ]“。例如� ......
Douyu是一种完全采取Java语言开发的、运作于JVM以上的新式基础开发平台。
在web层，Douyu完全遗弃了JSP/Servlet，
在数据库访问层，Douyu不依赖于任何ORM(对像关系照射)构架(如Hibernate)。
Douyu将Java语言编译器、Http服务器、MVC圆满调整在一起，
差点儿兑现了ORM全自动化，同时在Java语言层面引出了权限治理模型。
Douyu内置的Java语言编译器基于OpenJDK Javac编译器(b60版)，
并进行了批改和扩张，和Http服务器组合以后能在控制器层发挥出强大的威力，
你只要批改Java源文件，其后刷新浏览器就能查看运作结果，
与此同时编译器也是兑现ORM自动化的基石。
Douyu内置的Http服务器是基于NIO技术的，
是对Tomcat六及com.sun.net.httpserver(一共1300多个Java源文件)进展阔斧大刀的改建后得来的，
改建后的Http服务器当前唯有60个上下的源文件，支持Http1.0/1.1协议。
Douyu内置的权限治理模型现阶段包孕了效能权限、字段权限两类，
效能权限正常对应控制器类中的Action步骤，Action步骤可以与表单中的旋钮联系关系，
字段权限能统制表单中的字段是不是可以查看、批改或掩藏。
Douyu内置的ORM已差一点兑现自动化，你只须建个数据库表(如p ......
日前要做新项目，想理解一下子新的技术见见有没有可以改善的地方。于是乎学习了一下子Struts二（预先一直用Struts一），接触到了FreeMarker，做了一些实验以后，对其效能很是不解。
从我自个儿测试以及看网上大伙的述评可以得出FreeMarker具备以次优点：
一、逻辑分开美，View层不出现逻辑代码，可维护性美
二、美工和技术的工作分开
三、速度快，省掉了Jsp编译进程
四、可以在IDE中运作，换言之是可以开展单元测试
五、可以制造Macro
看完大量FreeMarker的文件以及大家伙儿对它的评说以后，仍旧没法打消我内心的不解，针对之上五点我可以讲：
一、逻辑分开，无非是FreeMarker模版没法直接运作Java代码，挟制要求全部数据务须预加工才华将结果传到View层做终极呈现。我个人对这种过于纯正的货色报以怀疑，实际工作中很多时分这种单纯的逻辑分开很难兑现。应一个长期维护的项目，不停增多展示逻辑以后，为了护持View层的这种挟制的清洁，而在Action层增多大量处置逻辑，我不觉得维护性会好（或者我了解错了，终究没长期使用过）。就像前些年风靡XML配置文件，分开了逻辑，嗣后发现太劳驾，又发生了Annotation扑灭XML配置文件，无论是分开仍是集合，逻辑是没法扫� ......
开始之初的架构设计决定着软件产品的生死存亡。“好的开始相当于成功一半”！
开始的架构设计也是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持。再结合自己项目的特点（需要透彻的系统分析），才能逐步形成自己项目的架构蓝图。
比如要开发网站引擎系统，就从Yahoo的个人主页生成工具 到虚拟主机商提供的网站自动生成系统，以及IBM Webphere Portal的特点和局限 从而从架构设计角度定立自己产品的位置。
好的设计肯定需要经过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法
由于在开始选择了正确的方向，后来项目的实现过程也验证了这种选择，但在一些架构设计的细部方面，还需要对方案进行修改，属于那种螺旋上升的方式，显然这是通过测试第一的思想和XP工程方法来实现的。
如果我们开始的架构设计在技术平台定位具有一定的世界先进水平，那么，项目开发实际有一半相当于做实验，是研发，存在相当的技术风险。
因此，一开始我们不可能将每个需求都实现，而是采取一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍（加入人工干预），以检验各个技术环 ......
抽象化和继承关系使概念和定义可以复用；多态性使实现和应用可以复用；
开闭原则（Open-Closed Principle OCP）一个软件实体应当对扩展开放，对修改封闭。
对可变性的封装原则（Principle of Encapsulation of Variation） (1)一种变化性不和另一种混合在一起 （2）一种可变性不应散落在代码的很多地方。
里氏代换原则（Liskov Substitution Principle）：任何基类出现的地方，子类一定可以出现。
依赖倒转原则（Dependence Inversion）：要依赖于抽象，不要依赖于实现。
组合/聚合复用原则（ Composite/Aggregate Reuse Principle）：尽可能使用组合/聚合，而不是继承关系。
迪米特法则：一个软件实体应尽可能少地和其他软件实体发生关系。
接口隔离原则（Interface Segregation Principle）：向客户端提供尽可能小的独立的接口，而不是大的总接口。
Coad原则，什么时候使用继承复用？
（1）子类是超类的一个特殊种类，不是超类的一个角色，区分Is-a，Has-a
（2）子类扩展超类职责，而不是换掉。
（3）永远不会出现需要将子类换成另一个类的子类的情况。
（4）只用分类学上有意义时，才使用继承，不要从工具类继承。
几个工厂模式解决对象创建过程中的依 ......
最新文章 :