手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2024年11月的文章

Adobe to contribute AMF support to Zend Framework

Submitted by gouki on 2008, August 16, 12:16 PM

Copy from framework.zend.com , it's submitted of Thursday, July 31, 2008
It's full contents :

XML/HTML
  1. Andi Gutmans, the CTO of Zend, blogged yesterday about a new proposal making it’s way through the Zend Framework process.
  2. Adobe has made a proposal for an AMF (Action Message Format) component in Zend Framework. This ZF component will allow for client-side applications built with Flex and Adobe AIR to communicate easily and efficiently with PHP on the server-side. Leading the design of the component for Adobe is Wade Arnold. Wade already has a track record of bringing the Adobe RIA technologies to PHP as a result of all of his work on AMFPHP.
  3. I know everybody over on the Zend Framework team is real excited about this proposal. If you work with Zend Framework then you are going to want to keep an eye on it.

and someone were comments for this news,

 

XML/HTML代码
  1. This is really great news! I am currently using JSON as the interface format between my Zend Framework and Flex app. This week I've been considering switching to amfphp (Lee Brimelow prepared a screencast http://www.gotoandlearn.com/player.php?id=78), but I didn't want to refactor/change all of my code. Zend_Amf is great news. I can't wait to begin using it. Cheers Adobe!

 

这样看来，以后ADOBE或许也会主动参与了吧？

Tags: amf, zf, adobe

PHP Framework | 评论:0 | 阅读:21045

PHP+MYSQL的OA为何没有Java的值钱

Submitted by gouki on 2008, August 15, 11:54 PM

本文来自于天极网。意见不敢苟同，COPY过来也是想听听大家的意见。
原文如下：

为什么PHP+MYSQL的OA不如JAVA写的值钱？？？
  1. 现在市场上的oa基本上可归结为两大阵营，即php阵营和java阵营。但对接触oa不久的用户来说，看到的往往只是它们的表相，只是明显的价格差异，却很难看出它们之间的实际差异。其实， PHP + MYSQL 不值钱不仅仅局限于oa软件，而是整体上PHP + MYSQL开发的软件都不如java开发的软件值钱。为什么PHP + MYSQL 的OA为什么不值钱呢？首先得明白php和java之间的差异才行。  
  2.   
  3. 　　1、系统的技术架构比较  
  4.   
  5. 　　分层是将系统进行有效组织的方式，分而治之的思想是计算机领域中非常重要的思想。在好的分层思想引导下，便能实现“高内聚、低耦合”，也能将具体的问题割裂开来，易于控制、易于延展，更易于分配资源。PHP只能实现简单的分布式两层或三层的架构，而JAVA在这方面就十分强大，可以实现多层的网络架构。运用MVC的设计模式，可使oa系统具有更加高效、合理的系统架构。技术架构的落后，使运用php编写的oa软件系统先天不足，而后天又无法补足其先天上的劣势。使得系统在可拓展性、需求应变性上与JAVA编写的oa软件系统的差距越来越大。架构的差距，注定了php做的oa充其量是个小家碧玉，始终无法和java这种大家闺秀同台竞技。  
  6.   
  7. 　　2、数据库访问比较  
  8.   
  9. 　　PHP可编译成具有与许多数据库相连接的函数。将自己编写外围的函数去间接存取数据库。通过这样的途径当更换使用的数据库时，可以轻松地修改编码以适应这样的变化。但PHP提供的数据库接口支持彼此不统一，比如对Oracle, MySQL，Sybase的接口，彼此都不一样。由于PHP对于不同的数据库采用不同的数据库访问接口，所以数据库访问代码的通用性不强。  
  10.   
  11. 　　而Java通过JDBC来访问数据库，通过不同的数据库厂商提供的数据库驱动方便地访问数据库，访问数据库的接口比较统一。如果同样是将开发的web应用从MYSQL数据数转到ORACLE数据，PHP需要做大量的修改工作，而且比较繁琐。但JAVA开发的便只需要很少的更改便能实现。  
  12.   
  13. 　　数据库访问方式的差异，奠定了php开发出的oa和java开发出来的oa是马车和火车的差距，前者只能亦步亦趋而且额度有限，后者却是工业化的结晶，不仅能够包容万物而且速度上稳步提升。  
  14.   
  15. 　　3、安全性对比  
  16.   
  17. 　　在同是开源和跨平台的java面前，php丢掉了很多的优势。在代码的安全性上尤为突出。php的开发程序在别人拿到代码后，可以很容易的进行修改。而 java开发的程序由于无法看到完整的源代码，只能看到一些编译好的类文件，所以安全性较高。加之系统架构的优势，在安全性上php和java是相去甚远。  
  18.   
  19. 　　如果非要将php和java在安全性上做个比较的话，同一个小偷光顾php那是随便拿来随便改，想拿什么拿什么，拿的高兴还能大笔一辉某某到此一游。而光顾java的时候，便会发现警察把守，内设自动报警装置，即便突破重重阻扰后进入居室。那值钱的东西都放在加密后的保险柜中，只能望洋兴叹、铩羽而归。  
  20.   
  21. 　　4、前瞻性和拓展性  
  22.   
  23. 　　从整体来说，php适用于中小型系统，而java适用于大型系统。Php能够将单一的事件做好，但却不适合完成集成度较高的多项并发事件。为什么说php适合中小型系统而不适合做大系统呢？  
  24.   
  25. 　　首先， php缺乏多层结构支持。而对于大型的系统负荷站点，只能采用分布计算。将数据库、应用逻辑层和表示逻辑层彼此分开，并将同层的根据流量分开，组成二维数组。而php恰恰缺乏这种支持。  
  26.   
  27. 　　其次，PHP提供的数据库接口不统一，要将多个不同的数据库数据统一需要花费很大的力气。而JAVA则没有这种缺陷，可通过SUN Java的Java Class和EJB获得规模支持，通过EJB/CORBA以及众多厂商的Application Server获得结构支持。如IBM的E－business，它的核心是采用JSP/Servlet的Web Sphere，是通过CGI来提供支持的。  
  28.   
  29. 　　如果将Php比作将才，具备独挡一方的能力。那么java便是帅才，具有较好的前瞻性和拓展性，整体布局和协同能力强。能够指挥千军万马，最后逐鹿中原。  
  30.   
  31. 　　5、开发成本比较  
  32.   
  33. 　　既然php在诸多方面都不如java优异，那么php开发出的oa产品何以与java产品竞争呢？在于Php阵营普遍走的是低端路线，而java阵营走的是中高端路线。两者之间交叉的区域较小。  
  34.   
  35. 　　软件价格的高低很大程度上和自身成本和功能相挂钩。php的入门门槛较低，绝大多数学过c的程序员都很容易转型为php程序员，这使得php程序员的泛滥成灾的同时，低成本的php软件产品也层出不穷。以PHP最经典的组合PHP + MySQL + Apache为例，由于所有软件都是开源免费的，所以投入并不高。  
  36.   
  37. 　　而java开发需要特定的环境，成长为一个合格的java程序员需要一定的时间，java程序员的成本也是php成本的几倍。Java的web应用服务器免费的有Tomcat、JBoss等，而要想具有很好的商业化服务便必须选用Web Sphere和 Web logic。这其中投入的成本无形中便超是php成本的N倍。所以，java开发oa的成本要远远高于php开发出来的同类软件产品。但也正由于java 开发的成本较高，很难实现抄袭和短期内逾越的可能，也使得java用开发出的产品门槛更高。  
  38.   
  39. 　　不怕不识货，就怕货比货。Php开发出来的产品也能用，但是和java开出的同类产品是没法比较的。正因为php开发的产品整体性能和java开发的相去甚远，所以php运用低成本的低价优势和同类的java产品抗争，以价格落差来平衡购买者的心态。所以，PHP + MYSQL 的OA不值钱也就不足为怪了。  

在作者眼里，PHP好象就只能处于低层次的开发。其实开发这东西也是双面性的，你让一个新手写JAVA和让我一个老手写PHP，写出来的东西你认为哪个值钱？
之所以JAVA比PHP值钱，归根结底还是观念，大多数人认为JAVA是科班出身，而PHP则是扎根草堆，虽然最近两年也开始逐步有培训班的出现，但和JAVA比起来就差远了。
就象大腕里说的：你要用PHP写的OA，你都不好意思提出口，怎么着也得是JAVA，.NET之类的吧。

Tags: oa, 价值, java

Misc | 评论:0 | 阅读:20689

REST与SOAP之比较——SOAP篇

Submitted by gouki on 2008, August 15, 11:41 PM

比较REST和SOAP的“风格”

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL
为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容：

用于访问服务的地址信息
用于传送信息的传输协议(例如，通道数)
用于所有可使用功能的名称和接口使用方法
在所有的请求和响应中所使用的数据类型
2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP

如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：

消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论

在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

——END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71772.html
仅作参考

Tags: rest, soap, compare, 比较

PHP | 评论:0 | 阅读:26810

REST与SOAP的比较——REST篇

Submitted by gouki on 2008, August 15, 11:40 PM

　我有这样一个推断，在计算机世界中，但凡那些让开发人员记住的重要概念，都有一个很酷的名称首字母缩写，否则的话，开发人员很快就会将其抛之脑后。比如Ajax、SOAP以及REST就证明了这一点。

REST能够在计算机领域被广泛采用，它走的道路是不同寻常的。这个术语是由Roy Fielding创造的。Fielding毕业于Irvine市加利福尼亚大学，在他的博士学位论文中第一次提出了REST这个概念。在Web方面，我们必须承认Fielding是非常精通的，他曾经帮助创建HTTP 1.0规范，该规范从1996年开始就为Web提供基本准则。他在Web标准方面非常有经验，这为他的这篇博士论文奠定了坚实的基础。

Fielding指出，使用且符合代表性状态传输(REST)设计约束的 Web 上部署的组件，可以充分利用 Web 的有用特性，万维网(World Wide Web)才能够达到最佳的工作效果。可以这样理解REST——当一个浏览器得到并且显示构成HTML页面的各个元素时，它正在获取资源的当前状态的表现形式。在Fielding的博士论文中，他列举了REST风格的设计约束，并且解释了为什么这些约束能够充分利用Web 的有用特性，使其达到最佳状态，以及这些约束的关键所在。同时，在论文中，他也包含了一些关于REST和某些目前的Web风格之间 “不符合”的讨论，以及这些Web风格是如何导致设计无法利用Web特性的。

Fielding认为，对于使用HTTP承载应用程序协议穿越防火墙，XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。”它们所采用的方式违背了设立防火墙的概念，结果是，防火墙厂商为了保护系统需要侦察出所承载的协议。由于大多数SOAP应用程序使用HTTP都是为了穿越防火墙，因此，你可以发现REST与SOAP之间的冲突是从哪里开始的。Fielding认为，如果你打算使用HTTP的话，就应该与充分利用HTTP本身的含义。

REST风格强调，通过有限的操作或者是“动词”以及一个组件之间的标准接口，也就是HTTP协议提供的借口，来提升客户与服务之间的交互。通过为每一个资源分配其自己的URL，来实现灵活性，REST可以调用包含上百个URI的资源类型的客户，其中的关键是REST能够给你无限多的“名词”。REST使用HTTP的动词——简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应，从而避免了歧义。举个例子，GET只能够简单地返回资源的表现形式，而不能够创建任何其他的内容。

在Web发展的初期，由于人们都在试验通过收集各种不同来源的元素，从而把Web应用程序融合在一起，有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息，用于页面创建者没有计划到的用途。这种“屏幕抓取”的Web类比表明，REST风格的方法是先于那些更加复杂的Web服务而出现的。

REST是一种风格而不是一个标准

你可能会把软件的架构风格当作对上层设计模式的抽象。然而，根据Fielding所说，设计模式的堆砌并不等同于架构风格，因为模式是非常接近于特定问题的。

由于REST是超文本系统的一种风格，而不是Web服务的，因此，本文的标题“REST与SOAP之比较”就有些让人误解。然而，很多软件设计人员会将其混淆，他们在考虑如何创建Web服务时，会得出这样的结论：SOAP过于复杂，而简单的类似于REST的设计却更加适合。

REST与RPC风格之比较

远程过程调用的架构，是应用在基于XML-RPC或者 RPC风格的SOAP的Web服务中的，它却有着完全不同的风格。客户端发出命令，以使服务做出特定的操作。换句话说，RPC有动词的倾向。

REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构，动词数量是没有限制的。REST说，我们使用四个动词——非常熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。

一个简单的REST举例

假设我们希望一个Web服务暴露一部分目录，从这个目录中，用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述，用户需要格式化一个GET请求，类似于下面的这个URL：

http://company.com/catalog/description/n1996-01

在处理这个请求时，“/catalog”将映射到一个服务中，之后，通过该服务对“description/n1996-01”进行解释，从而定位资源。在创建响应时，服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下，假定返回格式是HTML或者XML，客户端能够使用它来控制页面的布局。如果要得到图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。

REST的商业应用

最近几年，大多数Web商业企业开始对REST非常感兴趣。Google Data API(目前还在测试版本)专门使用REST规则来提供简单的协议。对服务的HTTP GET请求的响应结果是，采用Atom或者是RSS联合格式的XML数据。Google也使用Atom以及POST、PUT和DELETE操作来完成公共协议。eBay服务提供通过使用不同语言工具来访问服务，这些工具包括文档/文字风格的SOAP以及REST风格。

那么，对于XML-RPC和SOAP所具有的RPC风格而言，REST风格是否是一个具有竞争力的替代者呢?当然，我决不这样认为，在下一篇文章中，我将尽量向大家展现SOAP所向无敌的领域。
———END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71777.html
仅作参考

Tags: rest, soap, compare, 比较

PHP | 评论:0 | 阅读:27949

javascript---浅析注册事件

Submitted by gouki on 2008, August 15, 11:18 PM

在这个浮躁的世界里，说实话，很难看到一两篇好的文章，我写的一般都比较垃圾，但我会尽量发现精品。在闲逛的时候发现这篇文章确实不错，虽然讲的比较简单一点。

文章是从cssrain.cn上COPY而来，原文网址为：http://item.feedsky.com/~feedsky/cssrain/~6110346/103912558/4218245/1/item.html

内容如下：

首先是最常规的方法：

XML/HTML代码
  1. <p id="para" title="cssrain demo!" onclick="test()" >test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6. </script>  

当某一天，我们知道JavaScript要跟HTML结构实现分离后，就会改了一种写法:

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6. window.onload = function(){  
  7.     document.getElementById("para").onclick = test;  
  8. }  
  9. </script>  

当我们工作越来越久后，有时候我们需要对某个元素绑定多个相同的事件类型：

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. window.onload = function(){  
  12.      document.getElementById("para").attachEvent("onclick",test);  
  13.      document.getElementById("para").attachEvent("onclick",pig);  
  14. }  
  15. </script>  

在一段时间内，你并没发现这段代码有任何错误。
某一天，一个名叫firefox的浏览器 闯入你的视野，当我们把这段代码放到firefox中执行后，
发现并不能正常运行。 问题就这样，越来越多，然而作为一名JS程序员，这些都是必须面对的。

为了解决这段代码的平台兼容性问题，我翻翻手册，知道了firefox跟ie的区别：
firefox中注册事件使用：addEventListener方法，同时为了兼容ie，我们必须用到if ... else...

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. window.onload = function(){  
  12.          var element =  document.getElementById("para");  
  13.          if(element.addEventListener){  // firefox  , w3c  
  14.                 element.addEventListener("click",test,false);  
  15.     element.addEventListener("click",pig,false);  
  16.          } else {   // ie  
  17.     element.attachEvent("onclick",test);  
  18.     element.attachEvent("onclick",pig);  
  19.          }  
  20. }  
  21. </script>  

此时，代码就可以在多个平台上工作了。

但随着水平的进步，你不满足每次都去判断，你想把这个判断封装起来，以后可以直接调用：

XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. function addListener(element,e,fn){  
  12.      if(element.addEventListener){  
  13.           element.addEventListener(e,fn,false);  
  14.      } else {  
  15.           element.attachEvent("on" + e,fn);  
  16.      }  
  17. }  
  18.   
  19. window.onload = function(){  
  20.          var element =  document.getElementById("para");  
  21.          addListener(element,"click",test);  
  22.          addListener(element,"click",pig);  
  23. }  
  24. </script>  
XML/HTML代码
  1. <p id="para" title="cssrain demo!">test</p>  
  2. <script>  
  3. function test(){  
  4.   alert("test");  
  5. }  
  6.   
  7. function pig(){  
  8.   alert("pig");  
  9. }  
  10.   
  11. function addListener(element,e,fn){  
  12.      if(element.addEventListener){  
  13.           element.addEventListener(e,fn,false);  
  14.      } else {  
  15.           element.attachEvent("on" + e,fn);  
  16.      }  
  17. }  
  18.   
  19. window.onload = function(){  
  20.          var element =  document.getElementById("para");  
  21.          addListener(element,"click",test);  
  22.          addListener(element,"click",pig);  
  23. }  
  24. </script>  

 至此，作为一个程序员的工作就完了。
中间我们从一个最传统，最基本的写法 ， 然后实现Js和HTML的分离，然后又实现对同一个元素注册多个事件，期间，我们发现注册事件的兼容性问题。最后我们对注册事件的方法进行封装，方便以后使用。

———END——

浏览器这东西还是非常害人的。啥时候才能有统一的标准 ？？？

Tags: javascript, 注册

Javascript | 评论:0 | 阅读:22267

Records:3094«‹575576577578579580581582583584›»