cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Mon, 10 Oct 2005 05:48:46 GMT
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.


Mime
View raw message