Hi all, I've got your typical data-driven, forms-based app, all done with fairly granular components. kind of a basic bean/dao/gateway thing. The difference is that these components, rather than talking to a single database, can talk to any number of databases all of which are "supposed" to have the same db schema. So this application, then, is a front-end for managing certain data in these databases. problem is, every so often, a table or two inside one of the databases will change slightly and, for that one database, the application will break. For example, imagine a "Candy" table. and 10 of the databases' candy table has a "CandyType" column, and that column is a string (maybe the rows have "yummy chocolate", "earwax", etc. and then some smarty says "you know what, this string thing is junk, we should have a new CandyTypes table, and then this Candy table should reference it in the CandyType column instead of keeping this as string data. So that happens for one database, but the other 9 databases can't change yet.
So now my manager interface doesn't work for the newer database because A) The old query in the dao isn't joining on the new table, B) the save functionality is slightly different, and C) the form that renders the Candy interface is off.... currently, the CandyType field is just a text field, but I'd like it to be a dropdown field for this one database Because of time/resource/whatever constraints, it can take months to get all the databases consistent again as that generally happens at a pre-determined release schedule. Thus, what I'd like to do is build in adaptivity. I need a way of saying "For this here new database, instead of using the CandyDAO, we're going to use the NewCandyDAO. And in this dsp file that renders the form, we want to show the CandyType field this way instead of the normal way. And i need to be able to configure all of this at runtime. And I don't want it littered with "cfif database eq "NewerCAndyStyleDatabase", then CAndyDAO = NewCandyDAO". I want it entirely dynamic such that: 1) the objects i create are the "default" objects UNLESS there's an object for the new database that. 2) the form code can stay stable and they offload the "field rendering" to some other mechanism. I thought that I could achieve #1 via coldspring, although I've only used spring but not coldspring. basically the idea would be to load all "default" beans first and then, at runtime, include bean definitions for any custom overriding components that would override the default beans. I do not know, though, whether coldspring supports this. For #2, I've got some ideas but I'd like to hear other folks' thoughts on this first. The good answer of "do a better job of keeping the databases synched" just ain't gonna happen any time soon. In the interim, I need to simply make a more flexible system and if I have to resort to hacky if statements all over the place, then I probably just won't do it at all, i.e. i'll leave it broken. Now, as I said, the "default" functionality already exists and has been for a very long time. I'm just adding in the ability to be more adaptive. Thanks to all for your thoughts! Best, Marc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
