CForms and Database - 5 Degrees of Separation?

[Derek Hohls <dh...@csir.co.za>]

I understand that the "separation of concerns" offered by
Cocoon allows for parallel development on a system, through
the enforcement of appropriately defined contracts.  In
theory, this separation is meant to ensure that a system is
more flexible and more maintainable... Now the flexibility
part I will buy into, as I have seen it in operation, but
I am becoming concerned about the maintainability.

Take for instance a simple use case - using CForms with a 
persistence layer such as Hibernate to save data to a data-
base (at this stage a theoretical scenario as I have not seen
all these components working together as yet...) and now I 
need to add a new item that the user wants to see/edit...  

The following steps now seem to be required:

1. Update the database - pretty straightforward, assuming that
the new piece of data is just a new attribute on an existing
table...

2. Update the TableBean representing where that data is stored,

3. Update the persistence layer configuration file - in the 
case of Hibernate, this would be a Table.hbm.xml file,

4. Update the form binding file to link the data to the bean
(all the fb: widgets),

5. Update the form definition file (the fd: widgets), and

6. Update the form layout template file (the ft: widgets).

Whew!  All very nice and cleanly separated... but are they?  
This seems like a lot of work for what is, essentially, a
very simple change.  Forget one step, or make a single typo
and the entire cascade fails...

Does anyone have any thoughts on whether or not this process
could be simplified or, perhaps automated?   Or whether some
type of "meta config file" could be be created, where all the 
data is stored, and from which the needed files could readily
be generated?

Derek

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

RE: CForms and Database - 5 Degrees of Separation?

[Antonio Gallardo <ag...@agssa.net>]

David Leangen dijo:
>
> Sorry if this thread diverges a little from Cocoon...
>
>> Using OJB and Druid I do:
>> BTW, next version of Druid will include support for Hibernate
>
> Druid looks really interesting, but there is NO documentation...

The docs are bundled in, just look inside.
>
> No doc, no use!

It is up to you. ;-)

>
Best Regards,

Antonio Gallardo.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

RE: CForms and Database - 5 Degrees of Separation?

[David Leangen <dl...@canada.com>]

Sorry if this thread diverges a little from Cocoon...

> Using OJB and Druid I do:
> BTW, next version of Druid will include support for Hibernate

Druid looks really interesting, but there is NO documentation...


No doc, no use!


Any idea where I can get SOME info, even if it's old?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: CForms and Database - 5 Degrees of Separation?

[Antonio Gallardo <ag...@agssa.net>]

Ugo Cei dijo:
> Derek Hohls wrote:
>> The following steps now seem to be required:
>>
>> 1. Update the database - pretty straightforward, assuming that
>> the new piece of data is just a new attribute on an existing
>> table...
>>
>> 2. Update the TableBean representing where that data is stored,
>>
>> 3. Update the persistence layer configuration file - in the
>> case of Hibernate, this would be a Table.hbm.xml file,
>
> 1. Update the TableBean.java file.
>
> 2. Automatically generate the mapping file (Table.hbm.xml) from XDcoclet
> tags included in TableBean.java comments.
>
> 3. Update the database using Hibernate's tools.

Hi:

Using OJB and Druid I do:

1-Make changes on Druid (add/change/remove fields, tables, etc).
2-Run ant that automatically:

A-Automatically generates from Druid: a new SQL script, Java Beans and O/R
map (xml).
B-backups the data from the database
C-drop the current database
D-create a new database using the new SQL script and load the data again.
E-Recompile the new beans.jar
F-Copy the new bean.jar to the cocoon application and to the java handler
project.

It is a 2 step procedure. The most is done automatically, so there is no
way to make mistakes.

BTW, next version of Druid will include support for Hibernate (it is
already on the CVS). But I am not sure how well it works. The link to
druid is: http://druid.sf.net/

Best Regards,

Antonio Gallardo


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: CForms and Database - 5 Degrees of Separation?

[Ugo Cei <u....@cbim.it>]

Derek Hohls wrote:
> The following steps now seem to be required:
> 
> 1. Update the database - pretty straightforward, assuming that
> the new piece of data is just a new attribute on an existing
> table...
> 
> 2. Update the TableBean representing where that data is stored,
> 
> 3. Update the persistence layer configuration file - in the 
> case of Hibernate, this would be a Table.hbm.xml file,

1. Update the TableBean.java file.

2. Automatically generate the mapping file (Table.hbm.xml) from XDcoclet 
tags included in TableBean.java comments.

3. Update the database using Hibernate's tools.

> 4. Update the form binding file to link the data to the bean
> (all the fb: widgets),
> 
> 5. Update the form definition file (the fd: widgets), and
> 
> 6. Update the form layout template file (the ft: widgets).
> 
> Whew!  All very nice and cleanly separated... but are they?  
> This seems like a lot of work for what is, essentially, a
> very simple change.  Forget one step, or make a single typo
> and the entire cascade fails...
> 
> Does anyone have any thoughts on whether or not this process
> could be simplified or, perhaps automated?   Or whether some
> type of "meta config file" could be be created, where all the 
> data is stored, and from which the needed files could readily
> be generated?

I think that some more automation is required. Generating and keeping 
up-to-date CForms artifacts from Java sources or some other kind of 
model shouldn't be too hard, at least for simple cases. The scenario 
calls out for some "smart" tool to carry out most of the gruntwork and 
let the developers concentrate on the business logic aspects.

	Ugo


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org