2006年04月30日
cookoo 写道:
日本6,70年代经济高速发展的时期也有社会过分功利化的现象. 当时的日本文学家呼吁人们别忘了钱买不到的那些东西: 知识, 环境, 良心…



不知道我们现在的社会有没有像这样的声音?





我们需要声音;我们需要改变!



改变必然伴随痛苦,人直接反应就是规避,进一步是对源头的抵制和打击。


缺乏"自由人格"的大群体,直接反应会不会占主体?这个直接反应会不会直接杀掉声音,就像"杀"掉那个爱哲学的孩子?



liusong1111 写道:


从大_锅_饭到包干到户到现在提的农村城市化,感觉很有戏剧性。




我原本的意思是,为什么每个时期人们的思想总是如此统一。规模化生产->非规模化生产->规模化生产,人们如何平和的接受着一个个矛盾。



感觉佛教越来越受到人们关注~

zxc005 写道:
liusong1111 写道:
simohayha又发好文!~



我不发消极言论了~



前几天真正见识了偶像为何称为偶像 – 人生态度!


我也在努力剥去自身世俗的皮~






为何不把你的收获给大家分享一下?





我每冒出个想法总会到javaeye上说说,不管别人喜不喜欢,起码对自己是个促进。


没说过的就是没想过/不知道的(嗯嗯,打个比方,我们应聘的时候,人力资源不提饭补的事,那肯定没戏 Very Happy



提个问题:谁想过 "志趣驱动生活" ?谁在准备这样的生活?谁在享受这样的生活?



对于我,还在困扰于"我的志趣是什么" Confused



今天北京交通广播电台的王佳一 与 阿丘
一起主持了节目,话题是城市交通的停车位问题。看了日本地铁附近寄存自行车的设施,十分震撼。md,这么想想老百姓普遍的功利意识不是没道理,你得时刻操
心生计上鸡毛蒜皮的琐事。当生存和安全这样的基础设施保障不够,人们要做的,就是追求拥有更多以备将来。


话又说回来,我们是初级阶段,100年不动摇~



原先只在广播里听过王佳一,十分喜欢。语速/应变快,发音清,幽默开朗乐观,业务熟,知识面宽,心态好,贴近生活。去央视羞一羞那些所谓的名嘴主持人 Laughing Idea



八荣八耻在舆论上的造势,看来只能控制那些没落的相声演员了,闹轰轰的招人烦。一直热播的《杨光的快乐生活》不就是积极的宣传者吗?提出倡导八荣八耻很及时,手法不能推陈出新令人失望,政_治理念到草根文化路在哪里…..



扯远了~

2006年04月29日

除了以前提的机会公平之说,中国社会的另一个症结在于不分基础和高端。
几个现象:
媒体缺乏宣传***大众化***的养生、医疗、育儿、饮食、法律、行居、就业、社交、安全、公德等生活中形形色色的常识,造成老百姓极度幼稚(!)可喜的是,这种题材在变多。 — how to establish the mechanism?
科研机构吃干饭。
农村基础设施不强。
住房、医疗、教育昂贵….

是什么造成这样呢?一方面鼓吹无私奉献,一方面屯积(垄断/封锁)基础设施(软硬件)谋利。
要求科研单位无私奉献,就缺少研究高端技术的热情。
封锁大众基础设施(住房、教育…)及基本理念(育儿…),就阻碍了社会进步。(这样钱好挣,就是太土,重复做得低级的工作,生活水平不可能提高)

看软件业的open source多是基础件,商业的多是高端产品。
open source发展,是基础件领域的扩张。商业的发展,是高端产品走向更高端。
人类社会的发展,就是技术进步、观念革新的过程,说白了,就是基础设施积累固化的过程。

什么拉动内需啦,农村城市化啦… 我看要先摆正这个理念。
嗯嗯,试试readworld.com的翻译效果,还不错:

infrastructure: fair,open,popular
superstructure: highly-competitive,highly-rewarded,highly-safeguarded

牙不疼了,希望睡一觉烧就降了。

2006年04月24日


我的命像风一样流落四面八方
我的梦还捧在手上而哪里才是天堂
我比你多些沧桑执着的却一样
这旅程有了你的眼光
让冰雪有阳光*
#我和你身不由已两颗心
相遇在茫茫人海路上
肩和肩的依靠
心和心的对望
我永远都有你分享
我和你身不由已两个人
感动在眼神之间游荡
我带你找梦想我陪你去天涯
就算一路尘土飞扬黑夜依然有天亮的希望

———————

blog不关张,也不能引火烧身…..

2006年04月19日

[quote]错误提示信息:
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
[color=red]Caused by: org.xml.sax.SAXParseException: The content of element type "class" must match "(meta*,(cache|jcs-cache)?,(id|composite-id),[/color]discriminator?,(version|timestamp)?,(property|many-to-one|one-to-one|component|dynamic-component|any|map|set|list|bag|idbag|array|primitive-array)*,(subclass*|joined-subclass*))".
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) [/quote]

<class>下必须有id或composite-id子元素,形式是:
<id ..>
而你是

[quote] <property name="id"
type="java.lang.String"
update="true"
insert="true">
<column name="Fid"/>
</property> [/quote]

hibernate对视图的支持我不了解,至少可以google下吧。

肯定进回收站或直接删除。

难道说入门级提问多起来,可以证明hibernate已经大面积普及了?

如果用IDEA或eclipse装上个插件(xman?),事情就会更明了。

哪个编程语言在语法级支持国际化?入门时学会看异常是道坎啊。
异常信息国际化了,可能入门的人上手更快吧。

看swt-designer支持国际化的方式挺不赖
[quote="gigix"]IDE的作用,说穿了无非是帮助你更快地写出一大堆跟你想做的事情不搭嘎的代码罢。[/quote]

经典!
java IDE最大的作用是弥补语言本身的缺陷,真是个遗憾,难道java程序员天生不喜欢IDE?.net framework和delphi显然不止这些,至少它们以不同perspective操作源码的技巧用得更好。
IDE能做什么、应该怎么做,我经常胡想这个问题,改天摆这个话题yy一下,顺便体验一下在非windows平台的人们用emacs、textmate等兵器有啥感受。

话又说回来,期待值上去了,现实不会改进,只会打击自己的士气。

说了这么多,版主还是删掉吧。哪天想明白了再开贴子聊,目的是充分利用IDE的优势,尽量少打击自己的士气。
komodo3.5.2也支持ruby的code intelligence了,尽管不好用,总比没有好。

2006年04月17日

拜读完毕。


delphi的Variant,OleVariant类型变量,它的方法调用不受编译器检查,是在运行时动态绑定。delphi对于javascript,python(python4delphi)的支持,都是利用这个语法特性实现的。


这种“动静结合”,感觉很好。

gigix 写道:
我觉得差不多,反正不管改配置文件还是改代码,改完以后都要build all然后run all tests,对我来说没区别。





记得去年一个讨论AOP的贴子里,gigix的观点是Annotation只是把元数据从配置文件挪到了源代码,没有实现其他的东西,我本人很赞同。


对于元数据,可以存放到 java代码、脚本、配置文件中,其区别大致是书写方便性、IDE友好性(编译时检查、code assist、设置向导)、布署便捷性。



对Annotation的质疑很大程度上是 在变更时布署上带来的麻烦,那么细究下来,产品什么时候布署新版本? 公司产品的版本计划和新版本布署方案是什么样的? 大概不会太频繁吧,都会build all吧。


那么对于开发过程呢?我想只要支持热布署,和以前的开发过程一样,不须我重启应用服务器就OK了。


没用过jdk5.0,希望各位指正。最好讲讲您是怎么用Annotation的,与传统方式在编码和开发布署流程下有什么需要注意的的吗?


======================


xml配置确实有它作为文本的好处。


引用:
这些例子都是我在实际项目中实实在在碰到过的情况,很多时候你在本地开发环境好好的系统,在生产环境就会遇到很多小毛病,这些小毛病往往只是需要你调整一下配置就可以解决的,但是如果放在annotation里面的话,你就必须经过一个很漫长的修改过程。




上面两个例子是在生产环境吧?


生产环境与开发环境不一致现象,毕竟不像开发中应对的事情多吧,当然,遇到后,解决的难度和压力也是很重要的。大概annotation对咨询过程不够友好吧 Smile



正常情况下集成测试不会太频,时间间隔也不会很短吧,对于俺们开发人员,充份利用IDE调试就可以啊。



说点题外话,关于开发环境的集成度,感觉差异也是挺大的,常规的IDE(内置web程序调试支持)+版本控制+问题跟踪,好的可以无缝集成DB管理、文档
写作、单元测试……,差的拿ultraedit编辑、ant编译、System.out写调试语句、复制.class/.jsp文件到应用环境调
试。感觉对开发环境的最佳搭建方案讨论不多,有没有必要另开个贴?



元数据写在源代码还是配置文件引起 概念的视角 确实不一样,个人觉得各有优点,需要看情况权衡。



AspectJ了解不多,感觉是不是以前太静了,只是给它加点动的成份(运行时),没有"改成动态"这么严重吧,不然太可惜了。

==============


gigix 写道:
robbin 写道:

个帖子中的annotation声明事务和XML声明事务。一个大型的应用,至少有上千个方法需要声明事务,那么annotation你就需要在代码里面
写@transaction(strategy="required") 至少上千次。而如果用XML,只需要在XML统配一次。这就是XML的优势。




那么这个配置根本就不应该出现。我是说,它就应该是一个缺省配置,只有遇到特殊情况的时候才重载它。这就是为什么Rails开发效率高过J2EE的原因。





在试RadRails,呵呵~


又是题外话,提到脚本,我了解的python和Ruby都支持元数据标记,可以参考她们的应用范围,不过,脚本语言用元数据,天然就能避免java的一些问题,如布署~。


python表达方式与java类似,是一种decorator wrapper的模式。


ruby是通过module mixin的方式(rails大量使用)表达,不过与上下文无关。


相关资料:


http://www.python.org/doc/2.4.2/whatsnew/node6.html


http://www.python.org/peps/pep-0318.html


ruby网站怎么访问不了了 Sad

=================


zkj_beyond 写道:
引用:
在source中写annotation 进行系统配置,相对于XML中配置来说,效率要高得多




其实是一样的。都需要ide,或工具的支持。如果没有好的工具,XML与annotation都让人疼痛。





我姑且认为annotation是OO角度,xml是AO角度,这两个视角我都不喜欢。


我还是想充分利用IDE,假如有这么一种模式:


制定annotation与xml配置 双向映射 的表示标准(mapping schema?)。


在IDE编辑器中 输入annotation,显示效果跟现在一样,IDE在后台不是把这些annotation存于源码中,而是按指定的"映射规则"(mapping rule?)存到相应的配置文件中。同理,当IDE打开源文件,也会按规则查到对应的配置文件,正常显示annotation。


在定义annotation时,可以利用IDE的向导生成"映射规则"文件。


在生产环境,可以用vi直接打开配置文件修改。


annotation的service端代码,是分析xml配置文件而非利用反射机制生效。


这种情况,与使用xdoclet比较,不同的是元数据存放位置的天然脱离源代码、语法级上支持、映射标准的制定、IDE的标准制定。


这样,原先不支持annotation的库,制定它的mapping rule就可以了。


即使大家一致认为这样确实好,我想m$完成这个目标也一定比java快。


这个设想存在两个可能的问题:


1. IDE显示效果与配置文件格式差异太大,以致于如果两种方式都要查看的话,都要学习,还要熟悉其对应关系。


2. 复杂情况可能只想通过反射,不想(或不能?)通过加一层xml来做


即使这两个问题都很严重,起码这个设想作为一个可选的方案,或某个IDE以一种非标准的方式支持也好啊,呵呵~



另:AspectJ5支持含有注释的pointcut通配,找时间学习下


http://www-128.ibm.com/developerworks/cn/java/j-aoplib/

前几天开始做某个项目,看到流畅的原型为了编码的需要被改的面目全非,俺真个心疼啊。


于是反思保护web原型的问题,看到buaawhl老大 的讲解,不胜喜悦,俺想要的老大差不多都做好了,还外送了不少好东东。


下面是俺的观感和原先的一些想法,夹杂着独门术语,卖弄一二。


(不知何时得闲开始学习一下fastm呢)




引用:
编程即配置




关于作者对于脚本与配置的论述十分认同,附一点对xml的漏述:xml可以反向解析,脚本就十分难了。比如我想做个可视化的配置界面,如果配置信息是脚本实现的,大概只能单向生成配置脚本了(用velocity一类很容易)。




3.页面资源



映射Css、JavaScript文件类型,对于它们的链接,参考zope,即:相对路径下找不到,就到上一级目录,直至context根。实现页面外部资源查找的面向对象方式。


应用场景:


在context根目录放置全局`默认`css,对要定制的子web模块,在相应目录建立同名文件即可实现css定制。


引用:
Zope Object Publishing




这个是不是我前面的说的?Zope Object Publishing没看过



引用:
后面的关于Web各层开发的论述,主要就按照这个“应对复杂、让复杂更简单”的思路展开。




引用:
设计思路也是同时应对简单和复杂




引用:
级列设计思想




目标:简单的方案应对简单的需求,完善的方案应对复杂的需求。即遇简则简,遇繁则繁。


方式:方案的`默认`实现应对简单,开放的架构应对复杂。


重在`三态`中`默认`态的实现。



4.页面模板层



引用:
这一层也是著名的脏乱差楼层。




严重同意!



包括三个内容:


1. 模板(页面模板、UI组件装饰器):sitemesh起作用的地方。


2. UI组件(通用组件、数据敏感组件):有人称之为macro的东东,服务器端与客户端统一模板,可以注册服务器端事件。


引用:
如果完全避免Server Side Template Engine,那么所有的包含动态部分的页面装载(URL变化、刷新等),都需要和服务器进行两次通信。




UI组件的服务器端事件激活时,引起一次客户端请求(当然也可以是ajax型请求)。对于UI组件的服务器端初始化事件,考虑无通信消耗的优化。


引用:
Nihongye说


衡量值得组件化的ui结构 then make it.




3. 控制逻辑(分页、循环项、分支)



欣赏的实现方式:


页面`元数据`:页面标签的自定义属性(类tapestry、zope page template),标记数据源名、UI类别,可以包含简单的逻辑代码(Ognl的应用)。



(X)HTML DOM在服务器端解析及改动带来的便利:


引用:
Dlee写道:


同样,我从来也不喜欢在服务器端处理 HTML DOM 的解决方案,例如 XMLC、Echo 等等。




not so bad。除却服务器端DOM的执行效率问题,其可带来的价值是可观的(这方面的常见应用还是太少了)。


一般思路是用个FilterServlet解析返回的原始(X)HTML,对可见的DOM注入页面模板、UI组件(及其模板、数据),执行针对DOM的控制逻辑。


可能的应用场景:


1. 避免二次提交:向form标签内自动注入hidden域存放令牌


2. url修饰:有些状态往往需要在用户操作流的连续页面内传递(`page flow`),如公文的ID号,放在session中既占资源,又不符合需要(假想用户登录一次,打开两个浏览器窗口处理不同的公文)


3. model属性值自动注入页面



引用:
我现在主要在这个方面下功夫。比如,提供了类似于OGNL的支持,为了大数据量情况下节省空间,提供了Iterator,ResultSet的支持,等。


你说的那些功能,都可以在fastm的外围API做。fastm也提供了类似于SAX
Callback的机制,是一个IValueInterceptor, 匹配引擎每处理一个fastm template DOM
Node的时候,都会调用这个IValueInterceptor。

特殊的需求,可以在这个IValueInterceptor里面实现。


比如,可以专门定义一个 FuncInterceptor处理{call.a.func(c, d)} 这样的东西。可以专门定义一个 FormatInterceptor处理{a.date@yyyy-mm-dd} 这样的格式处理。


其实,fastm的这种格式处理可以非常强大,可以根据 对象属性的名字、类型、值等,进行各种处理。


比如,beginDay, endDay, 就显示 yyyy-mm-dd; beginDay, endDay, 就显示 yyyy-mm;
beginYear, endYear就显示 yyyy; beginTime, endTime 就显示 yyyy-mm-dd hh:mi:ss.
等。



这个我称为显示逻辑AOP。


fastm支持对象图。类似于OGNL。POJO可以直接在template中引用。





我们是不是可以称之为页面生成上的AOP和IoC 


如果逻辑比较复杂,可以用服务器端脚本作为datamodel和DOM的粘合剂,保持对复杂的适应。例如:覆写默认行为,复杂表现逻辑。


同样,`默认`是如果存在脚本,则用脚本粘合,否则是默认粘合。


默认行为的制定参考css查找规则。



以上方案试图力保原始(x)html的纯洁性,保证`原型友好`,理想状态是这样的:


在没有应用服务器的情况下,原型是最新的可以展示的版本,对用户和美工都是友好的。


放在应用服务器下,它就是一个跑得很好的完整应用。



达到这个理想虽然很难,但我们可以逼近。


原型页面和普通的应用一点大的不同是link和form
action的指向,往往改成了*.jsp,*.do等对原型不友好的形象。是不是可以保留原型中的原始htm链接,用个Servlet映射*.htm,
接管客户端请求,并以默认规则确认action名称,构建实例,并自动根据request参数初始化属性(差不多就是XWork)。



这里,`默认`要forward到的view就是用户请求的html。



表单验证也可以用`页面元数据`表达,最终可被server-side DOM(服务器端脚本验证器)转译处理和client-side DOM parser(javascript验证库)处理。如果server-side验证不通过,`默认`forward到原页面。



引用:
fastm的完全“推”模式的优势就体现在 HTML和Code可以完全剥离。





暗合,呵呵~


后面还有:



引用:
fastm的DOM分为两个部分,Template DOM is Read Only, shared among all theread.





引用:
关于Ajax(XMLHttp),我的意见是必要时才用,而且最好采用粗粒度的用法 — JavaScript发出一个URL请求,返回一整段HTML,直接替换到页面的某一块,而不是用JavaScript来做这样的把数据填充到HTML DOM中。




十分同意!


称之为`提交form到某html UI`,很爽的样子。



7.O/R



引用:
A a = new A();


IMapper aMapper = MapperService.getMapper(A.class);


While(rs.next()){


aMapper.populate(a, rs);


businessLogic(a);


}




超级不赖的lightweight o/r切入,学习ing!


用反射就行了,性能不会太大吧~(或者两种实现,开发时和布署时两套方案?反正开发时不爽就是不叫俺爽~)



Pager



引用:
Canonical说


到底是预先把所有变量都计算出来,还是将计算时刻延迟到执行的时刻(采用lazy evaluation其实是function programming最擅长的)。


我想fastm强调页面中没有复杂逻辑是正确的方向,但是也不必绝对排斥在页面中调用函数。


支持对象图或者对象函数调用的一个额外好处是可以需要命名的变量数,即减少需要创造的概念数,在对象数比较多的复杂情况下还是有用的。





引用:
这些URL是分段的。每一段代表 一级子模块。后面的段属于前面的段。

Lightweb是这么定义的。除了最后一级,前面的各级子模块,都对应一个 Channnel
(其实就是Dispatcher);最后一级子模块,可以对应 Channel (Dispatcher), Controller
(类似于SpringMVC的Controller), Action(类似于WebWork的Action)等三种编程模型。





是不是说:Channel是模块级(module),Controller是实体级(action instance),Action是方法级(action method)?



对于WW2的Action,每种请求对应一个Action(的execute方法)。


是不是有面向Entity(pojo)的,像ruby on rails,把Entity类的某些方法暴露出来,作为http请求的目标。(暴露的粒度,模板的适用对象)


是不是也有Entity类的`默认`模板(比如实例属性、对应方法的参数自动转成html form表单或link参数,一个Entity类提供CRUD四个模板页面),可以针对某Entity类定制模板,并提供override模板某部份的能力?



=========
buaawhl老大的回复:

多谢liusong1111的深入分析探讨。


前面的 Ajax, Form Post等意见都很好,是有益的补充。我现在的框架中,主要针对 Stateless Link。



关于Lightor 的那段特殊用法里面,为什么不用Reflection.


因为那段特殊用法是用来处理 Long Transaction的。也许有几十万条记录批量处理。那节省的时间就很多了。



liusong1111 写道:

引用:
这些URL是分段的。每一段代表 一级子模块。后面的段属于前面的段。


Lightweb是这么定义的。除了最后一级,前面的各级子模块,都对应一个 Channnel
(其实就是Dispatcher);最后一级子模块,可以对应 Channel (Dispatcher), Controller
(类似于SpringMVC的Controller), Action(类似于WebWork的Action)等三种编程模型。





是不是说:Channel是模块级(module),Controller是实体级(action instance),Action是方法级(action method)?






对. 可以这么说。Smile


也可以说,Channel 是 Dispatcher, Controller, Action 是 Service。



liusong1111 写道:


对于WW2的Action,每种请求对应一个Action(的execute方法)。


是不是有面向Entity(pojo)的,像ruby on rails,把Entity类的某些方法暴露出来,作为http请求的目标。(暴露的粒度,模板的适用对象)


是不是也有Entity类的`默认`模板(比如实例属性、对应方法的参数自动转成html form表单或link参数,一个Entity类提供CRUD四个模板页面),可以针对某Entity类定制模板,并提供override模板某部份的能力?





Lightweb 主要暴露Service,不暴露Entity. Smile


暴露的最低级别就是WebWork的Action 级别了。


CRUD还是需要自己包装。

借宝地俺对server side也YY一下:


server side css,


server side script,


server side include,


server side component(server side tag,server side annotation,server side event,server side property)


server side template,


server side html dom parser,


server side data binding,


server side logic/data injection,


server side state transfer,


server side continuation……

语法上咋是"怪怪的"呢,我感觉"便捷一致"啊 Very Happy


C#3.0新特性概览:


http://www.lanhai.net/NEW/ShowArticle.asp?ArticleID=2644



C#3.0的这些特性看得爽不?


除了"LINQ查询表达式"是m$自己的(?),"扩展方法"特性是取自groovy的(还不如ruby的mixin呢,算作静态类型的妥协吧),"表达式树"俺没看明白,其它的都取自ruby的语法(又是一大堆糖啊)


也印证了以前的想法,动态语言的许多语法特性都不是因为动态而独有的,C#3.0大肆利用ajoo以前提过的type inference让编译器在字节码生成技术上大作文章。


在我狭窄的视野看来,ruby都算引领了语法的方向,学习它是物有所值的。



C#3.0的这个语法特性,哪位朋友给俺讲解一下?


引用:
表达式树



  C#
3.0包含了一个新类型,允许表达式能够当作运行时的数据使用。这个类型,System.Expressions.Expression<
T>,只是一个内存中一个lambda表达式的重新表达。结果是你的代码可以在运行时修改和检查Lambda表达式。



  如下是一个表达式树的例子:



Expression<DemoDelegate> filter = () => Console.WriteLine("Hiya!!") ;



  使用如上的表达式树的方法,你可以使用过滤器变量中的各种属性来检查树的内容。





不知道java语法在C#3.0冲击下会有什么改变,光是java5.0在对比下就倍受谴责了。俺挺喜欢鼓捣语法上的东东,引用庄表伟老大的话:语法是强化的框架,框架是弱化的语法,信然~