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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
