I’m needing to setup some new bean properties for Lightwire in a new CB module I’m writing.
What I’d like to do is have these properties sitting with the module. The idea being that I can then import these into any CB projects that are using it.
I’ve been looking through the Docs, Plugin and Lightwire code but I can’t see a way that I can possibly add more than one xml configuration to a single factory, or get the Module to add the beans when it’s first run.
I did however find this blog by John Whish:-
Which talks about an enhancement he’d added to the original Lightwire. Can I do something similar in CB’s version?
Why not just write your own config script? The power of lightwire is that it doesn’t use XML by default. That was something that Paul Marcotte contributed (thanks Paul!). The heart of LightWire is a config script file which can load config information from code, XML, databases or third party web services based on the time of day, the phase of the moon or the average daily temperature last week in NYC. Loading multiple xml files should be fairly easy to code and should not require any changes to LightWire.
If you want to keep it separate, I would in my module create a new lightwire configuration object, with what the module needs. Then create a new instance of lightwire and then add the original parent application’s lightwire instance as the parent of the factory. This way you can retrieve parent objects if necessary through the hierarchy.
You will have to do this manually, but it is very achieavable.
I am finalizing the wirebox implementation for modules and this is an issue I am tackling by treating all modules like this. This means that every module can load up a new wirebox injector with it’s own configuration binder and will be automatically attached to the parent applications’s wirebox injector. All this will be transparent and setup already via the module configuration and by conventions.
This way, you just wire up your objects in you modules as it will have its own injector attached to its parent hierarchies.
For those interested, this is my first approach at a concept of HMVC, where you can build hierarchies in your application, with decoupled elements and modular concepts.
Ok this sounded super geeky, sorry! I am just excited.
@Peter - Thanks a lot. If anyone is going to know Lightwire I guess it’s you :-). I’ve gone with the XML convention for the reason that’s what we we’ve been trained on and what the ColdBox docs seem to promote. Also helps with the migration to ColdSpring if we ever decided to go that route, but I’m not a big fan of XML configurations myself. Prefer the coding way as well.
I can actually see the methods I need. They’re sitting in the BaseConfig.cfc, but I can’t find a way through Coldbox of gaining access to those methods. The only thing I can “grab” is the Lightwire.cfc and the IoCAdaptor. Otherwise I think I’d be well on my way to adding them in.
@Luis - I think a brain cell just popped in my head with that last one :-). Just before I posted I did see a method call in the init, I think of the Adaptor, looking for a reference to IoCParentFactory. I did a Google on it but couldnt’ find anything or in the docs. And here I am :-). Do you have any pointers of what a “typical” configuration would look like?
As for having all the stuff running on conventions for Modules that would be very cool. I really love the whole concept but implementing so far has been a bit fiddly for me. Maybe because it’s still evolving - I’m persisting with it though
Following your advice Luis I’m trying to setup a new instance of Lightwire in my module. I’m doing this in the ModuleConfig onLoad() and trying to use the example code you’ve laid out here :-
Looking at the methods on the IOC plugin though I’m not seeing a setIOCFramework() and setIOCDefinitionFile() , there’s just getters, so this code is erroring for me (ColdBox 3.0, don’t know if this code is ColdBox 2.6 (?) )
Looking at the configure() method on the plugin it looks to be coded to only use the main project configuration settings, using getSettings(), So from what I can see there doesn’t seem to be anyway I can by-pass / overwrite those settings to use my module instead.
Is there a cleaner way of doing this that I’m maybe missing? Am I barking up the wrong tree
Got it … just to share the code, in case anyone else wants to try this…
- Called when the module is activated and application has loaded
// Load in a fresh instance of Lightwire
var IOCConfigPath = controller.getSettingStructure().Modules.quickAddress.settings.ioc;
// Initialise with the modules definition file and generate the factory
var oMyIOC = createObject(‘component’,‘coldbox.system.ioc.adapters.LightWireAdapter’).init(
// Set the parent factory as the main projects ( so the module has access to all its stuff as well )
// Cache it for usage in the app, indefinatly!
As you said Luis it came down to doing it manually and working out how the plugin loaded everything in but that’s up and running and I can now call it in on
Thanks again for the help