Sylvain Wallez wrote:
Antonio Gallardo wrote:
Max Pfingsthorn wrote:
..
Summary: "Input the form definitions and templates and let Lepido
build the whole cocoon application for you!" ;-)
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.
We can automatically produce a form library from the DB schema, and
the real form then uses that library, adding or removing fields,
providing additional validation, etc.
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.
What do you mean by "the defined interface"?
Tipical use case: User interface. Said the user table must have 5
columns. Of them, login and password, between others. The initial create
user form show all 5 columns. While the change password show only 2 of
them + the verification password field. This is a typical defined
interface. Mapping both user forms to different tables in this case is
not too smart, right? As this sample, we can find a lot of similar
samples in an db enabled application.
Best Regards,
Antonio Gallardo.
