ColdSpring AOP Tutorial

Introduction to ColdSpring AOP
ColdSpring AOP Tutorial – Part One
ColdSpring AOP Tutorial – Part Two, Around Advice

MachII and ColdSpring Architecture

Redirect Command and SES URLs

Hi Everybody,

Just wanted to post a proposed solution for SES URLs and the redirect command. As some of you may know, I don't know if SES URLs are all they are supposedly cracked up to be. However, we want to meet the needs of the community without comprising the framework. I cannot make any guarantees that this will ever make it into the framework -either in this release or a future release. One reason why this may not get into the framework is because this can easily be emulated by using a filter instead of the redirect command. However, there is an argument that redirect should do it "natively" without the use of a filter (because the redirect command is like a filter anyways). Here is the solution that I devised with input from Kurt Wiersma. Matt and I would like people's thoughts whether good or bad on this:

The solution is allow users to customize the redirect command by extending it with a custom command. You would extend the current redirect command CFC (MachII.framework.commands.RedirectCommand) with a custom command that you wrote. You would then override the makeRedirectURL() method in the base RedirectCommand with your makeRedirectURL() method and schema of creating SES URLs. Your custom extension would also require a configure() method (instead of a init() method) - which would be allow you to do configuration code just like in listeners, filters and plugins.

You would define an application wide custom extension of the redirect command by adding a property to your Mach-II properties. For example:
<property name="defaultRedirectType" value="path.to.your.custom.redirectCommand"/>

Your custom extension would then make all redirects commands in your config file obey your SES schema.

If you wanted a specific redirect command to obey a certain schema, you could that easily. This would override the application wide custom extension or default Mach-II behavior (standard url with a query string):
<redirect event="youNewEvent" args="some,args" type="path.to.your.custom.redirectCommand"/>

Adding the "type" attribute makes this enhancement inline with how listeners, filters and plugins are defined.

One reason why I favor this approach over adding SES to the current redirect command is that this will account for 99% of the SES URL schemas. Not everybody uses /param1/value1/param2/value2 approach. Also, some people do even more url rewritting and remove the file name from the url (something like example.com/param1/value1/param2/value2 instead of example.com/index.cfm/param1/value1/param2/value2). One thing is that Mach-II isn't going to parse the SES urls for your - you need to have your webserver do that for you or institute a plugin to do that on the preProcess. That is one reason why I am a bit hesitant in adding this in the first place - we're starting to get into areas where Mach-II shouldn't be involve itself in - IMHO.

Please, any comments are appreciated. Again, no promises if this will make it into this release or future releases of Mach-II, but discussion is required on this subject. Also, please see the redirect command enhancements that have already been made that I mentioned in the Mach-II 1.1.1 Status Update email I sent earlier today.

Peter J. Farrell - Maestro Publishing
blog.maestropublishing.com

Ioc容器的革命性优点

我们知道,在Java基本教程中有一个定律告诉我们:所有的对象都必须创建,或者说,使用对象之前必须创建,但是现在我们可以不必一定遵循这个定律了,我们可以从Ioc容器中直接获得一个对象然后直接使用,无需事先创建它们.

这种变革,就如同我们无需考虑对象销毁一样,因为Java的垃圾回收机制帮助我们实现了对象销毁,现在又无需考虑对象创建,对象的创建和销毁都无需考虑了,这给编程带来的影响是巨大的.
我们从一个简单例子开始,有一个普通类B代码如下:

public class B implements BI
{
　AInfterface a;
public B(AInfterface a)
{
　 this.a = a;
}
　public void invoke()
{
　　/** ...*/
　}
}

有两种使用B的方式:
1.普通无Ioc容器的调用方式:
BI b = new B(new A());//需要在生成B实例之前 生成A等实例
b. invoke();
2.使用Ioc容器(Jdon框架)的革命调用方式:
BI b = (BI) WebAppUtil.getService("b");
b. invoke();

上面两种方式重要区别:
前者需要照顾B类中A类的实例化,如果B类中调用不只A类一个,还有更多其他类如C/D/E等类,这样,你在使用B类时,还需要研究其他类的创建,如果C/D/E这些类不是你自己编写,你还需要翻阅它们的API说明,研究它们应该如何创建?是使用New还是工厂模式 还是单态调用?

这时,你会感叹:哇,有没有搞错?我只不过是为了使用B类中一个小小的方法,就花去我这么多时间和精力?

当我们使用第二种方式时,就无需花很多精力和时间考虑A/C/D/E等类的创建.
使用Ioc容器,你再也不必做这些僵化愚蠢的工作了,我们只需从ioc容器中抓取一个类然后直接使用它们.

当然,在使用之前,我们需要做一个简单的配置,把你将来需要使用的类全部告诉ioc容器,例如Jdon框架的ioc容器配置jdonframework.xml如下:

注意:虽然B类代码调用了A类(甚至可能调用C等其他类),但是在配置中我们无需考虑这种调用关系.
因此,整个环节我们都无需考虑B类中涉及其他类的调用关系,这样是非常省时省力的,特别是如果项目较大,JavaBeans特别多,又是多人协调开发,这种方式对提高开发效率,降低出错率是非常大的帮助.
如果你的项目中有非常多的类,调用关系很复杂,而且调用关系随时都可能变化,那么,使用无需照顾调用关系的Ioc容器无疑是减轻开发负担的首选.
ioc容器另外一个著名实现是Spring框架,但是在Spring的配置文件applicationContext.xml中,我们必须考虑上述调用关系:

所以,从以上对比来看,从项目开发效率角度看,基于PiocContainer实现的Jdon框架在实际使用配置效率无疑要高于Spring框架.
同时,也可以说:基于PiocContainer实现的Jdon框架完全真正实现了Ioc容器的革命性优点,颠覆了"使用对象之前必须创建" 的基本Java语言定律.

Reactor:coldfusion世界的ORM框架

闲云孤鹤介绍Reactor框架的文章,很不错.
PS:ColdFusion世界里还有几个Object Relational Mapping框架:
Transfer
ObjectBreeze
Active Record Factory
CFCPowerTools

ColdFusion正在成为市场新宠

via: www.zdnet.com.cn

这篇文章将帮助您探索ColdFusion的世界，这个世界中正在发生的事情，以及您为什么要关注这一开发平台。

我已经在编写ColdFusion的相关文章上工作一段时间了，因为真正令人兴奋的事情正在ColdFusion世界中进行，现在是时候来修正我们的观点了，在我看来，没有比现在更好的时机来加入到ColdFusion的开发者行列了。这篇文章将对现在的发展以及未来的潮流进行综述，我的后续文章将对这些主题（以及其它主题）进行深入探讨。

新的管理

软件界最大的一起并购在去年晚些时候结束：Macromedia公司与Adobe公司的合并创造了世界上第五大软件公司，因此，ColdFusion也就变成了Adobe公司的产品。

说实在的，去年有段时间ColdFusion看起来仿佛处于不稳定的过渡状态，但不要误会我，人们依然使用ColdFusion来快速创建应用软件，就像他们以往所做的一样，ColdFusion MX 7是一个辉煌的版本，它给予了开发人员很多新特色，但是每个人都保持静默（还不是十分静默），正在疑惑这次的合并对ColdFusion的开发者意味着什么，对ColdFusion的未来又意味着什么。

关于这场合并已经尘埃落定，Adobe将ColdFusion视做其软件产品线中的关键产品，他们将接受Macromedia已经完成的这项伟大的工作并希望能走的更远，使ColdFusion成为一个引人注目的应用服务器选项。 ColdFusion只会变的更加强大。ColdFusion MX 8已经在开发当中了，我估计它将提供与Adobe其它产品的紧密集成，比如PDF和LiveCycle，当然还会包括很多其它的改进。

为实践他们所说的，Adobe甚至使用ColdFusion来建造他们的新网站，这很好，新的Adobe.com将现有的Adobe网站和原来的Macromedia站点融合在一起了，而且这个网站是完全运行在ColdFusion之上的。

AJAX + CF

无论您认为AJAX是发明切片面包以来最伟大的事情，或只不过是对已经存在多年的技术加上了夸大其词的宣传用语而已，AJAX都不可能被忽视，AJAX已经存在于现在的技术世界中，而使用ColdFusion来编写AJAX是令人难以置信的简单。

ColdFusion 组件(ColdFusion Components (CFCs))可以被作为网络服务、Flash远程组件或直接通过URL来进行远程调用。在直接被远程调用的时候，此组件所返回的数据会自动转换为 WDDX XML格式，然后，通过一些简单的客户端JavaScript WDDS转换方法（免费的），使用CFC来响应AJAX请求就很简单了。

如果您需要一个更强壮的解决方案，来自Rob Gonda的AjaxCFC 就是一个强大且易于使用的工具。这是一个抽象的组件，开发者可以将其进行扩展来创建自己的AJAX组件或façades，这是一个具备全部特色的组件，它提供了错误处理、状态请求和同步与异步的能力，使用AjaxCFC来填充对话框、验证表单字段，创建“建议样式（suggest-style）”的下拉菜单或在页面上生成内容都是非常容易实现的。

最后，一个重大新闻就是Adobe刚刚发布了名为Spry的AJAX类库，如果在实际的CF 服务器上出现这些东西的踪迹，我并不会感到奇怪。

Flex 2

Adobe正在推广的Flex平台可以用于创建一种全新的Web应用软件。通过使用Flash创建用户界面，使用Flex编写的应用程序看上去更像真实的桌面软件。

虽然这可能听上去像AJAX现在正在做的事情，但是实际上却不是，Flex使用的是一种简单的XML语法来创建应用软件并将其联系到后台的数据服务上。它并不会受到不同浏览器显示效果或行为因素的影响，而这些正是困扰AJAX、DHTML和CSS的问题。它提供了一个统一的用户组件集合来实现对界面的定制，这一新型的应用软件平台是如此引人注目，甚至微软都试图在Vista的视窗基础表示层（Windows Presentation Foundation）中加入对这类软件的支持。而最好的消息是Flex的API和编译器都是可以免费使用的。

那么这些和 ColdFusion有什么关系呢？好，当基于Flex的应用软件可以通过网络服务与一系列后台数据相连，Adobe将ColdFusion定位于向 Flex应用程序提供数据的最快和最简单的方式。Adobe在Flex2.0的开发过程中的作风非常开放，开发了很多编译工具和示例程序。

名为FlexBuilder的集成开发环境包含了ColdFusion开发工具，可以让您在几分钟内逐步创建一个完整的Flex应用程序。如果您见到过 Ruby平台的运行，您就会知道使用FlexBuilder来创建Flex应用软件和相关的ColdFusion服务器端组件是多么迅速了。以我粗陋的见解，Flex 2.0所带来的冲击不仅在ColdFusion的开发上，而且对于整个网络开发都将造成巨大的影响。

用户界面控制器架构

随着ColdFusion的日益成熟，很多开发人员都将其作为构建应用软件的方式。模型－视图－控制（Model-View- Controller）模式是很多开发者采用的软件构建模式，有很多架构可以提供控制功能，最流行的三种是：Model-Glue、Mach-II和 Fusebox。

Model-Glue和Mach-II实际上很相似，它们是基于事件调用架构的，这两种架构通过URL或输入的表单来接受用户请求，对消息进行广播，从而传达到模型组件，然后渲染HTML视图。这两种架构都需要开发者具备面向对象的程序设计经验，因为该模型是使用CFC并按照面向对象方式创建的。

Model-Glue目前的版本是1.1.0，其2.0版本已经处于alpha阶段，Mach-II的版本也是1.1.0，它们两个现在都已经是稳定的架构了，假设您了解面向对象程序设计并且具备构建基于HTML应用软件的知识，那么您可以在这两个架构上很好地工作。

Fusebox是这三者当中最老的也是最流行的，它支持更广泛的编程风格，开发者可以使用过程化的方式或面向对象方式，这对于希望学习面向对象，但是希望逐步采用面向对象模式的开发者来讲是非常棒的选择。即将发布的Fusebox 5版和CFCs一样，完全从头编写的框架，融入了更多的灵活性并保持与Fusebox 4.1应用程序兼容。

缩写词汇：IOC与ORM

我刚刚提到的三个架构只是MVC模式中的控制器部分，CF社区并没有忘记MVC模式中最重要的部分：模型，模型是一个应用软件的心脏，所有的处理过程与商业逻辑都是通过模型进行的，我想大部分开发者都会同意模型是有意思的事情的发生地。

ColdSpring是一个用于ColdFusion应用软件的逆向控制(Inversion of Control (IOC))容器，它和Java的Spring架构的工作方式类似。最基本的想法是：您的模型组件越复杂越面向对象，则越难以管理它们之间的依赖关系。 ColdSpring提供了一种简便的方式来连接（wire together）您的CFCs。

ColdSpring可以完成注入CFC到其它的CFC或强制一个CFC与其它独立的CFC建立关联的工作，而不需要您手动完成这些任务。更好的是，如果您希望的话，它还可以将单独的组件实例缓存到内存中，这样今后调用它们的时候速度就会非常快（这也被命名为独立设计模式（Singleton design pattern））。作为一个免费附带的奖励，ColdSpring还支持一系列面向方面的程序设计（Aspect-Oriented Programming）的功能。

Reactor是一项正在展开的工作，它致力于为ColdFusion应用软件创建一套对象关系映射API（Object-Relational Mapping API）。这是一项极具挑战的事业，但它的有效性和能量已经在CF的世界中引起了巨大的波澜。Reactor从数据库中读取元数据，然后自动生成组件，该组件可以对数据库进行抽象，并提供验证逻辑。Reactor创建的组件遵循很多已经确立的设计模式，比如动态记录（Active Record）、数据访问对象（ Data Access Object）和表格数据网关（Table Data Gateway）。也许最强大的特色就是它可以与很多数据库协同工作，包括SQL Server、Oracle、MySQL、DB2和Postgre，这意味着一个应用软件可以以一种实质上透明的方式从SQL Server转换到Oracle。

一个正在成长的社区

也许ColdFusion复兴的最明显的一个原因就是开发者社区本身，ColdFusion非常易于使用，很多没有软件工程背景的人都可以很快学习并开始使用，目前正在快速显现的焦点是最佳方法与有效的面向对象开发。

正如您从这篇文章中推测的一样，CF的开发者正在拥抱面向对象的程序设计和面向模式的开发方法，活跃的大型邮件列表和论坛比如CFCDev和CF-Talk里充满了这类主题。很多开发者的博客流量很大，而且现在至少有三个播客在提供相关的内容。这正在创建一个反馈的循环，社区学到的更多，就能共享更多，而它共享的更多大家就能学到更多。

播客:

1. Helms and Peters



2. ColdFusion Weekly



3. ColdFusion Podcast

在2006年6月，举行了第七界CFUnited 会议，这次历时四天的会议一共包括75个研讨会，今年的与会者预计将超过1100人。在今年早些时候，CFObjective会议在明尼阿波利斯举行。相对 CFObjective而言，CFUnited会议的范围更广泛，而CFObjective则更关注企业级软件的设计和开发。

在众多开放源代码的项目中，CFEclipse项目构建了一个基于Eclipse平台的优秀的并且免费的ColdFusion集成开发环境，CFEclipse是真正为开发人员使用的，而且它一直在不断改进，几乎每天都会编译新的版本。

最后，现在甚至部署CFML代码都有了更多的选择，NewAtlanta公司最近发布了一款名为BlueDragon.NET的产品，Adobe的ColdFusion MX运行在J2EE平台，而BlueDragon.NET则允许将CFML代码部署在微软的.NET平台之上。MySpace.com是当前流量最大的三家网站之一，它就是运行在BlueDragon.NET之上的，这展示了BlueDragon.NET所提供的强大功能。

活蹦乱跳的ColdFusion

我希望这篇纲要可以证明ColdFusion的活跃，实际上，伟大的事情正在以比我以往所见过的所有事情更快的速度发展（我使用 ColdFusion已经超过十年了），Adobe是CF的坚定后盾，社区正在接受挑战，并不断推进最佳实践和企业开发。从架构到AJAX工具到Flex 用户界面的这些新的方法正在以每周一个的速度出现，今后的文章将会深入讲解这些主题，如果您最近还没有接触过ColdFusion，那么现在就是最好的时机，下载免费的开发者版本，您就会发现现在成为一个ColdFusion开发者的伟大时机。

ColdFusion Band

没想到还有个名为"ColdFusion"的乐队.
成立于2004年,来自美国亚利桑那, 乐队风格深受Nirvana,Rush影响,是我一直喜欢的风格.
乐队主页
ColdFusion@myspace
ColdFusion@purevolume