Luis,
After digging into the code I think we have a bug in the ContentBox admin module.
What I am working on is adding new content types into ContentBox within a module I am writing. So I want to make use of the existing contentbox-admin module for as much of the functionality as I can (rather than making copies of all the necessary files). In two different instances thus far I have found issues when I make an event in a handler in my module so that the event mimics the same event in the cbadmin module.
For example, in one of my new content types (extending the base content class) I want to provide the ability to add related content that includes not just Page, Entry and ContentStore, but also my new content type. So I created the following in my content type’s handler in my module:
function showRelatedContentSelector( event, rc, prc ) {
event.paramValue( “search”, “” );
event.paramValue( “clear”, false );
event.paramValue( “excludeIDs”, “” );
event.paramValue( “contentType”, “Page,Entry,ContentStore,MyContentType” );
// exit handlers
prc.xehRelatedContentSelector = “#prc.cbAdminEntryPoint#.content.relatedContentSelector”;
prc.CBHelper = CBHelper;
event.setView(view=“content/relatedContentSelector”, module=“contentbox-admin”, layout=“ajax” );
}
The problem arises in contentbox-admin/handlers/modules.cfc. After var results = runEvent(event="#module.getname()#:#prc.contentbox_moduleEvent#"); runs and returns null, the following code incorrectly overwrites the module specified in setView():
// stash the module view, so it renders in the admin layout
prc.viewModule = module.getName();
The intent was to insist that the view gets rendered in the admin layout. The result, however, is that it applies the module that the event is in, which in this case is my module. So it changes the module from my setting of “contentbox-admin” to the module my code is in. The view, of course, is not present in my module (as noted, the intent is to make use of the core and not make copies that could end up being out of date upon upgrade of ContentBox). So ColdBox looks for the module in the wrong module and, when it fails to find it in the module, looks for it in the root.
Of course, we can’t just remove this line as it causes the pages of my module to fail. But REMming out the line and simply browsing the showRelatedContentSelector() event correctly displays the Add Related Content interface with my additional content type.
Obviously ContentBox wasn’t written with this scenario in mind. In my mind it would make sense for custom modules to operate within the admin area and be able to reference and use admin area code. I think the prc.viewModule = module.getName(); line contentbox-admin.handlers.modules.execute() achieved the desired result without going about it the right way. I don’t think it anticipated executions of events that only need to call a view (and that specify the desired module for the view).
Perhaps I am missing the correct method of specifying the module within this context. Please let me know.
Also, if you, Luis, agree that this is something to be addressed as a bug, let me know and I will enter it into jira.
John
