I just pushed new updated versions of HomePortals and ColdBricks to their respective sites and are now available for download. As usual the updates contain multiple bug fixes and small improvements here and there. However there are a couple of features that are worth mentioning.
A while ago I shared a small framework I created which I use to develop pretty much all of my projects (both open source and paid engagements). The framework, as is usual for web frameworks, follows the MVC and Front Controller patterns; also like Sean Corfield's FW/1 and Barney's FB3 Lite (and many others) it has an emphasis on minimalism and makes an effort to stay out of the way as much as possible. I recently made some changes to the framework and wanted to share them with the community.
A few weeks ago I wrote about how to use the layout management features of HomePortals on a ColdBox 3 application. This time I want to show how to do the same but with an application built with the Model-Glue framework and also explain a bit more of why would you want to do so in the first place.
A while ago I wrote a post about how to integrate the HomePortals layout rendering features into an a ColdBox application. Since then a lot has changed on both the HomePortals and ColdBox camps so I've been wanting to revisit that experiment and see if it could be made in an easier way now, using the advances on both frameworks. Read on for the findings.
I wanted to quickly share that two new ColdFusion websites have been launched recently: MSDynamicsWire.com (a news portal) and Meancycles Owners Galleries (a social network). Both sites were developed using HomePortals and ColdBricksCMS.
Both sites show different level of integration and customization, as each serves a very different function, but they are good examples of the wide range of solutions that can be obtained by combining the HomePortals framework with the ColdBricksCMS platform.
Recently I finished overhauling the way HomePortals 3.1 handles page templates and wanted to find a real-life (and useful) way in which I could demonstrate its new features. So, in this post I want to show how the templating features in the new HomePortals version can be leveraged to provide layout management capabilities on top of an existing application like BlogCFC. Why BlogCFC? well, first because it has a great segmentation between the blogging engine (the actual blog.cfc) and its presentation layer, and second because I already use it on my own blog and have plenty of real-life data to play with.
A few days ago I found out (via tweeter) about this plugin for jQuery. Apparently UI.Layout is a port or adaptation of extJS border-layout but done the jQuery way. Well, this is basically a plugin to create complex full-screen layouts, with resizable panels and everything... really cool stuff. So I started wondering if I could use this to leverage the way HomePortals deals with page layouts and see if I could use hp to declare the page modules/widgets/content but on a layout controlled by the UI.Layout plugin. It turns out in fact that I was able to mix both projects pretty easily. Here's how.
First of all, lets jump to the end and see what the finished product looks like
And this is the corresponding HomePortals page:
You can check out a live demo of this page here.
So, did I pick your interest? well, if yes, then keep reading to find out how this was implemented. At the end of this post you can find a zip with the entire example, but let me go over the important bits here.
** Note that this example requires HomePortals 3.1 beta, and will not work in earlier versions. You can get the latest release here
First of all, we need to setup a HomePortals application for this example and set the appropriate environment. For the purpose of this example, our HomePortals application will live on a directory named "uilayout". You can find the complete dir structure and required files on the attached zip file.
For the main settings we will use the standard config xml file.
homePortals-config.xml
The first two entries just tell HomePortals where to find the content pages and what page to load by default.
The UI.Layout plugin uses CSS class names on DIV elements to determine the type of layout region. There are five types: center, north, south, east and west; each one with its own specific class name. So, since all our layout regions will be rendered the same, we will need only "one" kind of layout region. We will name this a "region" and declare it on the layoutSections tag.
Next comes all the jQuery javascript files. These are ones required by the UI.Layout plugin plus one additional "init.js" to handle our jQuery initialization routine for this page.
init.js
The only thing this does is to initialize the layout plugin.
Then finally the final bit of configuration that we need to add is to define a "page" render template. This is because the overall HTML markup needed by the UI.Layout is way much simpler than the default HTML structure that comes out of the box in HomePortals. The "page" render template controls the overall HTML structure that will be used to render all HomePortals pages.
page.xml
The relevant part here is the $PAGE_LAYOUTSECTION["REGION"]["DIV"]$ line. This just tells the HomePortals renderer to render all "region" sections one after another and use DIV tags around them. The HEADER and FOOTER custom sections are really not needed and not even used on this example.
So, once that is in place, we can just declare our pages and use the UI.Layout class definitions to create the layout. Like this:
start.xml
The layout section is where we declare the page layout using the UI.Layout class names for the different regions. So if we want to customize the layout, say, do not have a footer, or have only one left column, we can change that here easily by just removing the location tags that we don't need.
The next section body is where we declare what goes into which layout region. the content tags just display plain text or html content while the view tag does a cfinclude of a CFML template. Of course you can now use the whole HomePortals framework features to create your own tags and do whatever you need.
And since jQuery is so awesome, here is another example that uses pretty much the same setup but adds some drag & drop funkyness.
*** THIS IS A REPOST OF AN EARLIER ARTICLE THAT GOT WIPED OUT ON A RECENT DB CRASH. ***
If you ever wanted to modify ColdBricks or BugLog, but didn't understood how these application were constructed; or if you just want to see yet another way of developing CF applications, then this post may be for you.
I just posted some pages describing the framework I use for developing CF projects. It doesn't even has a proper name, I just call it "Core" due to its simplicity and its minimalistic nature. The basic principle of this framework, and the reason why I choose to use it instead of going with more traditional offerings, is that it only focuses on one thing and one thing only: provide a formal mechanism for going from one page to another and for invoking actions.
It doesn't do any fancy things, no complex request lifecycles, no sophisticated caching, no extensive API, none; however, it does provide enough extension points to which I can hook any functionality that I desire on a per-project basis. Basically the framework consists on a Front Controller implementation, a base event handler and a few conventions for directory structure and nomenclature.
Anyway, you can find the code and read more about this framework by going to the Projects section or by going directly here.
This afternoon I have been experimenting with a somewhat interesting and funky idea: mixing the layout rendering engine of HomePortals with a full application framework like ColdBox.
Why? Because integrating these two engines would allow developers to create applications that can benefit from the modularity provided by HomePortals on the front end and at the same time enjoy all the swiss-army knife functionality provided by ColdBox, in particular the rich control over the lifecycle of the requests and the application.
For example, this could be great for developing dashboards or BI applications. HomePortals would make it easy to create a modular interface based on small widgets or pods, and ColdBox could handle the overall application structure and tasks (security, persistence, logging, etc).
In theory it sounded possible, so I just went ahead and see what I could get. Well, at the end I found that the two worked beautifully together.
I do not have yet a full working application that I can share, so for the time being this is just "proof-of-concept" type of stuff.
Here is what I did.
** For this I used ColdBox 2.5.2 and HomePortals 3.0.189, which are the current releases for both projects.
First I created a new coldbox application using the "ApplicationTemplate" found on the standard ColdBox distro. I named the new application "hpcoldbox" and put it on a directory under my web root so I could get to it by going to: http://localhost/hpcoldbox
The first part was setting up the HomePortals side, which was basically just modifying the newly created application to look like a HomePortals site and then writing a sample page to display. Let me describe this step by step.
Within the "config" directory I added the two main HomePortals configuration files: homePortals-config.xml and accounts-config.xml.cfm
homePortals-config.xml:
accounts-config.xml.cfm
Those files provide a very basic configuration for HomePortals. The first one just states where the application is located and where will the account files be stored. The second one just expands a bit on some details about how we are going to store the account data.
Next I needed to create an account an a sample page. For that, under the root of the new application, I created a new directory named "accounts", with the following internal structure:
To make things easier I just copied the accounts.xml and site.xml from /Home/Accounts/accounts.xml and /Home/Accounts/default/site.xml since I was using pretty much a default setup.
For default.xml, which is our sample page, I used the following code:
Nothing fancy, just display a couple of feeds and a flicker photo stream.
Finally I had to create a template to allow HomePortals modules to talk back to HomePortals in an asynchronous way. So I created a file named gateway.cfm in the root of the application with the following contents:
That was it for the HomePortals side. The next part was doing the ColdBox part.
HomePortals works basically as an API, that means that everything is object-based, so the crucial part is to have an instance of the HomePortals main object, which is Home.components.homePortals. The best practice is to instantiate it as a singleton and just leave it on the application scope. Since we need to do this only once for the lifetime of the application, I added the following code to /hpcoldbox/handlers/main.cfc
I know ColdBox offers more options for these kind of things but for the purpose of the experiment this seemed like the quickest way to get up and running.
Then, I modified the default event (general.dspHome) in /hpcoldbox/handlers/general.cfc
What this code does is get the homePortals instance and load the page named "default" on the account named "default". After the page has been loaded and parsed internally, it then asks for the rendered HTML corresponding to that page. Then we set that returned html content into a variable named "html" in the request collection. Finally we set the view to render.
Notice also the <cfsetting> tag that I had to add on top. This was needed because it seems that coldbox internally has it set to true and that affected the rendering of some parts of the output in HomePortals.
Next I modified the default layout file (/hpcoldbox/layouts/Layout.Main.cfm) to just limit itself to render the view. I did this because the output of the HomePortals rendering is already a full HTML document. However, you can modify your HomePortals settings to only a partial HTML page and use ColdBox layouts to handle the page's HTML structure.
This is what my Layout.Main.cfm looked like:
The last piece was updating the view (views/home.cfm) in the same way.
And that was it, when I went into my browser and fired up the application, the HomePortals page was rendered perfectly.
Again, this is a very simple proof-of-concept but I trust that if you are familiar with ColdBox you can see how this fully integrates into the application. You could have some pages rendered normally and some pages rendered with HomePortals; and thats without even going into further integration within custom HomePortals modules that you could write that could take advantage of the coldboxproxy to make even more interesting things.
I am really excited to have been able to find this out, as I said at the beginning, because I think it opens the door to very interesting opportunities. It would also be interesting to see if HomePortals can also be integrated in the same manner with Model-Glue, MachI, Fusebox, or other full application frameworks; however my practical knowledge of those is even less than what I know about ColdBox, so if anyone is willing to give it a try I'd love to hear how it went.
Thats it for now,
Happy coding!
We spend ridiculous amount of time discussing the merits (or lack of) of the different MVC frameworks in ColdFusion, and we keep doing it again and again. Well, at least everyone should agree that when it comes time to decide how to go from one page to another we got that pretty much well covered. But for all the OO fever taking over the hard-core ColdFusion community as of lately, why are we still focusing on the presentation layer still, which honestly is the least OO place in the whole application? Where are the repositories of just plain libraries? components and subsystems that we plug together to provide sophisticated functionality to our applications regardless of how the presentation layer is done.
Yes, we have Transfer, ColdSpring, and Reactor, and they really rock; but it seems that that's where the list ends. Has nobody written a really tight, super strong, caching library? what about a job-scheduling library? It could be that the lack of these libraries as separate entities is what motivates MVC framework authors to add more and more complexity to their projects, which in turn fuels the discussions of why these frameworks are so bloated and complicated. I know Luis, from ColdBox, has put a lot of effort in building the caching functionality in his framework, and knowing the quality of his code I'm pretty sure it kicks a$$; but sadly is all tied into the framework. Wouldn't it be much more beneficial to everyone if there were already some project out there that would provide this functionality so that you could just plug it in into your application?
If we have enough of these little libraries that would focus on doing one thing and one thing only, then the 'framework' in which an application is built would not need to be these gigantic-swiss-army-knife platforms that we are getting used to. They would become lighter and lighter until they are reduced to a 'core', just down to the basic principle that embodies their core ideas. Imagine a coldbox-core, a modelglue-core, a fusebox-core, super small code bases that just provide the basic guidelines and minimal code to support a proposal on how an application should be structured; And then on top of them we could have 'distributions' or 'shells', canned projects that would group together a 'core' and a few libraries to put together a basic solution, custom tailored for specific purposes. For example, you could have a shell for an intranet application that includes the framework core, a caching subsytem, a security subsystem, an IOC subsystem and an ORM subsystem; or on the other hand there could be a shell for a plain website that may only include the framework core and a caching subsystem. The bottom line is that all those parts can be plugged in an out and replaced or extended, and the application as a whole could be customized to the specific needs and would not need to carry any added complexity that is not desired by the author.
If I may give a suggestion, we should move on from the MVC frameworks and start focusing in these kind of projects. We need to focus more on libraries and subsystems in that the only interface is an API that can be used by other applications. Of course, in order to do that, it should be easy for everyone to find these libraries. RIAForge makes a terrific job as a repository of entire projects, and maybe it could be extended to add a new category exclusively for ColdFusion libraries and APIs; or maybe we need an entirely new website to allow us to post and search libraries for different types of functionalities that anyone wanted to add to their application.
Any thoughts?
