Extending the ContentBox Model / views


I'm really diggin whats been done with contentbox! I have an
application which similarly abstracts content to "entries" and I can't
wait to file alot of the related functionalities into my contentbox.
I have a few questions though.

My first "module" that I'm working with, should allow for contentBox
to function in a multi-tenant fashion - that is, run multiple sites
from the same codebase. Rather then hack up the core, I figured i'd
explore doing this with a module (tho, it'd probably make for pretty
good core functionality). I defined an interceptor which pre-
process looks at the host, and retrieves an ORM object for which site
it is - this defines the basic "site" information as well as any
DNSMask entries they have. cool!

So the next task as I see it is to extend the model, basically
decorating some of the "beans" with a new property "siteID" - allowing
things like settings, pages, etc to be site-specific.. Being
relatively new to DI and AOP, i first thought, well mayeb thats what
this "binder" thing is all about - maybe i can just redefine the path
to that class and extend the original. Looking over it, i'm not sure
thats the direction to take and I'm wondering if maybe the group could
shed some light on this?

Similarly, there will be a number of admin and UI related changes
required in this and a number of the other "features" i'll be
porting.. Can anyone speak to overriding those sorts of things -
generally, i would use the externals / application sort of scheme, but
I'm thinking its going to be different in contentbox for some reason
(mostly because my module lives in a completely different place then
the admin or ui modules.. thoughts?


First lets take a look at your plans, when you say multi site, are your intentions to have more than one database per site?

No, in my current system, theres a complex key on everything.. ID +
siteID.. one db. before anyone critiques the approach,
i've run thousands of sites concurrently.. :slight_smile:

(and alot of one-to-many and many-to-many tables)..

lol, I want critique the approach, I use it all the time myself. If the applications share common data it is one of the best approaches to go for.

I had to ask because ContentBox is just modules, which you could just rip out and drop in your application.

Now I had wondered this same problem, and my guess is that there will not be a huge need for this. But that doesn’t mean Luis may not introduce it either.

The amount of work needed, as you would need to change all the entities to apply a site, and then retrieve the information and store the information based on that.

So as you have done this sort of thing before, there is more to it than just an interceptor.

thats kind of what i was thinking - I'd have to hack up the core a

so, no easy way to just override the appropriate models from my own
module via DI or something? Kind of "rewrite the mappings" to the

What beans?

along the lines of modules while we're talking about it.. my
tendency is to put the tests for my module into the module folder, but
i found this awkward because of the way the test directory is setup
(obviously my module doesn't have remotefacade, etc).. so i've
mimicked the path to my module inside test/modules (ie, test/modules/
contentbox/modules/multiTenant .. Where are others putting those?

I do the same thing, all tests go in a folder that is not apart of the source of the main application, and then create folders to mimic what the tests are.

I'm kind of referring to the orm objects (ex, modules/contentbox/model/
system/Setting.cfc) - but i could certainly see some services having
to be modified. I think with services, i can override the wirebox
binding.. but with these orm objects, i'm not sure that i can. yes/

after having said that, i guess i could just redefine the service,
pointing it at the new orm accessor and inherit the bulk of the
functionalities that are defined - does that sound viable?

Ok I thought you meant the ORM Entities, as they are not beans I just wanted to make sure.

Yeah the problem is that you would have to basic rewrite all the models and services, some services call themselves, so it is more than what you think. Not impossible to do, but just more than extending the services etc.

And how do you then read the data back?

The services would still need to know about pulling code out based on that site.

well, in the context of settings, i'd imagine i could redefine this
line i grabbed from the contentBox/moduleConfig.cfc:

pointing it to my new service which extends the contentbox service..

then, i would redefine init - pointing it to my new ORM Entity

finally, i would redefined "getAllSettings" mostly to update this line
to deal w/ the siteID:

var settings = list(sortOrder="name");

Like I say, i'm pretty newb at DI and certainly ORM - I'm just trying
to rationalize this before i really get in and get dirty!

Well that would sort of work, however.

You might as well look at doing the job correctly, and that would be to setup a default site that all ContentBox would use, then modify all the services and entities to take that into consideration.

Basically by doing it the way you are thinking, you are then rewriting all the services to do that anyway, and the entities, which means you are basically rewriting all the core code.

I am not trying to discourage you, just trying to get you to think outside the box more. Also with your approach, any major changes to the core and you will be constantly modifying your services etc.

I would suggest pulling a forked version of ContentBox, and try to get the core to work this way. Then submit it back to Luis, I know a few others might like this as well. It won’t be a popular feature, but I am sure there will be a few who might like the feature still.

Actually the more I think about this the more it will not be feasible, I just started seeing issues with 3rd party modules and widgets and themes that just will not work this way.

Here is a question for you. How do you handle content and data in a row that is not specific to a site?