cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hepabolu <>
Subject Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Sun, 16 Oct 2005 08:25:01 GMT
Antonio Gallardo wrote:

> IMHO, for normal fields, yes. Calculated fields are more often 
> transient. So, the default for them should be to not store them in the 
> database.

Reasonable, but some calculated fields need to be stored, e.g. for 
auditing reasons and to be used as a data item in itself.
An example: the calculation of BMI (body mass index = length^2/weight) 
is an excellent example of enhancing user experience, but storing it is 
necessary because it's often used in making decisions (-> audit trail) 
and because it can be used in charts (-> data item).

>                                                                - 0 -
> I know this is not the normal pattern we see in a bunch of application 
> that try to autogenerate code. And they often fail, because they are not 
> able to build a little bit more complex forms as a simple invoce. Since 
> day 1, my cocoon involvement is more related to web-enable DB 
> applications. I know cocoon is often also percieved as a publishing 
> framework. A lot of people use cocoon mostly to build CMS or websites. 
> Michael Wechner told me last year he think in cocoon are main two groups 
> (publishers [CMS-ers] and DB webapp-ers) and that this two groups 
> inevitable push in different ways. My cocoon experience involves already 
> an account system, a payroll system between others. They normally 
> involve more than 50 tables..... Maybe this is the case Michael pointed 
> out and we have different needs of what a better Db support should be. 
> While you some people is happy with few simple tables to finish the 
> application, for others it is just the beginning.

So true. I suppose I'm in the DB-webapp "camp".

Bye, Helma

View raw message