... > >Druid looks great. But wouldn't it be better to let users > make an ER diagram and take it from there? i.e. create db, > java classes, ojb mapping, some default forms with the right > definition and binding. Then, the "only" thing left to do is > adjust the template and you are done! :) > > > > > Unfortunately, this does not solve the problem: > > 1. In a form we can have some fields that are calculated, hence there > does not exists a corresponding DB field for it. > 2. In other situation, you don't want to use all the DB table > fields in > the form. > > IMHO, there is no a correct way to go from the DB table to the form. > More often than we though a DB table cannot be mapped to a > form due the > defined interface.
Hmm, okay. But how do you generate a database schema from a few forms? Especially if there are graph-like relationships between the entities you cannot model in a form definition. If you think about it, the form code that is generated is not more than a skeleton anyway. No application will use the exact generated code. I think it would be much easier addind these extra bits (add extra fields or remove ones you don't want to edit) by hand than trying to figure out what people meant when they were writing their forms. After all it would be "just" a code generator to cover those 80% of work you have to do anyway, it does not have to be completely correct all the time (working, yes, but not correct for the specific application). Ruby on Rails does the bare minimum of code generation also basically on top of an ER representation, yet still, they do cover enough ground to build stuff fast. I was also thinking about the views... It might be nice to have a state as to which view to show. Some actions might change this state in a state-machine-like fashion. You might also have a way to directly change the current view. This would make it much easier to translate requests to the server as actual method calls on a controller or even model object (something like /shoppingcart/addItem). After calling the method giving a hashmap of parameters or something similar, the current view would be rendered. Now, it would be especially cool to do this ajax-style and send back a document containing changes to the current view. Without ajax, you get weird urls which are not bookmarkable at all but you translate the "old" request/response model in a more appropiate action/reaction sort of thing. Now, if you define views also in terms of other views (like an eclipse perspective), this might work quite nicely. WDYT? max
