只显示主题贴

2008-08-04
全文显示

回复: OGNL & ValueStack 入门

引用 很好的文章，希望LZ继续进行OGNL 的语法讲解。 谢谢各位的鼓励！ ognl的语法是很简单和简洁的，个人感觉看ognl的官方文档应该就足够了，自己要再写文章讲解也多半是重复照抄，没多大意思，呵呵。
  • 进入论坛 Java 版
2008-08-04
全文显示

回复: javaeye上的牛人，这样的简历,有谁在深圳能引荐一下？

我认为对新人的宽容和培养的态度，是每一个有经验的前辈程序员所应具有的责任。否则何谈中国程序员的崛起！我们部门也进来了一批新人，有人基础好，有人基础差，虽然象楼主这样优秀的人不多，但我相信一定会有，否则我们只能为中国的大学IT教育而深深悲哀，象楼主这样肯学、好学、而且对计算机有热情的人正让我看到希望。本不想说什么，但看到那么多怀疑的论调，还是忍不住要进来为楼主加油，相信自己，认准方向，只要你有热情，你肯定能做好！
2008-08-03
全文显示

OGNL & ValueStack 入门

h1. 一个例子 请看下面的需求，假设有如下用户对象模型： public interface User { public String getName(); public Date getRegisterDate(); public Customer getCustomer(); } public interface Customer { public String getId(); public String getName(); public boolean isVip(); } public interface En ...
  • 进入论坛 Java 版
2008-07-24
全文显示

回复: EOS/普元：中国IT业的悲哀

以我们现在对EOS的了解，开发EOS主要包括以下几部分工作： 1、EOS的解释引擎，也就是EOS Server：这部分主要就是要写一个解释器，实现对EOSStudio 所生成的XML流程的解释执行。一般来讲写一个解释还是有一定难度的，特别是要把解释做好，可能不是那么容易。但从我们上面对EOS的语法分析来看，这个解释要解释的语法实在太简单了，因此我认为这部分工作没有任何难度（当然可能有一定工作量），甚至比ajoo写的jaskell都要简单得多。 2、EOS Studio，也就是基于Eclipse的IDE：这部分是EOS的重中之重，所谓可视化开发全部要仰赖IDE实现。这部分的工作量要比EOS Se ...
2008-07-18
全文显示

回复: 网上银行的安全操作设计探讨

1、据了解，动态口令采用的就是楼主说的第2种机制，所以动态口令发生器会有一个容错时间。 2、目前通讯层和服务端安全方案都已非常成熟了，网上银行最大的安全弱点在客户端，所以网银的安全性其实是由使用者本人决定的。
2008-07-14
全文显示

回复: EOS/普元：中国IT业的悲哀

javatar 写道jxb8901讲的很多设计上的问题, 确实存在, 我也使用过一段时间的EOS, 讲一些实实在在的问题: 性能很成问题, 机子要好点才行, 有同事甚至直接在服务器上修改页面, 因为项目大了后, 本机测试太慢, 受不了, 而只有服务器的高配置才行. 只有过程重用, 丧失面象对象的所有特性, 一个图形不能继承于另一个图形, 或覆写某个图形节点. 图形节点的粒度太细, 一个功能通常需要很多节点来完成, 最后都是蜘蛛网, 无法维护. 图形节点稍多，并且有节点环时，格式化图形(蜘蛛网), IDE就挂了． 对基本类型数据处理非常不方便, 如: 加法, 先用一图形节点设置原始值，再用一个图 ...
2008-07-09
全文显示

回复: EOS/普元：中国IT业的悲哀

银狐999 写道首先，我很理解你的抱怨。毕竟我也是一个狂热的技术爱好者和钻研者。 你的意思是“狂热的技术爱好者和钻研者”就一定会对EOS有所抱怨？或者你所接触的“狂热的技术爱好者和钻研者”都对EOS有所抱怨？如果是这样，那么一家视技术为生命的企业是否应该考虑这种现象为什么会出现，为什么自己的产品不能得到“狂热的技术爱好者和钻研者”的认可？而不是自以为是的以“业务才是最重要的”这样的话来自欺欺人。 另外，我本人还算不上你所说的“狂热”，看来抱怨EOS的人大有人在，至少这是值得深思的。 银狐999 写道不过，说句实在话：你们公司选择Primeton EOS这是明智的选择，而不仅仅只是所谓的“商业 ...
2008-07-02
全文显示

回复: EOS/普元：中国IT业的悲哀

惊鸿逝水 写道如果能总结出什么功能是EOS不能实现的、绝对致命性的问题列表，那才好呀！ 省的被忽悠也没办法反驳，列举一些名词对比，对领导层不会有什么震撼力，起不了决定性作用。 还是从语言层面来看，仅仅具备基本语法元素的EOS（这里是指图形化的EOS）可能有很多功能都不能实现，但不要忘了EOS的宿主语言--java语言，有什么功能是java语言所不能实现的呢？因此从EOS的角度来看，如果有什么功能是图形化所无法解决的，那也没关系，因为可以在java中实现，然后再封装成“运算逻辑”，这样就等于无限扩充了EOS，所以从这个角度来说，只要java能实现的功能，EOS就能实现。 但我们将EOS做为一 ...
2008-07-02
全文显示

回复: EOS/普元：中国IT业的悲哀

正如robbin在2005-12-09时说的http://www.javaeye.com/topic/17295： robbin 写道前几天倒是有幸和普元的老总吃饭聊天，听他介绍的情况，EOS主要还是卖给大公司客户，不走中小企业路线。对于那些大企业客户，EOS销售业绩增长很快。对于那些大公司客户，是直接和老板去谈的，老板认可了，自上而下的推，底下程序员的意见是没有用的。而EOS本身也确实不是废物，在某些问题领域，确实很有效，所以有老板认可。 姑且不论EOS好坏，这个大客户的市场，商业远远比技术重要的多，人家商业做得好，可以让老板认可，技术好坏是非常无关紧要的。 三年后的今天，这句话依然重 ...
2008-07-02
全文显示

EOS/普元：中国IT业的悲哀

公司引入了普元的EOS作为公司的基础架构平台，今后的所有项目将逐步向EOS的迁移，但对EOS的研究又让我不得不说出以下话： 1、EOS确实够简单，但未免简单过了头：从语言层面看EOS 因为EOS将成为我们的开发语言，所以有必要从语言的层面认识EOS。 去除EOS的图形化外衣，我们看到EOS就是一门以XML表示的类似Basic的脚本语言，这门语言相当简单，因为其语法元素极少，如下： 过程声明 <-> 构件的创建 过程调用 <-> 构件调用 条件语句 <-> 构件图中的IF结点 循环语句 <-> 构件图中的"{" 和 "}"结点 因为语法元素少，加之图形化的编程方式， ...
jxb8901
搜索本博客
最近加入圈子
存档
最新评论