On Thu, Sep 11, 2008 at 3:25 AM, Tom Chiverton <[EMAIL PROTECTED]> wrote: [...] >> if I want to get a list of objects from reactor, how can I do that >> using only the reactor factory? Or is there something I can call from >> the reactor factory that isn't an object, perhaps? > > You can't, you'd use a separate config object, the same one that's passed into > the Reactor factory.
We're back at the beginning, so I think we've covered all the angles. :-) >> seems to make sense to me to have the configuration for the reactor >> factory be accessible from the reactor factory. I'm not sure it >> breaks encapsulation, but this is exactly what I wanted to know. > > Why should anything outside Reactor care about the details of how (a) Reactor > is configured ? How about this: Why wouldn't the reactor factory want to know how it was configured? And be able to relay that to the outside? Otherwise you'd always need to know you were dealing with the "correct" configuration object, and you'd have to keep that "in your head" somewhere, so to speak, right? >> Reactor-specific functions wouldn't belong in it? > > Well, yes, assuming I wanted to build an ORM-indepdant data access layer, yes. > /me looks quizzical > There methods on ReactorConfig bean define an interface, yes, but it doesn't > have to be a Reactor class behind that bean... I don't think that it would be an easy swap. It's sorta an interface, but it's expecting Reactor objects, and exposes reactor-specific functionality. It's pretty tightly bound to Reactor. Which is fine by me. I'm not looking to create an ORM-agnostic config object. Just track what's been configured, where, if that makes sense. >> My thinking is, that if Hibernate does it, and does it in spades, it's >> not too bad. You should /see/ what you can do with just the hibernate >> version of the ReactorFactory! > > So wait for CF9 then... I wasn't meaning to say anything besides that it's cool, and perhaps it does break encapsulation (dunno, as it's all still reactor-specific), but if so, I'll trade that break for the usefulness. (And there's no need to wait, I'm using hibernate now, with cf8, and it's fine. Dandy, even. :] ) >> Can one factory have more than one configuration object, perhaps? Is >> that how multiple DSNs are getting handled now? That might make more > > I have a Reactor for each DSN. So if you're dealing with multiple DSNs, you'd have to juggle multiple config objects as well. So instead of having a piece of code that deals with whatever factory it is handed, you've got to have it keep track of which config it was using, correct? Basically shuttling around that config object wherever you need that "metadata"? You cannot get what factory the config belongs to from the config itself, either, so if you want to be able to create objects, you're juggling both the config AND the factory, and I don't see that config information being particularly useful beyond what the factory needs from it, ya know? There is only one config per factory, and the config object is really only useful to the factory itself.... I'm not seeing how it's better encapsulation to expose the config from the reactor factory generated objects, but not from the factory itself, basically. >> And thanks for the convo, I value your input. > > Not a prob., good to thing these things out where every(any)one can chip in. Sweet! I enjoy just rolling the stuff around, too. I'm fine with not changing Reactor, that's the project's prerogative, but I'm always trying to wrap my head around encapsulation (heh) and whatnot... so, again, gracias. Mulling over the stuff makes it clearer, somehow. -PS- Where's that rotating .sig? :-) -- History does not merely touch on language, but takes place in it. Theodor Adorno -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [EMAIL PROTECTED] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
