|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-09
age0 写道 jaskell能不能处理对象？比如说我在java里面定义了几个对象，能不能直接把这几个对象传给jaskell去处理。
可以。 如果是对象，你或者需要把它传递给jaskell解释器。这样： Jaskell jaskell = Jaskell.defaultInstance();;
jaskell = jaskell.importValue("myobj", myobj);;
jaskell.eval("mymodule", "myobj.mymethod[]");;
这个代码就调用了myobj.mymethod(); 或者需要让jaskell能够通过某一个类得到这个对象（在java中也一样啊） 比如：
Jaskell jaskell = jaskell.defaultInstance();;
jaskell.eval("mymodule", "MyClass.getMyObj[].mymethod[]");
|
| 返回顶楼 | |
|
发表时间：2005-03-09
引用 xml文件比java代码还难懂？xml文件会冗长是确实的，但感觉比代码强啊。
你觉得是： obj = new MyObject();;
obj.setName("tom");;
obj.setAge(10);;
obj.setParent(obj2);;
容易懂，是 bean "MyObject“
{name="tom"; age=10;parent=obj2}
容易懂，还是 <bean id="myobj" class = "MyObject"> <property name="name"><value>tom</value></property> <property name="age"><value>10</value></property> <property name="parent"><beanref id="obj2"/></property> </bean> 容易懂？ 这还是简单的例子，xml虽然写起来繁琐一点，但是还比较直观。 如果涉及到list, map等等东西，就更麻烦了。我是看了一篇spring的介绍，对它作为例子的一些xml觉得非常别扭。 xml文件的信息重用也是个问题。同样的信息可能在很多地方重复。entity语法丑陋，而且局限也比较大。 引用 至于熟悉dtd，熟悉新的语法不也是一种熟悉吗。
嗯。如果用脚本，只要熟悉一个脚本的语法就好了。采取同一种脚本语言的不同应用的配置文件之间非常类似。 而用xml，你懂了web.xml，不见得能看懂spring的xml文件，不见得看的懂hibernate的xml。各个不同的vendor的xml的dtd和语义千差万别。各个tag代表什么意思，每一个值怎么表示，list, array, dependency怎么表示也都不同。 这就象地球人都用嘴说话，但是同一个音节发出来却代表不同的意思。 当然，不同的应用使用脚本配置的话，也可能会各自有各自的api，但是因为这些api都在这个脚本语言的框架内，各个语法元素的语义相比xml更加固定，有章可循，所以熟悉api的过程比熟悉dtd要容易。 这里， 熟悉脚本的语法大概比熟悉xml的语法要难些。但是这个开销是一次性的。 而熟悉脚本的api我觉得比熟悉各个xml配置文件的dtd和表示法要简单。而这是更加频繁的。 引用 脚本式的最大问题就是缺少好的编译器和调试器。 脚本就不需要什么编译器了。至于调试，xml就好调试？如果简单的逻辑，比如就是name-value pair，那么用脚本和用xml也没什么调试难度上的差别。 引用 而且考虑到一旦混合，就要明确哪些需要脚本，哪些需要文件，这就会导致项目成员各自为政，加大管理难度。对于那些有专人完成配置编写人员的组织这个也许就不是问题了。 所以可以考虑干脆全用某种脚本啊。至少是一个可能的发展方向。 引用 ajoo 写道 后者不但简洁很多，而且，自动拥有jskell提供的所有的高阶函数能力和直接调用java的能力。 jaskell提供的扩展功能也让自定义新的配置语义易如反掌。（这些bean, new函数就是通过jaskell api简单地扩展出来的） 不像xml，你要新添加一个element,要改dtd，改很多xml相关的东西来支持这个新的语义。 另外，用来处理基于构造函数甚至静态工厂的对象构造也容易，比如： {
CompositeBean = new "test.jfun.CompositeBean" ["jack", 33, [bean0, mbean]];
);扩充能力是个不错的卖点，但对于一般人很少会用到这种功能吧。 对象的关系的复杂必然导致配置文件复杂，但用脚本就能解决吗？深表怀疑，不知道有谁能提供出这样的实例来。我自己碰到到的都是中等复杂的，虽然配置文件很大，但关系并不复杂。 你觉得我举的那个配置bean的脚本是否比用xml简洁呢？ 我想，如果你需要给自己的应用提供一些比较特殊的配置功能（比如说这个功能不能用web.xml或者任何一个现有的xml文件格式来达到），那么应用jaskell的扩展功能是比自己去搞xml要容易的。 我们一个项目前段时间给validation逻辑做配置，为了支持自己的xml格式，还颇费了点劲来处理xml以及分析出来的数据，根据xml中储存的数据进行解释等等。 这是因为xml代表的是被动的数据，即使有xml parser, xml binder等工具，你仍然需要对这个输出的数据进行分析，处理。 而脚本内部存储的是主动的逻辑，解释出来的结果马上就是可用的对象。 至于说复杂配置，个人觉得spring的配置文件就有点复杂了。 比较一下下面两个配置（注意，脚本配置针对product1, product2, product3做了些重用的处理，把重复的部分消除掉了）： <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<!--
- Application context definition for "springapp" DispatcherServlet.
-->
<beans>
<bean id="springappController" class="web.SpringappController">
<property name="productManager">
<ref bean="prodMan"/>
</property>
</bean>
<bean id="prodMan" class="bus.ProductManager">
<property name="products">
<list>
<ref bean="product1"/>
<ref bean="product2"/>
<ref bean="product3"/>
</list>
</property>
</bean>
<bean id="product1" class="bus.Product">
<property name="description"><value>Lamp</value></property>
<property name="price"><value>5.75</value></property>
</bean>
<bean id="product2" class="bus.Product">
<property name="description"><value>Table</value></property>
<property name="price"><value>75.25</value></property>
</bean>
<bean id="product3" class="bus.Product">
<property name="description"><value>Chair</value></property>
<property name="price"><value>22.79</value></property>
</bean>
<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename"><value>messages</value></property>
</bean>
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/hello.htm">springappController</prop>
</props>
</property>
</bean>
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass"><value>org.springframework.web.servlet.view.JstlView</value></property>
<property name="prefix"><value>/WEB-INF/jsp/</value></property>
<property name="suffix"><value>.jsp</value></property>
</bean>
</beans>
{
springappController = bean "web.SpringappController"{
productManager = prodMan
};
messageSource = bean "org.springframework.context.support.ResourceBundleMessageSource"{
basename="messages"
};
urlMapping = bean "org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"{
mappings=[assoc["/hello.htm", "springappController"]]
};
viewResolver = bean "org.springframework.web.servlet.view.InternalResourceViewResolver"{
viewClass="org.springframework.web.servlet.view.JstlView";
prefix="/WEB-INF/jsp/";
suffix=".jsp"
};
}
where
prodMan = bean "bus.ProductManager"{
products = [product1,product2,product3]
};
product1 = productbean "Lamp" 5.75;
product2 = productbean "Table" 75.25;
product3 = productbean "Chair" 22.79;
productbean desc price = bean "bus.Product"{
description=desc;
price=price
};
assoc = jaskell.tuple.assoc;
|
| 返回顶楼 | |
|
发表时间：2005-03-09
ajoo 写道 如果涉及到list, map等等东西，就更麻烦了。我是看了一篇spring的介绍，对它作为例子的一些xml觉得非常别扭。 xml文件的信息重用也是个问题。同样的信息可能在很多地方重复。entity语法丑陋，而且局限也比较大。 list,map是有些繁琐，但并不难懂。重复的位置也可以利用<ref parent="someBean"/>完成。局限性肯定是有的，但够用就行。 引用 嗯。如果用脚本，只要熟悉一个脚本的语法就好了。采取同一种脚本语言的不同应用的配置文件之间非常类似。 而用xml，你懂了web.xml，不见得能看懂spring的xml文件，不见得看的懂hibernate的xml。各个不同的vendor的xml的dtd和语义千差万别。各个tag代表什么意思，每一个值怎么表示，list, array, dependency怎么表示也都不同。 这就象地球人都用嘴说话，但是同一个音节发出来却代表不同的意思。 当然，不同的应用使用脚本配置的话，也可能会各自有各自的api，但是因为这些api都在这个脚本语言的框架内，各个语法元素的语义相比xml更加固定，有章可循，所以熟悉api的过程比熟悉dtd要容易。 这里， 熟悉脚本的语法大概比熟悉xml的语法要难些。但是这个开销是一次性的。 而熟悉脚本的api我觉得比熟悉各个xml配置文件的dtd和表示法要简单。而这是更加频繁的。 严重的不同意， 首先，很多配置文件并不是要配置出一个类出来，比如web.xml和hibernate的xml，能不能用jaskell展示一下如何使用？ 其次，一个项目当中用到多个框架的不同的配置，jaskell能否全替代？目前看，似乎只是替代spring的配置，所以，熟悉spring的xml的语法和一个脚本的api谁的成本高？ 再次，即使能实现比如各个vendor用同一个脚本配置，那是不是所有vendor都可以用同一种格式的xml呢？ 最后，这年头，脚本有点多，语法都去学一下，我是有点害怕的。 引用 脚本就不需要什么编译器了。至于调试，xml就好调试？如果简单的逻辑，比如就是name-value pair，那么用脚本和用xml也没什么调试难度上的差别。 我说错了，不是编译器，而是编辑器，spring的eclipse插件可以自动完成，可以直接排错，可以图形化bean之间的关系，我想随着编辑器越来越好用，xml 配置会变简单。调试的话，二者确实差不多，不过脚本倒有出调试器的可能性，xml就难说了。 引用 所以可以考虑干脆全用某种脚本啊。至少是一个可能的发展方向。 那至少是有一种脚本非常流行才有可能，而目前很难啊。 引用 你觉得我举的那个配置bean的脚本是否比用xml简洁呢？ 我想，如果你需要给自己的应用提供一些比较特殊的配置功能（比如说这个功能不能用web.xml或者任何一个现有的xml文件格式来达到），那么应用jaskell的扩展功能是比自己去搞xml要容易的。 对于一般应用，很少会用到特殊配置的，为这个目的就选用脚本的理由不够充分。用脚本配置，确实会使配置文件短很多。能不能演示一下，如何完成spring中aop的配置。 |
| 返回顶楼 | |
|
发表时间：2005-03-10
youcai 写道 list,map是有些繁琐，但并不难懂。重复的位置也可以利用<ref parent="someBean"/>完成。局限性肯定是有的，但够用就行。 我说的是跨越一个xml element或者在一个element内部的一部分信息的重复。 xml只提供了一个ref，远远不够。ref也没有参数可以传递，可以说当信息重用的要求稍微多一点它就不够用了。 比如我举的那个例子里面的product1, product2, product3这三个东西，除了一点点信息不同，他们共享很多相同的东西（类名字，property名字等） 用函数可以轻松搞定，而用xml？难。 youcai 写道 引用 嗯。如果用脚本，只要熟悉一个脚本的语法就好了。采取同一种脚本语言的不同应用的配置文件之间非常类似。 而用xml，你懂了web.xml，不见得能看懂spring的xml文件，不见得看的懂hibernate的xml。各个不同的vendor的xml的dtd和语义千差万别。各个tag代表什么意思，每一个值怎么表示，list, array, dependency怎么表示也都不同。 这就象地球人都用嘴说话，但是同一个音节发出来却代表不同的意思。 当然，不同的应用使用脚本配置的话，也可能会各自有各自的api，但是因为这些api都在这个脚本语言的框架内，各个语法元素的语义相比xml更加固定，有章可循，所以熟悉api的过程比熟悉dtd要容易。 这里， 熟悉脚本的语法大概比熟悉xml的语法要难些。但是这个开销是一次性的。 而熟悉脚本的api我觉得比熟悉各个xml配置文件的dtd和表示法要简单。而这是更加频繁的。 严重的不同意， 首先，很多配置文件并不是要配置出一个类出来，比如web.xml和hibernate的xml，能不能用jaskell展示一下如何使用？ 其次，一个项目当中用到多个框架的不同的配置，jaskell能否全替代？目前看，似乎只是替代spring的配置，所以，熟悉spring的xml的语法和一个脚本的api谁的成本高？ 再次，即使能实现比如各个vendor用同一个脚本配置，那是不是所有vendor都可以用同一种格式的xml呢？ 最后，这年头，脚本有点多，语法都去学一下，我是有点害怕的。 如果这些框架在xml底层提供了可编程的配置接口（比如pico就提供了java api），那么自然可以用jaskell替代了。谁的成本高？呵呵。也许人和人不同吧。我自己熟悉jaskell语言，自然觉得两个简单的函数比若干条xml的规定容易懂。 web.xml和hibernate.xml我会找时间展示一下。 你置疑vendor们不是都用同种格式的xml，这正好和我的观点相同。我认为xml这种语言语义太贫乏，稍微高级点的东西就需要vendor自己发明一套自己的dtd和语义。 比如，如果vendor想给xml提供传递参数的功能（如ant的build.xml现在就是没法简单地给task传递参数），那么必然要费尽心机弄一套dtd出来，然后后台处理这种带参数的element的语义的代码也必然很多，前面还得提供一堆对这些新的element的语义和用法的解释。为什么？因为xml给我们的东西太少啦。 而如果用脚本，这些功能脚本都提供了。vendor只要根据需要提供的语义写几个api就万事大吉。api如何调用脚本语言早就规定好了，你只要说清楚这个api干什么就行了。 另外，xml主要是个树形的结构，用来描述树自然没问题，但是问题是，很多现实中的问题不是简单的一颗树。如果用xml勉强描述这种信息，自然显得笨拙。 youcai 写道 引用 所以可以考虑干脆全用某种脚本啊。至少是一个可能的发展方向。 那至少是有一种脚本非常流行才有可能，而目前很难啊。 这倒是。在我看来，xml的最大好处就是标准，围绕它的支持技术也多。 youcai 写道 对于一般应用，很少会用到特殊配置的，为这个目的就选用脚本的理由不够充分。用脚本配置，确实会使配置文件短很多。能不能演示一下，如何完成spring中aop的配置。 我回头找个aop配置的sample文件来模拟一下。或者，如果你有的话，不妨贴上来？ |
| 返回顶楼 | |
|
发表时间：2005-03-10
看了一下spring的aop，其实spring几乎所有的东西都围绕java bean的配置，所以aop的配置用jaskell替换起来仍然是跟前面一样，照猫画虎。
spring的配置文件： <bean id="SearchBookBean" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyInterfaces"><value>library.SearchBookBean</value></property>
<property name="interceptorNames">
<list>
<value>myInterceptor</value>
<value>SearchBookBeanTarget</value>
</list>
</property>
</bean>
对应的jaskell配置： {
SearchBookBean = bewan "org.springframework.aop.framework.ProxyFactoryBean"{
proxyInterfaces = "library.SearchBookBean";
interceptorNames = ["myInterceptor", "SearchBookBeanTarget"];
}
}
倒是hibernate的配置，因为不是java bean，所以应该需要利用jaskell的扩展功能，再写几个配置函数：mapping, session_factory等。 hibernate的mapping xml如下： <?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 2.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">
<hibernate-mapping>
<class name="de.gloegl.road2hibernate.Event" table="EVENTS">
<id name="id" column="uid" type="long">
<generator class="increment"/>
</id>
<property name="date" type="timestamp"/>
<property name="title" column="eventtitle"/>
</class>
</hibernate-mapping>
对应的jaskell代码应该是这样： [
mapping "de.gloegl.road2hibernate.Event" "EVENTS"
.id {name="id"; column="uid"; type=types.long; generator="increment"}
.property "date" {type="timestamp"}
.property "title" {column="eventtilte"}
]
这个list里面是一串的mapping函数返回的对象。 mapping函数支持两个参数，第一个参数是类名字，第二个是table名字。 它支持id和property两个成员，用来添加id和property。 hibernate configuration文件如下： <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 2.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd">
<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.driver_class">org.hsqldb.jdbcDriver</property>
<property name="hibernate.connection.url">jdbc:hsqldb:data/test</property>
<property name="hibernate.connection.username">sa</property>
<property name="hibernate.connection.password"></property>
<property name="dialect">net.sf.hibernate.dialect.HSQLDialect</property>
<property name="show_sql">true</property>
<property name="transaction.factory_class">
net.sf.hibernate.transaction.JDBCTransactionFactory
</property>
<property name="hibernate.cache.provider_class">
net.sf.hibernate.cache.HashtableCacheProvider
</property>
<property name="hibernate.hbm2ddl.auto">update</property>
<mapping resource="de/gloegl/road2hibernate/Event.hbm.xml"/>
</session-factory>
</hibernate-configuration>
对应的jaskell配置如下： session_factory $ load "de/gloegl/road2hibernate/Event.hbm.jsl" $ assoc[ "hibernate.connection.driver_class", "org.hsqldb.jdbcDriver", "hibernate.connection.url", "jdbc:hsqldb:data/test", "hibernate.connection.username","sa", "hibernate.connection.password","", "dialect","net.sf.hibernate.dialect.HSQLDialect", "show_sql",true, "transaction.factory_class","net.sf.hibernate.transaction.JDBCTransactionFactory", "hibernate.cache.provider_class","net.sf.hibernate.cache.HashtableCacheProvider", "hibernate.hbm2ddl.auto","update", ] 几点需要引起注意的： 1。session_factory这个函数期待两个参数。第一个是mapping列表，第二个是一个property-value的查找表。 maping是列表而不是一个文件名字。这样的好处是，对于简单的mapping，你甚至可以不写单独的mapping文件，直接就在config文件里面定义mapping就好。 而对于复杂的mapping，用个load函数来把这个文件读出来就好了。 而不知道你注意到没有，load函数的存在也同时意味着，如果愿意，我们可以把任何一段信息单独存储到某一个单独的文件中去，而不是只能死板地照hibernate的规定划分文件。比如，我们也可以把那些properties单独弄到一个文件中去。 2。$符号是jaskell里面用来改变表达式优先级的符号。这样就省得用括号把这个巨大的assoc函数调用括起来。 3。assoc函数用来把一个列表转换成一个查找表。这也是预定义的函数。 4。jaskell作为函数型语言，可以让写出来的代码尽可能的简洁，废话尽可能的少。这可以让人把注意力完全集中在要表达的逻辑上面，而不受过多的语法方面的限制。 当然，针对hibernate的这些jaskell函数必须要在java中实现。但是借助jaskell的扩展能力，这很简单。 jaskell语言本身并不提供一个大而全的包罗万有的平台，但是它确实给你提供了方便的扩展能力，让针对任意的应用需求进行剪裁和扩充成为可能。 |
| 返回顶楼 | |
|
发表时间：2005-03-10
to ajoo
让xml支持元素重复应该是可以实现的，但无论如何实现确实都不如函数精简。 现实是，各vendor已经都有各自的dtd了，再弄一个支持脚本的就属于锦上添花的工作了，而且还要支持不只一种脚本，不知道难度会有多高。你要推广jaskell，倒是可以考虑为常见的框架和工具包做扩展。 引用 而如果用脚本，这些功能脚本都提供了。vendor只要根据需要提供的语义写几个api就万事大吉。api如何调用脚本语言早就规定好了，你只要说清楚这个api干什么就行了。 这是不是意味着不仅要有脚本支持功能，同时还必须有一定的写好的功能脚本来支持，才会有价值？ 看了演示，觉得还是创建java bean的脚本容易懂，因为都是*** = ***** 而等号后面无非是些属性或者构造函数等等,到下面的脚本就觉得有点云山雾罩了。 再出点题： 1，spring可以支持singleton和非singleton，支持惰性初始化，支持指定一个初始化方法和销毁方法。 2，由于使用Autowiring 可以减少很大的配置工作（虽然有可能有问题），脚本能提供类似功能吗？比如dao都需要同一个sessionfactory而我有几十个dao的时候，就体现出Autowiring作用来了。 3，感觉上如果依赖于这种方法配置大量的类的时候，即使是脚本也会变得很大，当这些类之间还想有先后顺序的时候，这个控制就不好做了，而xml可以利用dependencies来检查，因为xml是配置文件。可以在全部配置都分析完了再决定类初始化的顺序。 <bean id="person" class="org.springframework.beans.TestBean" singleton="false" init-method="init" destroy-method="cleanup"> <property name="age"><value>10</value></property> <property name="spouse"> <bean class="org.springframework.beans.TestBean"> <property name="age"><value>11</value></property> </bean> </property> </bean> |
| 返回顶楼 | |
|
发表时间：2005-03-10
引用 让xml支持元素重复应该是可以实现的，但无论如何实现确实都不如函数精简。
现实是，各vendor已经都有各自的dtd了，再弄一个支持脚本的就属于锦上添花的工作了，而且还要支持不只一种脚本，不知道难度会有多高。你要推广jaskell，倒是可以考虑为常见的框架和工具包做扩展。 确实如此。一个应用要支持若干种不同的配置确实不经济。 但是要支持不只一种脚本也太夸张了吧？ 这就是一个标准化的工作了。xml的好处就是标准，而坏处就是描述一些复杂逻辑繁琐难懂。如果能有一个标准的脚本就好了。 即使没有，我觉得在一些xml不是很胜任的场合采用某种脚本应该是更好的选择。 引用 这是不是意味着不仅要有脚本支持功能，同时还必须有一定的写好的功能脚本来支持，才会有价值？
看了演示，觉得还是创建java bean的脚本容易懂，因为都是*** = ***** 而等号后面无非是些属性或者构造函数等等,到下面的脚本就觉得有点云山雾罩了。 如果没有实现写好的api，就可能要脚本直接调用java class。这个调用不见得最直观。所以从尽量简化脚本考虑，一些写好的api是必要的。 至于后面的代码，看不懂主要是因为你本身对这个脚本语言就不熟悉。其实不管什么语言，只怕你没学过语法直接上来就看实际应用中的不是hello world的代码都会晕吧？ 另外，这个脚本是函数式的。如果熟悉函数式编程的人会更容易上手。 引用 再出点题：
1，spring可以支持singleton和非singleton，支持惰性初始化，支持指定一个初始化方法和销毁方法。 jaskell语言就是lazy的。在tuple内部的成员都是每次引用求一次值。而where定义的变量都是最多求一次值（就是singleton了） 所以这点通过语言就可以做到。不需要你在java中做任何事。 如：
{
mybean = bean "MyClass";
}
就是惰性的，每次取值就生成一个新的对象。 而 {
mybean = mb;
}
where mb = bean "MyClass";
就是singleton的。
对比xml的配置方法，你的java处理程序则必须要读这个"singleton"属性，然后根据这个属性做对应的语义处理。 如果明天忽然发现需要来一个round robbin式的轮换返回两个实例，还要增加新的xml element，增加大量的处理这个语义的java代码。 当然，如果喜欢xml的singleton=true这种声明式的方法，大可以给bean函数添一个参数就是了。 引用 2，由于使用Autowiring 可以减少很大的配置工作（虽然有可能有问题），脚本能提供类似功能吗？比如dao都需要同一个sessionfactory而我有几十个dao的时候，就体现出Autowiring作用来了。
Auto wire都是在java中做掉的。比如pico。配置文件只不过负责配置auto-ware。如果用jaskell配置pico，大概会是这样： container
.register("Class1");
.register("Class2");
.register(“Class3");;
引用 3，感觉上如果依赖于这种方法配置大量的类的时候，即使是脚本也会变得很大，当这些类之间还想有先后顺序的时候，这个控制就不好做了，而xml可以利用dependencies来检查，因为xml是配置文件。可以在全部配置都分析完了再决定类初始化的顺序。
<bean id="person" class="org.springframework.beans.TestBean" singleton="false" init-method="init" destroy-method="cleanup"> <property name="age"><value>10</value></property> <property name="spouse"> <bean class="org.springframework.beans.TestBean"> <property name="age"><value>11</value></property> </bean> </property> </bean> 应该说，没有配置文件能作而程序语言做不到的。 脚本虽然可以主动创建对象，但是我们也可以选择让它象xml一样被动描述对象。比如，我们只让脚本返回一个数据结构，然后在java里面搞这些依赖分析什么的。这就跟xml做的差不多了。 xml只有被动描述一种选择，脚本则两者都做的到，甚至可以混合。 只不过脚本强大得多，用了脚本，我们往往会更贪心，让它做的更多。 person = beandesc "org.springframework.beans.TestBean"
{singleton=false;init_method="init";destroy_method="destroy"}
{
age=10;
spouse= beandesc "org.springframework.beans.TestBean"
{}
{age=11}
};
这个beandesc函数只负责记录所有的信息，但是不创建对象，java程序读入这个描述对象后，做分析，最后再创建对象。 不过，谢谢你的提醒，我现在觉得也许应该把这个功能直接实现在jaskell的release里面，因为它应该很常用。 |
| 返回顶楼 | |
|
发表时间：2005-03-10
ajoo 写道 这就是一个标准化的工作了。xml的好处就是标准，而坏处就是描述一些复杂逻辑繁琐难懂。如果能有一个标准的脚本就好了。 即使没有，我觉得在一些xml不是很胜任的场合采用某种脚本应该是更好的选择。 只有一个标准脚本有点难，我印象中maven就有内置的一个脚本支持，它和xml混在一起。但看很多配置文件，但很少人用。 引用 如果没有实现写好的api，就可能要脚本直接调用java class。这个调用不见得最直观。所以从尽量简化脚本考虑，一些写好的api是必要的。 这些api是java的还是脚本的？ 引用 Auto wire都是在java中做掉的。比如pico。配置文件只不过负责配置auto-ware。如果用jaskell配置pico，大概会是这样： container
.register("Class1");
.register("Class2");
.register(“Class3");;
我有点理解了，是不是要实现这个功能，首先先把spring中关于实现auto-ware的代码拿过来，仅仅是用jaskell替换配置？但因为Auto wire是个配置标示，是不是对于函数来说就是增加一个参数。 脚本式替换配置文件应该没有问题，问题应该是替换到哪种程度，什么情况下脚本更有优势，再就是脚本本身能否流行和标准化。 |
| 返回顶楼 | |
|
发表时间：2005-03-10
重读martin fowler的Dependency Injection文章，里面说到代码配置和文件配置之间的关系，当时似乎没有多注意，惭愧啊。
尤其是对于编写组件的人提出，应该提供一个方便的编程接口。 |
| 返回顶楼 | |
|
发表时间：2005-03-11
youcai 写道 只有一个标准脚本有点难，我印象中maven就有内置的一个脚本支持，它和xml混在一起。但看很多配置文件，但很少人用。 是啊。标准化是很难。就象浏览器。明显莫衷一是的浏览器给开发造成了很大问题，但是还是标准化不了。 youcai 写道 引用 如果没有实现写好的api，就可能要脚本直接调用java class。这个调用不见得最直观。所以从尽量简化脚本考虑，一些写好的api是必要的。 这些api是java的还是脚本的？ 是用java实现，但是输入到脚本里面供脚本用。 比如， Function register = ...; jaskell.importValue(“register", register); 这样脚本就可以用register函数了。 youcai 写道 引用 Auto wire都是在java中做掉的。比如pico。配置文件只不过负责配置auto-ware。如果用jaskell配置pico，大概会是这样： container
.register("Class1");
.register("Class2");
.register(“Class3");;
我有点理解了，是不是要实现这个功能，首先先把spring中关于实现auto-ware的代码拿过来，仅仅是用jaskell替换配置？但因为Auto wire是个配置标示，是不是对于函数来说就是增加一个参数。 脚本式替换配置文件应该没有问题，问题应该是替换到哪种程度，什么情况下脚本更有优势，再就是脚本本身能否流行和标准化。 把spring的api包装成jaskell的Function对象，然后输入到jaskell对象中。 因为auto wire是个标志，我们可以选择让它作为一个额外的函数参数（当然，还有其它选择）。 一个精心设计的配置api，往往能够提供比xml大的多的灵活性。 比如，你前面说xml的destroy-method, init-method等。但是xml只支持一个函数名字。万一你要传入一些参数呢？ 比如，destroy的时候，我想调用destroy(true)怎么办？ 用脚本，我们可以设计出这样的效果： bean {
create = new "MyClass"[];
init obj = obj.initialize[now];
destroy obj = obj.destroy[true];
};
或者： bean {
create = import "MyClass".newInstance[];
init obj = obj.initialize[];
destroy obj = java.lang.System.out.println["destroying"] >>
obj.destroy[true];
};
这样构造方法，初始化方法，销毁方法都可以自由定制，而不仅仅局限于一个函数名字。 第二个例子还提供了在销毁时候的额外的logging。 >>这个操作符表示顺序执行。 |
| 返回顶楼 | |
