On Wed, Sep 10, 2008 at 2:31 AM, Tom Chiverton wrote: > On Tuesday 09 Sep 2008, denstar wrote: >> Cool. Some fools still just stick the factory in the application scope. > > That's fine, and that's where my BeanFactory lives.
And it's probably where you store the configuration object too, since you are using CS, but you'd have to stick the configuration in the application scope as well, if you were doing it "manually". Nothing wrong with that, we'll tackle encapsulation below. >> Heh. I've touched on this before, but the main reason I was doing it >> was to get a list of objects. >> If you have to know an object name first, you have the egg/chicken problem. > > Well, if you are wanting to hook into Reactors generation mechanism, you can > do that inside the Reactor classes, which have access to the _getConfig() > method anywhere (or a local subset). Don't you still need to know a class name? As in an object name? So 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? >> For another usecase, setting the DSN on the fly, you cannot just >> change the settings in your config object (last I checked, I think), >> you need to re-initialize the factory with the new config object. > > Or you can swap the database the DSN is connected to using ServiceFactory. > Or have a 'template' reactor.xml that you replace tokens in. Niether of which are exactly "on the fly". But that doesn't matter so much other than, I was looking for something not-too-complicated, that would just plain work, basically using the reactorFactory alone. It 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 it's a non-optimal approach. :-) >> So you're juggling beans, where it sorta seems like the factory should >> let you know how it's configured (and perhaps even change it). > > I'd say this breaks encapsulation. How so? The configuration bean isn't much of an object, on it's own. It's not much of an abstraction, either. I mean, are you going to use that configuration object with, say, Transfer? And at that point, you'd want something really abstracted away from reactor, right? Reactor-specific functions wouldn't belong in it? 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! Crazy stuff, that has been really cool to work with... I mean it, it's fantastic. Generation of ORM objects on the fly, etc., etc.. >> Besides having to fork the code though, I haven't run into any >> problems by exposing the configuration... > > Yeah, to be clear - it'll work fine. So, besides forking the code, is there really any "bad" reason to have access to the config object from the factory itself? Why is it fine to have access to it from the objects themselves (which, in my opinion, is really where you /wouldn't/ want it, as that does seem to break encapsulation), why not the factory? Isn't the factory more concerned with things like the DSN than the objects are? Can one factory have more than one configuration object, perhaps? Is that how multiple DSNs are getting handled now? That might make more sense, but even so, I'm thinking the factory should grant you access to it's configuration, as, well, it's driving the train, and you have to drive your train with it. The objects are just passengers... But I'm probably not thinking this through... can you give me an example of how it breaks encapsulation having access to the config in the factory, but doesn't when done from the objects themselves? Running on not much sleep for days, so sorry if I'm being thick here. And thanks for the convo, I value your input. -- Because thought has by now been perverted into the solving of assigned problems, even what is not assigned is processed like a problem. Theodor Adorno -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [EMAIL PROTECTED] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
