How should I structure this set of Coldbox apps...

Hi all,

I am developing a set of web applications for my company and will be using Coldbox. The structure is like this:

  • There is an overarching app that encloses all the others. It doesn’t do much in itself except manage user logins, which apps they can access, etc.
  • Within the overarching app are the main working apps. These have their own distinct functionality and it’s not anticipated that they will share much functionality or data, but some of that is potentially possible. They may share some common plugin functionality such as security, testing, mocking, etc. Some of the working apps will have both an admin component and a public component that our customers see.
  • These working apps will have with them modules that are specific to that app. These modules will likely not be interchangeable between apps.These modules can have both admin and public components.

I’m stumped on whether I should try :

  1. To put all of this into a single Coldbox-powered app (with each working app being a module), or
  2. To make each working app its own CB-powered app (with the app-specific modules being, obviously, modules)

#1 would seem to allow for a more unified approach and would better facilitate a universal login, etc. But if each working app is a module, are the modules for each app modules also?

#2 would seem to address the issue of handling modules, but how would I manage unified login and user management functions?

Any help/advice would be much appreciated!

Gary

Gary,

I develop a ColdBox powered platform that sounds similar to your outline. This is simple explanation of what I’ve done:

/platform (one Git repo)
/platform/app1 - A coldbox application
/platform/app2 - A coldbox application
/platform/app3 - A coldbox application
/platform/shared/ - Shared config settings and models.
/platform/logs/ - All apps log here

Most of the business logic (security, login, application services, entities. etc…) live within /shared/models/ and are injected into the ColdBox applications as needed using WireBox. Anything that can be shared between applications is placed within shared and is not directly dependent on ColdBox (they are dependent on WireBox). This allows me to be completely flexable in each ColdBox application. The down side is that the session is not shared across each application–however, there are simple ways around that if that is a requirement for you.

I have the feeling others would advocate that you use ColdBox modules to provide common functionality between your applications. I just prefer to put that stuff in a model and let each app have full control over the implementation of these shared features.

Hope that helps.

Aaron Greenlee
http://aarongreenlee.com/

Hi Aaron,

That makes a lot of sense. I haven’t done much with Wirebox but this looks like a good chance to get more familiar with that.

Thanks for the input,

Gary

Hi Aaron,

Quick question if that’s ok: is it possible to inject something from another application, or does DI only work from within the same app?

Thanks,

Gary

Yes it is possible to do that, just add a mapping to the component and wirebox will inject it for u.

Hi,

I have a related question. My app structure looks quite similar-

/platform (one repo)
/platform/app1 - A coldbox application
/platform/app2 - A coldbox application
/platform/app3 - A coldbox application
/platform/shared/ - Shared models.

I would be injecting the shared models into my applications as needed using Wirebox. But there’s something more that I want to do. There is a module in one of my apps that I want to share fully with other apps, i.e., not just the model functions in the module but the views as well. Now, I haven’t developed that module as a ‘Coldbox module’ within my app, but would doing that help in sharing the module across multiple applications?

I’m relatively new to CB and any help would be greatly appreciated.

Thanks,
Parul