Jim,
The simple answer is yes, treat it like anything else OOP. Which means basically you create your handler, extend the component you want and over ride the methods that you want. Be warned though, this means that it will only apply to that module. Which is not a big issue because, because anything that falls outside that rule should be core or global anyway.
Regards,
Andrew Scott
WebSite: http://www.andyscott.id.au/
Google+: http://plus.google.com/113032480415921517411
Thanks Andrew…that builds my confidence that I’m on the right track at least. I am new to Coldbox, so forgive me if I miss something obvious.
The global module is located outside of my parent app, so I have a mapping to its location in the parent app’s Application.cfc. I also set the cfclocation to the model folder in the module too. With these configurations the module is working as expected. What isn’t working are the places I have extended or attempted to override certain methods. There are no errors, the code simply isn’t running after a framework reinit (I’ve even restarted the CF server).
When I extend the handler in the parent app, I use the mappingName.model.Service as the path.
I assume the routes should go unchanged, as they are set within the module and working.
I have tried to use the same package and cfc names as the module and I have tried different unmatching names.
Based on what I have described, is there something I have missed? Is some additional configuration needed besides the extends on the component?
Thanks,
Jim Pickering
There are a couple of things that I would like to ask, because it isn’t very clear.
When you say access with the mapping, are you talking about in the extends? I think that the mapping won’t come into play here, because that would affect the path, which I would expect should throw an error. Which could be being caught by you onError in Application.cfc but that is a guess.
Routes should go unchanged, but when you say it appears to not be working, I am almost inclined to think that you are still using the old routes, and not the modules routes.
If I am hearing you right, what I think is happening is that you are expecting the event handler to run the module handler first, which is not what will happen.
Now I have been talking to Luis, because one of the things that I have been trying to do is find an easier way to do this. I am close but still need Luis to give an example on how I might achieve this. But the idea is that you define your models and such with DSL names, then one can write an interceptor and replace the new handler/module/plugin and everything else with ease. This would mean that once you decide what you want to override, then no code gets changed because the DSL by name will be tricked into thinking it is retrieving the older handler/module/plugin etc.
I haven’t heard back on whether that is possible at the moment, as it appears to be, but I have not had success in getting this to be a solution.
Anyway that doesn’t help you right now, so if you can provide an example, nothing detailed on what you’re currently doing, but an example on how you are extending the handler for instance and how you are then calling then calling this.
That would help a lot more.
Regards,
Andrew Scott
WebSite: http://www.andyscott.id.au/
Google+: http://plus.google.com/113032480415921517411
I will stick to the handler cfc example. So yes, I am talking about using the mappingName.handlers.CustomHandlerCFCName in the extends of the handler cfc in the parent app. The mappingName is defined in the parent app’s Application.cfc like:
this.mappings[ “/mappingname” ] etc. The CustomHandlerCFCName is the name of my custom handler cfc in the parent app. I have tried to name the handler cfc in the parent app the same as in the module, and I have tried to change its name; neither way mattered so far.
The original handler cfc is in the global module outside of the parent app, and I want to extend it within the parent app. As I said the module is working - it is a security module, it does its job - I merely want to add further customization’s to it from the parent app. And specifically at this point, I want to extend one handler cfc (adding additional new methods to it), and I want to override an existing method in a Service cfc in the Model folder of the module with a custom Service cfc in the parent app.
I have no error handling in place to catch errors. There are no errors with the extends configured the way I described. But the Coldbox app just doesn’t see any of my customizations. When I login, the customized code should fire and run, but I get nothing. Instead the default event fires.
As far as routes, the parent apps routes are unchanged, as well as the modules routes, unchanged. I was wondering if I needed to have additional routes defined for my customized handler cfc or not. But I thought I did not, because I need the route to fire as it is configured, I just have additional code I want it to execute.
Your idea sounds intriguing. I understand the parent app loads first, then the module. I am wondering then, if the concept of extending or overriding methods in modules from within the parent app, isn’t quite fully baked yet?
Thanks,
Jim
Ok,
I am beginning to understand what you trying to do, ok lets move away from the notion of parent and child for a minute. As I want to redirect your attention over to interception points.
The reason I bring this up, is because you can define them, and use them to do just what you’re looking at doing.
http://www.andyscott.id.au/blog/using-interceptors-in-coldbox-for-greater-scalabaility
Is just one of the posts I have done on interceptors.
Anyway what I would do is in your handlers, write the basics of what you want to do. And use the interceptor to then do further processing via that and each module added to the system.
As an example, lets say the basic would be to validate the username and password. Then by just adding an announce event right after the validation you could then hook into this with a logging module, or later on done the track an auditing module.
I think if you think about it like that, or from that view point you just may find that this is scalable quicker and easier than your other approach.
Regards,
Andrew Scott
WebSite: http://www.andyscott.id.au/
Google+: http://plus.google.com/113032480415921517411
Ok the interceptor idea is intriguing. However your examples from your blog sort of confuse me in that they are referencing HTML and Plugins, while I am working with Handlers and Service cfcs in the Model; but it did inspire me to consider the interceptor approach. If I could recognize the current event, and make it process the parent app’s handler method instead of the module’s handler method, that should achieve my goal. I tried this using preProcess() in the interceptor but it didn’t work. After reviewing the docs, I am venturing into AOP and will try an aroundHandler(), or one of those options; unless you think of something for me to try. Thanks again for your help Andrew.
Jim
The blog post was more about modularity and scalability.
In each module you need to register what that module is going to listen for, or you can define it at the global module level. The idea is that you do something like this.
testHandler() {
…// Core Code that needs to run
announceInterception(“my_announcepoit”, {entry = data_to_pass1, isNew = data_to_pass_2});
}
When you then define any other module with interceptors that have these methods, they will then be called to do further processing.
Regards,
Andrew Scott
WebSite: http://www.andyscott.id.au/
Google+: http://plus.google.com/113032480415921517411