I may just be thinking this is supposed to work the way I want it to rather than paying attention to what it really does. It seems in the documentation that modules are configured to provide content to their parent application, not the other way around. But what I want to do is create a module that basically extends the parent application so I need it to work in reverse. All my initial attempts and configuring a module handler to inject something the parent is wired to do are failing and more over, just trying to display the contents of a session scoped object that the parent application should have already populated fail as well.
Is this not possible? To inject into a module handler a mapped entity from the parent application?
This is certainly possible. Can you explain to us what you are trying to inject and the syntax you are using (it should be the same syntax as injecting into a parent app handler).
My only caution with this would be that the module is now coupled to the parent app, but if your desired behavior is just to break apart a large monolithic app and you aren’t worried about reusing this module in other applications, this is probably fine.
Sure. For example, in my parent application I have a DomainHostService singleton (and gateway and bean) that helps to manage information about the domain the user is coming from to hit the application. So, just like in the case of the interceptor that depends on the DomanHostService, in the module “home” handler I:
once you said it should work, I realized that I had changed to mapping a directory of services rather than name mapping them so I was using the wrong name for the id. I switched that out and that works.
So, since you seemed to think I should not be having any problems doing this or accessing my session scoped variable, I looked around and realized that I was using the wrong syntax for displaying that value.
The mistake I keep making is just because my mapped object is “named”, I cannot just use the “name” and expect a results. When I getModel(“name”), it works just fine…and of course if I dump the session I can see the mapped named object “wirebox:name”…which is exactly what I should be expecting.
I’m still getting used to the functional way variables are stored and kicked around the application so I apologize…this question was clearly premature…though it did at least get me to dig a little deeper now knowing this functionality should be available.
This kind of coupling is, I hope, exactly what I’m looking for, however, if you are interested or particularly talented with modules there is an earlier post on a related but different topic you might find challenging (though I hope you actually find it so easy you say "oh, sure, just do this:))
I was trying to do a similar thing - and bailed because I couldn’t get it work, however this post has given me hope.
Apologies for hijacking the thread…
Each of my “parent” apps are standalone. They all exist to achieve a different purpose - essentially they have zero common business logic/data.
But of course there are certain bits that are in every application, take security for example.
Initially I used the solitary module - but found I couldn’t integrate it exactly the way I wanted to… so I rolled my own.
The big problem I have is this - and I think most of it is related to injection AND ORM:
ParentAppOneUser has a bunch of specific demographic information stored in it
ParentAppTwoUser has a different set of demographic data
What I was trying to do was have these “User” objects extend a “UserAccount” object in a security module, which would provide username/password properties and all the handlers to perform basic security processes
I would prefer my parent applications to include this module from a common “externalModulesLocation”
How would you go about architect-ing this?
At the moment deadlines have meant that I have just rolled the security code into each application
I don’t have the exact answers, but one of the things that I started to do was along the following lines.
Every Module needs to be and treated as if it is independent, what this means is that you should be able to move modules from one application to another with extreme minimal reconfiguration.
I also took the approach with Contentbox, and modules / plugins that I wrote for it, that if there was common code that could be reused by another module, then I created a common module dependency. For example in Contentbox, one of the most common things I found that could be reused was saving settings for a module, so that was easy enough to separate. With plugins / interceptors also falling into this rule.
The above was or is the way I had been leaning with normal modules in an Application as well, by treating modules as black boxes I was / am able too incorporate them with ease into any application.
Now Steve you touched on something that I began to look into as well, and although I haven’t got around to doing this with modules, I think the principle of a blog post I wrote about ORM and sharing code still applies to some degree. Although I am not sure how to fully go about this as yet, as I do see some short comings with modules and ORM with global and different fields per application.
I’m clearly the wrong person to advise on this being that I’m still learning…but how about some clarification.
Do “parent” apps mean modules in a shared site root or are you creating several web applications that you would like to share code between? Both would likely have very different architectures.
In my situation, I have one site root application and my modules are just that…modules of distinct functionality that need to inject from objects living in the root. As the document suggests, the beauty of a module is that it can stand alone…but my application focuses more on how it overrides.
Not trying to help Just providing some clarification if needed.
By parent apps I mean different completely different coldbox apps running on the same server.
By shared modules I mean Coldbox modules residing in a “mapped” directory which the parent apps refer to for external module location
I want to be able to have an object in the parent app extend a persistent class in a module, and have the module contain generic activities around that base (mappedsuperclass) class
