Hi Sylvain: The idea is good at all. There can be 2 approach:
1) Use the database to just store the forms: - Don't care about primary keys, normalization, relations and similars. This way any database can act as a simple form repository. Forms can be "isolated islands" inside the database -You need to do all the validations at the application level. It remembers me the times where some people used FoxPro as a set of tables without any relations between them. - This can be builded using what we currently have (as many pointed before this post). For me the best approach will be: 2) At the design time: A businness oriented CASE based on the defined forms generates for you: - the required database tables with relations, etc. - the woody forms and binding - the flows to manage the application. This is my personal dream here. I know there are outthere some tools that already do that but AFAIK does not work with Cocoon. :-( We tought we can extend druid : <advertise> http://druid.sf.net </advertise> to allow people define the forms in that way we can allow people concentrate just in the form definition and the system will do the rest for us. As you noted before, non computer related people usually explain you what they need in forms. The rest of the work is ours. So if we will have a CASE that will allow us to define the form and do the rest, it will be fine, right? ;-D But this must be done at compile time. Not at run time. Best Regards, Antonio Gallardo
