很显然这个逻辑适用于所有创造器,尽管如此"null"创造器是最容易配置的。适用单例类对于单例类的创建,最好适用BeanShell和BSF来实例化对象。详细信息参见'Scripted'创造器其他创造器我么偶尔也需要一些新的创造器,最常见的是一个EjbCreator。讨论新的创造器的好地方是在邮件列表。DWR和HttpSessionBindingListenersDWR1.x中存贮已经创造的Bean的方法需要注意,它在每次请求时都会调用相同的setAttribute()方法。就是说,如果一个Bean在dwr.xml中的声明周期设置为session,再每次调用bean中的方法时,DWR都会执行一次session.setAttribute(yourBean)。这看上去没有什么危害,但是如果你要使用servlet的事件机制的,就是说用了HttpSessionBindingListener接口,你就会发现valueBound和valueUnbound事件在每次调用时都会发生,而不是你想像的在bean被创建时以及session过期时。DWR2只在第一次创建对象时调用setAttribute()。
dwr.xml中的签名(Signatures)signatures段使DWR能确定集合中存放的数据类型。例如下面的定义中我们无法知道list中存放的是什么类型。publicclassCheck{publicvoidsetLotteryResults(Listnos){...}}signatures段允许我们暗示DWR应该用什么类型去处理。式对以了解JDK5的泛型的人来说很容易理解。<signatures><![CDATA[importjava.util.List;importcom.example.Check;Check.setLotteryResults(List<Integer>nos);]]></signatures>DWR中又一个解析器专门来做这件事,所以即便你的环境时JDK1.3DWR也能正常工作。解析规则基本上会和你预想规则的一样(有两个例外),所以java.lang下面的类型会被默认import。第一个是DWR1.0中解析器的bug,某些环境下不能返回正确类型。所以你也不用管它了。第二个是这个解析器时"阳光(sunnyday)"解析器。
就是说它非常宽松,不想编译器那样严的保证你一定正确。所以有时它也会允许你丢失import:<signatures><![CDATA[importjava.util.List;Check.setLotteryResults(List<Integer>);]]></signatures>将来的DWR版本会使用一个更正式的解析器,这个编译器会基于官方Java定义,所以你最好不要使用太多这个不严的东西。signatures段只是用来确定泛型参数中的类型参数。DWR会自己使用反射机制或者运行时类型确定类型,或者假设它是一个String类型。所以:不需要signatures-没有泛型参数:publicvoidmethod(Stringp);publicvoidmethod(String[]p);需要signatures-DWR不能通过反射确定:publicvoidmethod(List<Date>p);publicvoidmethod(Map<String,WibbleBean>p);不需要signatures-DWR能正确的猜出:publicvoidmethod(List<String>p);publicvoidmethod(Map<String,String>p);不需要signatures-DWR可以通过运行时类型确定:publicList<Date>method(Stringp);没有必要让Javascript中的所有对象的key都是String类型-你可以使用其他类型作为key。
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-25046-9.html
fightordie
收了多少公关费