I hope you are enjoying Ortus Solutions' ContentBox Roadshow so far. We're had one free webinar already, and a few blog posts, with plenty more to come. Today I'm going to talk about modules a little more. I mentioned them in my "What's New with ContentBox" presentation ( you can read more about it and watch the recording here ), but you might not have known, I got excited about ContentBox and all of the modules before the roadshow even started.
Today I'm going to highlight 5 blog posts I have already published over the last few weeks, and hope that you go and read up on these great topics, so in my next post, and my webinar later in the month, we can go even deeper with modules.
I think these blog posts are a great starting point, and will let you learn more about what makes a module, different ways you can build them, and using them inside ContentBox
If you have any questions, please leave a comment, and I can build the answers into my webinar, on July 29th
I can see the light at the end of the tunnel. ContentBox 3.0 has been a massive project, with so many changes and features, its really exciting to be a part of it. The good news, the testing is almost all done, we're going to cut a final release very soon. With all the work being put into ContentBox 3, on top of the client work, we've been very busy at Ortus Solutions, with a lot of major releases. Personally, building apps built on top of, and around CMSes for 16 years, means that ContentBox 3 is very important to me. I have several projects I am in the middle of developing for Ortus, but also for myself, that is using ContentBox 3 Beta. I must say after using a home grown CMS for years, I am loving working with ContentBox 3, and today I'm going to share one of the reasons... Modularity.
In the last blog post, we talked about extending ContentBox with modules. With ContentBox being built on top of ColdBox, and integration with ForgeBox using CommandBox, there are a lot of modules ( and module locations), and how those modules interact isn't obvious at first. To be honest, with ContentBox 3, we only just decided to move the core contentbox modules, to provide clearer separation, and easier source control management... things are changing, so I thought this would be a great time to explain about the different type of module locations, and why you should use one over another.
In a previous Post, we talked about extending ContentBox easily with modules, and showed you how you could just download a module, activate it and use it in minutes. In this post, we'll look at how to add Modules into your website, by building your own, and how to leverage Module Layouts.
Whether you have used ColdBox before or not, using Modules with ContentBox and ColdBox is fairly straightforward, in fact, I think its a great way to dip your toes into using both technologies. Working with Modules is like everything else in ColdBox, you work with conventions, but you have control. In this previous post, 'Modules Modules everywhere, Extending ContentBox', we show you how there are 4 locations for modules in ContentBox, and depending on how your module will work, you should choose the appropriate location. In this post, we're going to build a custom ColdBox module, which it not managed by ContentBox Admin's Module Manager.
In our last post on Extending ContentBox 3 with your own Custom Modules we learned that you could build a custom ColdBox Modile with amazingly, just 2 files. You could paste in your legacy spaghetti code right into your default view, and it would work. Of course, we probably want to dress it up a little more, and add some more functionality, so lets look at the layout first.
In previous posts we have talked about creating a ColdBox module from scratch ( ContentBox - Extending ContentBox 3 with your Own Custom Modules ), one file at a time, to see the minimum files required to make the module work. That was a great educational exercise, but lets look at another way to create a module, with CommandBox's ColdBox scaffholding commands.