Can Coldbox have multiple handler / model / Controller /plugin directories, and is one able to add to / delete from these via an API?
Andrew Scott
Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613 9015 8628
Mobile: 0404 998 273
Hi Andrew,
Interesting question. As of now, you can have two locations for handler and plugins. As for model, you can have as many as you want, that is up to you. Now, for plugins you have the custom convention which is the main application “plugins” folder. Then you can set an external location via the configuration file called “MyPluginsLocation”.
For handlers, you have the convention “handlers” then you have an external handlers location via the configuration file called “HandlersExternalLocation”.
What happens for handlers is that the framework sees those registration points and tries to register all the located components in those directories. Once a event is requested, the framework tries to locate the component: conventions first, external location first. If a match is made, then method detection is done and execution follows.
So as you can see there is more to it, and I don’t believe the current infrastructure supports on the fly event handler additions on other locations apart from those mentioned above. However, it might seem like a good idea to open an api for appending registration points. However, I still have not found a use case for it.
Please post all the ideas on this area as they are interesting and might be something great.
Luis,
I am looking for a framework that will allow me to do a module based drop in and away she goes. But working on an MVC framework if possible.
The idea is that I can create a directory called modules, this directory holds the view / handler / plugin directories associated with that module. The reason I am looking at this now is that, I would like to at a certain point, do a check for current module installed against that in the module directory and update the code if necessary. So updates to a module are easier.
I hope that made sense to you, if it doesn’t then look at Drupal and how you add modules to the core. Just drop them in and the framework picks them up, as an API for Install / update etc.
I am hoping to mimic that functionality if possible.
Andrew Scott
Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613 9015 8628
Mobile: 0404 998 273
Hi Andrew, You can do drop-in functionality on handlers, plugins, views/layouts. However, they have to be on those directories. Then you can via the API re-register the handler index.
getController().getHandlerService().registerHandlers();
You can do this programmatically, and the framework will pick up the just dropped handlers in BOTH locations. A trick I have done is the following:
Add a modules folder in your application, then set that directory as the external location for both handlers and plugins. Then anything you drop into the modules, will be available as plugins and handlers. You can also place views and bring them in using ‘renderExternalView()’ methods.
However, if you have no problems droping modules into their appropriate directories then it would be absolutely simple and easy to do.
I will anyways, take a look at drupal and see how they do it. However, with the conventions available to you in coldbox, you can accomplish this by just placing the pieces in the correct directories as packages.
/app
/handlers
/blog
/forum
/plugins
/blog
/forum
/views
/blog
/forum
You can even add SES routes dynamically using the ses interceptor. So routes can be added dynamically. You can even create a auto-registration interceptor that just monitors those folders and will run registration on even interceptors themeselves (2.6 only).
This is an interesting topic Andrew. The approach I have used on several apps are the conventions based of adding them to their appropriate folders. keep em coming.
PS. plugins need no registration, if they are there, they will get loaded.
Hmm, never thought of it like that.
But in my situation it would be ideal to have this rather than you example.
/modules
/blog
/handlers
/plugins
/views
/forum
/handlers
/plugins
/views
So if I read you right then I can access Views like modules.blog.views.home? If it can do that with handlers and plugins as well, then I am going to be a happy chappieJ
This way a directory can be removed, and it will not affect anything else. Drupal is impressive actually, as it has API hooks into the modules for updating, installing etc. That includes setting up the database as well. That’s the easy stuffJ
Andrew Scott
Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613 9015 8628
Mobile: 0404 998 273
I played with this idea a bit this morning and may have a workable
option for you.
You can use the settings.xml file and the <conventions> you can change
the default location of all the directories (views, handlers, etc). I
changed them all to the modules folder.
This then enabled me to have this event <a href="index.cfm?
event=blog.handlers.general.dspHome">Blog</a>
Which called this view <cfset Event.setView("blog/views/home")>
While I didn't try the plugins I imagine it would work as well. This
is a little quick and dirty but I think it solves your need. I also
played with the idea of a preEvent Interceptor that would register
External Handlers on the fly but ran into some issues when using the
handlerService from the CFC API. I will probably get back into this
evening and see if I can develop away to to it with out having to
change the core directory conventions of ColdBox.
Here is a link to the Wiki and the settings.xml file
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbDirectoryStructure
Mike
HI guys,
great stuff. Also, note that on 2.6 you now have custom conventions. Which you can declare on your configuration file directly.
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbWhatsNew2.60#Per-AppConventions
The approach of pointing to one directory is an excellent idea. Also, you can point the external handler location and the external plugin location to a folder inside of the views folder named modules:
/handlers
/layouts
/plugins
/views
/modules
/blog
This way, you can use setView(‘modules/blog/view’). Run Events if you map the external location to :/views/modules ==> runEvent(‘blog.myhandler.myaction’). Then if you map the external plugins location to :/views/plugins ==> getMyPlugin(“blog/plugins/whateverplugin”)
As you can see, this shortens out a little bit. And the most important thign, is that you still have an application structure for your core application and then just bring in extra modules via the external locations. You can register new stuff by using the following:
getController().getHandlerService().registerHandlers()
Again, plugins are self-registration, no need to do anything. As for interceptors, you will be able to do the following:
getController().getInterceptorsService().registerInterceptor(‘classpath’, ‘properties’)
You can add custom interception points
getController().getInterceptorsService().appendInterceptionPoints(‘list of points’)
I hope this helps. Let me know your results, it could be a cool tutorial.
Thanks for the update on the custom conventions, I evidently read
right past that.
I was writing a post about doing the settings.xml file, but will
change it up to use the 2.6 custom conventions.
I will send you the link when I am done with the post.
Thanks guys...
I hadn't had the time to try this, and RefriedChicken (how on earth
did you come up with that name) has done what I was thinking. It is
good to know that with little code it will work, well what I need to
do anyway.
The one thing I am not 100% sure on is the IoC side of things, from
what I can tell when I do what I need to do. There needs to be a
specific entry point on each module, that is called when needed.
So if we take the module blog (or any module), I am thinking that if I
take the approach of drupal. The first check is to see if this module
matches the database, no then update via the update hook into the
modules code.
I can't believe that it was staring me in the face all this time 
Also remember that you can create multiple instances of the IoC plugin. So each module can have its own instance of its IoC factory. Even have differente factories. Also, lightwire is integrated with coldbox, so you can leverage that. Using the ioc plugin, you can reload factories, reload configurations, create factories, switch factories, etc. Just use the “newInstance” argument on the getPlugin() method.
Luis
Announcement and update on this issue. I have just commited a new
setting: ViewsExternalLocation
With this setting plus the handlers and plugins external location, you
can now get even better functionality for modules. Since now the
modules can setViews to render from within their handlers just as
normal views.
Please check it out.