goldrain

〉〉〉你怎么不想想，如果有一个包叫com.package.A，还有一个类也叫com.package.A，怎么办，不用import static能区分吗？光看到这我就看不下去了！

理论上会有这种情况，虽然这么做不规范
我倒觉得sun应该在java规范里限制包名和类名重复，
而不是加static使语言更复杂！

我有个更复杂的想法：
map里面放值可以进一步控制类型，比如什么key只能放什么类型的value.
这么做也符合“所有能够在编译期排除的错误都没有理由留到调试的时候去发现”，是否考虑让sun把这个功能给实现了？
或许sun打算在8.0里面给实现，可悲阿可悲

>>编译当然不去能排除所以错误，但是所有能够在编译期排除的错误都没有理由留到调试的时候去发现

代价难道是增加一门语言的复杂度？
现在的动态类型语言如python连变量的类型都不用定义了，
而且还不是一样那么多的追随者，一样做大型的项目，
甚至很多人都已经开始怀疑我们到底要强类型还是弱类型，
要编译语言还是脚本语言了。java却一意孤行，在复杂的道路上越走越远...这么发展下去，再出个java6.0,7.0,不知到又会增加怎样的功能，但结果是显然的:java将越来越复杂！
语言究竟要简单还是要复杂？没有泛型前的我们真的很需要泛型么？

java语言该认真反省了
支持静态编译但要简单易用
要被接受就要向简单演化
而不是在复杂的道路上越走越远！
看看python等动态类型语言为什么这么受欢迎吧

***
每个完整的业务操作都是：ui+process
对应后台则实现两个service:ui service+process service

概念上要分开，应用中可以灵活些，比如：service层可以互相调用构成一个较复杂的ui+get map一次输出.

构造交互界面的几种数据：
1.ui数据如：下拉列表等
2.业务数据：
辅数据如:
对主记录及几条子记录要维护的话，就需要先查询出要维护的记录来；而辅数据认为是不做修改只做显示的数据；
主数据：
界面可以提交以修改的数据。

辅数据和ui数据其实只是用来构造交互框架的，分离好还是放到一起好？
以query为例，查询出的条目为辅数据，和查询条件ui还是分离比较好。单独用service实现。

规范：对所有xmlhttp为post，对所有非xmlhttp提交为get方式。

看了params拦截器的实现，要实现xmlhttp提交的参数到action属性，可以重用这个params拦截。在它之前先把xml带过来的参数放进：ActionContext.getContext().parameters;即可，真是简单阿。

xmlhttp带来的主要好处就是不用考虑提交不成功后的数据保持问题了。

交互方式暂定为：
post操作成功则返回信息进session供界面调用，不要弹出框了，同时刷界面；
post数据校验错误则返回出错，弹出框显示报错信息。