function afterConfigurationLoad () {
writedump(var=this,label="this");
try {
var adminService = controller.getWireBox().getInstance('AdminService@admin');
adminService.activate();
}
catch (any e) {
writedump(var=e,label="catch") ;
}
writedump(var=application,label="application")
writedump(var=variables,label="variables",abort="true");
}
On Tuesday, February 7, 2012 at 9:47 AM, Stephen Moretti wrote:
Hi,I don't know if this a bug or expected behaviour or what.... But it looks like the module life cycle in ColdBox 3.1 isn't quite as documented.ColdBox Version : 3.1Background:I want each module in an application to register some data at the point at which it loads, so that another module can tap into this data at a later date.This data is relatively static, but not static enough just to write it out somewhere and forget about it. Its can be changed in the life time of the application, but don't want to have to reload the entire application when one small element is changed. It would be too arduous for the client module to go and request the information from each module when it needs it. The data can't be stored in a database, because some processing is required to build the data and so on.Anyway, having gone through all the options this is the way that we wanted to go:
- Each module has a method in one of its services that builds the data and registers it.
- onLoad in ModuleConfig.cfc calls this service method when the module loads (http://wiki.coldbox.org/wiki/Modules.cfm#Interceptor_Methods:_onLoad().2C_onUnLoad().2C_etc)
Problem we had :
- controller.getModel() doesn't work - you have to use controller.getWireBox().getInstance("SERVICENAME") (the above onLoad documentation could do with a tweak)
Problem we've got:
- Every service has at least one WireBox dependancy, onLoad throws an error sorting out the dependencies through the stack of inter-related services.
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
On Feb 7, 2012 6:31 PM, "Luis Majano" <lma...@gmail.com> wrote:
>
> Answers below:
>
Ditto.
>
> On Tuesday, February 7, 2012 at 9:47 AM, Stephen Moretti wrote:
>>
>> Hi,
>>
>> I don't know if this a bug or expected behaviour or what.... But it looks like the module life cycle in ColdBox 3.1 isn't quite as documented.
>>
>> ColdBox Version : 3.1
>>
>> Background:
>> I want each module in an application to register some data at the point at which it loads, so that another module can tap into this data at a later date.
>> This data is relatively static, but not static enough just to write it out somewhere and forget about it. Its can be changed in the life time of the application, but don't want to have to reload the entire application when one small element is changed. It would be too arduous for the client module to go and request the information from each module when it needs it. The data can't be stored in a database, because some processing is required to build the data and so on.
>>
>> Anyway, having gone through all the options this is the way that we wanted to go:
>> Each module has a method in one of its services that builds the data and registers it.
>> onLoad in ModuleConfig.cfc calls this service method when the module loads (http://wiki.coldbox.org/wiki/Modules.cfm#Interceptor_Methods:_onLoad().2C_onUnLoad().2C_etc)
>> Problem we had :
>> controller.getModel() doesn't work - you have to use controller.getWireBox().getInstance("SERVICENAME") (the above onLoad documentation could do with a tweak)
>
> Was this in the documentation? If so, the docs are wrong, controller.getModel() does not exist. The latter is correct.
>
Yes it is. It's under the onload/onUnload documentation link shown above.
>>
>> Problem we've got:
>> Every service has at least one WireBox dependancy, onLoad throws an error sorting out the dependencies through the stack of inter-related services.
>
> This has been an issue and resolved in ColdBox 3.5 in the development branch. You are absolutely right, if you used some plugins or interceptors for dependencies, the chicken and the egg issue would arise. Very pesky to discover and incredibly hard to solve, but now we have a working solution in our development branch and ready for Release Candidate in 2 weeks.
Marvellous! I'm glad I'm not going loopy.
Hopefully, documenting this here will help anyone else on 3.1 avoid this unfortunate pit fall.
Thanks Luis. I look forward to the release of 3.5
Stephen