Thanks a lot for responding so quickly Brian. I'll definitely read up on that. I started in my head with a factory, then I went to "bean factory", then I went to coldspring, then I thought about the whole "if i can have default components and override them with coldspring" thing might work, if it works.
to your first question, no, each database does not have its own service, dao, etc. In the ideal state the database would always be in synch, schema-wise, and this monkey business wouldn't be necessary at all. I'm just putting some lipstick on the pig i've been handed by making it flexible enough to deal with the scenarios when the schemas do change somewhat. So 95% of the time, all databases would be fronted by the "default" components. It's that 5% of the time when i need custom read/save/display behavior that I'm trying to contend with. With the renderer components, do you have any examples? I guess really what I'm wondering is how far to go with it. I don't necessarily want to have separate renders that redo the entire form when all that changes is how to render a single field on the form. so are you advocating a renderer that handles things at the field level? Also, sorry for the lame subject of this message. I had started it, went down to type the email, hit send, and forgot to finish the subject. i couldn't find a way to edit it, so I'm stuck with it. My bad. again, thanks. marc On Wed, Jul 2, 2008 at 8:40 AM, Brian Kotek <[EMAIL PROTECTED]> wrote: > I'm still a bit confused about how you are doing this in a single > application, and if each separate database has its own service, dao, etc., > but you should be able to do this via ColdSpring assuming you have separate > components for each database variation. Simply define the different kinds of > beans and then wire in the proper DAO to the proper service. Alternatively, > you can look at ColdSpring's factory beans, which allow you to specify a > method on a CFC that returns instances of CFCs. > > For your dynamic rendering, it sounds like you probably want to create > multiple renderer components for a given domain object and then allow the > domain objects to render themselves using whichever version of the renderer > that was passed into it. > > Essentially, both of these are implementations of the Abstract Factory > design pattern, BTW (http://en.wikipedia.org/wiki/Abstract_factory_pattern). > > > On Wed, Jul 2, 2008 at 7:27 AM, Marc Esher <[EMAIL PROTECTED]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
