Pomer：基于Flex和Java EE的信息管理系统基础框架

pomer的域名是转发的，所以地址栏的地址不会变化，不知道有什么方法可以解决

以前公司有其他同事提出想开发一个代码工具。依据表来生成一些东西。如果只是做一个在开发前生成文件的工具。那并不需要多少时间。而且对于整个软件开发过程来说，根据表创建一些文件，时间应该在5%以下。我所说的集成，是否可以考虑在消除B/S之间的耦合（B/S之间变更自动化），设计一个比较好的Client cache（客户端的缓存是FLEX开发信息系统的一个巨大优势，相对于HTML来说，他具备巨大的先天优势）...闪...

不知楼主有无思考过为什么用Flex写Web app？
如果从执行效率，设计简洁的角度， asp.net 或者Java base solution， 以及ROR， 哪一个不比Flex+Service（Remote object，webservice） 来得高效，安全。

不想说楼主走错了方向， 但举手挥刀的时候，要知道刀砍对了方向，才能达到目的。否则，不过是一个玩具而已。

有些言重了，担待。

我们公司之前的软件都是基于ajax+struts+ejb3的，后来公司高层决定全面采用flex,主要原因在于
1、flex可以做出很漂亮的东西来(公司领导使用iphone手机)。
2、flex写的代码比ajax容易维护，如果要用ajax写出跟flex一用漂亮的东西来，不是ajax做不到，而是很难维护，还考虑不同浏览器兼容问题。
3、用flex开发应用程序相当快速。
4、市场因素........

其实就是一个表现力的问题。 Flex的优势就是在于超过其他所有solution的UI 表现力。 所以某种程度上。 Adobe都放弃所谓一体化的编程方案， 我绝对相信这是举手之劳对Adobe来说。 因此使用flex开发web。重点不在如何与后台通讯。我赞同前面一位老兄说的话。 spring 对Flex的web app 来说绝对是简单问题复杂化。

大侠能明示一下吗，为什么asp.net 或者Java base solution要比flex简洁高效安全,这个结论从何而来？

Adobe都放弃所谓一体化的编程方案  一体化的编程方案这个是指什么？


同意，flex本身是前台的技术，只是提供一些rpc的方式而已，后台系统的架构与flex没什么关系，况且后台本身有成熟的系统结构。

你说的那些我们都用过，B/S技术发展到今天高效，安全所有这些技术都可以做到（否则早淘汰了），web2.0的今天，需要的超炫的用户体验和开发速度。从C++,到VB，到PB，到ASP，到java（swt,swing），jsp，再到ajax(dwr,ext),这些界面技术我们都开发了应用，用我们的实际应用说话，flex无可阻挡。

LCDS真的很恶心

首先，Pomer不是为高手准备的，它目前更多的是日常工作的积累，当前，Pomer主要做了两项工作：

其一：对想开发基于Flex的表现层Web应用初学者来说，它提供了一个现成的经实践检验的可用的kick start，当想快速看到一个效果，使用pomer，不必一开始就去学习分辨如何使用配置lcds, blazeds等remote object通信方式， 也不必去学习如果将一个pojo的java对象转换成as3 object，不必去学习flex端的mvc框架等等这些基础性、费时而于业务无关的技术。pomer提供了约定成俗的配置实现方式，这些实现方式，有些是大家都在用的，有些是改进创造的，pomer把这些很有条理的组合起来，对初学者，这些是有帮助的。

其二：任何代码生成器的意义都是在约定成俗的规则下为了节省无谓的劳动，持久层的pojo,repository，在多数系统中都已约定成俗，且多数系统都还将包括services interface和表现层框架，这些类或代码，多数系统都会出现，pomer也假定应用系统也会出现这些类或接口，所以提供了一个代码生成功能，根据数据库直接生成这些代码，包括java端的代码和flex端的mvc代码。这至少给初学者一个梗概，对帮助他了解一个可用的flex应用项目结构是有帮助的。

进一步完善后的Pomer期望Pomer之Flex犹如Grails之Groovy.......