je专家挺多，想多请教一下

谢谢捧场。je上都是技术人员，说话也率直，我喜欢。

不过我还不懂怎么投票，下次有机会慢慢摸索了。

我做技术其实都是凭兴趣在做，做这种开发工具也主要想着是自己用，而不是说拿去卖。当然中国目前还不适合培养这种市场。

不过闭门造车，我发现并不是一个好注意，je上虽然说语气都比较冲一些，但毕竟大家都只是探讨技术，无所谓。最怕有些公司的人，以为自己的产品才天下第一，带有刻意的感情色彩。

我也要把我以前做的一些东西，整理一下，慢慢拿出来探讨。不过发现当真的要拿出来的时候，总感觉有点像丑媳妇不敢见公婆一样，好像还欠缺什么，只能慢慢来了。

再做好一些，不要显得太落伍了，被大家笑话。

经理主管也用的多，不过 Read 比较多而已， 秘书文员当然是 Write 比较多了

活活， 我现在正在做呢， 基于 Web 的。 我写了个替代 SSH 的东东叫 Nutz， 现在正在它的基础上构建开发界面等东东 

路过，乱入一下 =v=

.NET上有前途不明的Groovy DLR。

98~99年的时候，我在做一个叫做Info Developer的东西，是用VB写的。也算是一个IDE吧。

生成的代码，跑在同事自己用Java写的一个脚本解释引擎上。（当时还没有JSP）

当时就感觉，最难的，就是代码的生成与解析。还有就是数据库访问的编写。（当时是模仿Foxpro的数据库设计器与查询设计器的风格）。

很多年都没有做这方面的东西了，现在想来，最难的，还是把简单的部分与复杂的部分合理的分开。

简单的东西，客户能填，能操作的，是一类。
复杂的东西，你开发工具做得再好，也是复杂的。

至于DSL，我并不看好，对于客户来说，满屏幕的字符，他就已经晕了。我更建议的是可视化的设计，或者是填表式的东西。

如果一个二次开发任务，用可视化设计 and  填表都不能解决，那么这个任务也根本不可能交给客户去完成，还是自己编程快一些。

很高兴能认识这么多志同道合的朋友。我们可以交流交流，我想碰到的问题应该都差不多。

实话实说，我没有下载你的东西来研究，我只看你的介绍。

我觉得你这个产品首先定位是给开发人员用的，是属于一个框架。另外你抓住了java项目存在的一个问题，不够简单。SSH不是说不好，但是对于一个对他研究不是很深入的人来说，还是显得太复杂了。至少这么多的配置和文件，对于一个对其不太熟的人，会晕掉。

另外SSH采用分层的技术，本来是为了解决耦合性的问题。是为了业务逻辑可以分离出来，更利于管理。但是这种过多的分层却使得对于结构的变化，无能为力。

比如一个类的属性发生变化，或者类某个方法的参数发生变化，返回发生变化。就会涉及到接口的变化，这样基本上什么地方都要改。而过多的分层导致，改动的面非常广，最终也使得改动工作量很大。

你希望搞一个轻量级的框架，我想你提供轻量级的框架的目的，就是希望使用的时候简单，生成的代码少，并且改动的地方少。这我觉得应该是轻量级框架需要把握的。

就像我们为什么用ruby、php来实现系统，发现非常的敏捷，除了其语法简单之外，关键还是他没有那么多层次，那么多的代码。所有的东西都写在一些，当然容易修改了。

所以我想你的轻量级框架，能抓住这些才是重点。保留SSH分层这样易扩展这样的特性，有具有敏捷语言的这些特质。这是我觉得真正使用的。

不要说我对你品头论足，不当之处请见谅。

非常感谢，我去研究一下看。

你可以把框架抽象一下形成几种模式, 例如 rails 的MVC, 你必须按它的规则, 它的结构写代码, 这个结构就类似填表的东西.

但它模式归纳的好,虽然为规则所限, 也能实现所有的需求.

至于这个: funnywiser 写道

确实目前做这类问题有个矛盾，就是如果你太简单了，就很难满足各式各样的需求。但如果你的功能很强，却会使易用性得到很大的限制。最终搞得又像一门新的语言。

不妨考虑一个插件的模式, 例如你有很丰富的插件实现界面, 就可以用配置生成

  grid :dataset => dataset 就可以生成表格

如果有满足不了的界面需求, 就必须开发新的插件

这样就把开发的层次给划分了, 有配置式的, 有二次开发性质的, 最终的目的是以最简化的配置实现通用需求,  但也能够优雅的扩展,实现未知需求

98年就开始做了，高手啊。

不过当时做的时候，还有很多限制。比如那是java还不够完善，另外能够参考和学习的东西也太少。而现在却好很多，有很多的开源代码可以参考，有很多的成品也可以参考，还有就是碰到问题直接可以google到。书籍也很多。

制作开发平台是我们这些开发人员的兴趣所在，我想每个追求技术的人，都会去做一些小工具，来提高自己的工作效率。这些工具如果能做的全面，融合在一起，就是一套软件工具了。我很喜欢这些工作，当然现实的环境，可能造成我们没有那么顺利。工作压力，生活压力、以及对社会的无奈等等，会使我们没有时间，也会让我们对很多东西失去兴趣，也就失去了激情。因此我们也就没有精力去做自己喜欢的事情了。

你说的将简单和复杂的分开，我觉得你说到了做这类产品的重点。就是说这类产品本来就是想把问题简单化，简便化。但是有些需求的复杂，却造成你简单的实现很难去满足。

这就会产生一个矛盾，是增强本身工具的功能来满足这些功能，还是通过其他的方式来解决。

我还是倾向于后一种，就工具来说，我就只能做这些简单的工作，并且这些简单工作我是可以做到最好的。其他复杂的，就做这种接口等来进行融合了。

说这么多，让人会感觉在纸上谈兵。现在确实是在纸上谈兵，要具体的话，就只能就某个点的实现展开才行。

你说的这种rails的MVC模式是基于编码方式来说的，对于一个快速开发的工具来说，对于大部分需求是不鼓励编码的。只有少部分复杂的需求，采用编码的方式来解决。然后才通过约定的接口来融合。因此我觉得你提的采用插件的方式来实现，复杂的编码实现和简单的配置实现融合是一个很好的想法。

但你知道，现在软件都是分前端和后端的。前端Ajax、后端java，这两种的实现特点是完全不一样的。前端侧重展现，后端侧重逻辑和存储。

因此你的说的这个插件模式，可能主要适合于前端展现。就是制作一些公共组件，然后通过标记等形式来实现插入。

不知道我理解的是否正确。其实我觉得我们可以探讨一下，在当前我们见过的工具中，什么工具，其前端的灵活配置做的是最好的。还有那些不足。这样可能更具体些。