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.

At work we always build our applications targeting clustered environments, that means that even if an app will be deployed to a single server at the beginning, it can always be moved to a cluster without any change. We also use our own infrastructure for clustering and don't rely on session replication or sticky sessions. That environment presents certain challenges for maintaining state within an application.

Our standard solution is to rely heavily on a DB backed Client scope. However, this has always limited how we can persist CFCs in the application. Typically when we want to persist a CFC we have to build our own serialization/desearialization mechanism to accomodate it to the client scope limitations. This solution would work fine for simple CFCs but it would rapidly become a hassle (to say the least) when dealing with composition/aggregation relationships.

Needless to say when I learned about the CFC Serialization feature in CF8 I was very eager to see how it could allow us to make better use of persistent CFCs. Sadly as soon as I started to make some simple proof of concepts I discovered (and later confirmed) the limitations of the current implementation of CFC Serialization in CF8. Apparently the serialization mechanism chokes when you have arrays, dates or query variables as instance variables in your CFC. Actually the problem is not the serialization, but the deserialization process.

Anyway, since other than that the CFC serialization worked beautifully (as far as I could tell), even with composition relationships, I still wanted to find a way to make use of this feature.

After a little bit of tinkering I found that I could make the CFC Serrialization work as intended if I just used a different Java class for the objects instead of the one provided implicitly by ColdFusion.

For example, instead of using ArrayNew(1) to declare my array, I found that using createObject("java","java.util.ArrayList").init() would work just fine. And for date objects using java.util.GregorianCalendar would do the trick.

Obviously the code that interacts with this Java objects need to be updated, but you can always create wrappers around it to handle the transformation between java.util.ArrayList and regular ColdFusion arrays, for example.

Well, here is the code for the object I used on my testing. I can now happily say that my days of limiting myself to persist only dull CFCs seem to be coming to an end :)

PS: You can find the code for serializing/deserializing CFCs here and here.

I wanted to share a couple of news about the BugLog project.

First if you are using ColdBox, Tom Demanincor wrote a very nice tutorial on how to integrate bugLog as a ColdBox plugin. Check out his blog post here, it is very detailed and shows the code needed to make it work.

Also he raised an interesting point if you are modifying buglog to use per-application mappings. The BugLog distribution contains basically two independent applications. The main one is the server/listener part, which is the part that receives the bug reports from the applications. This is on the main bugLog directory and has its own Application.cfc. This application does not have a user interface.

The second application is the HQ application, which is the part that has the user interface and is where you get redirected if you just go to /bugLog in your browser. This is where you can see the bug reports and look at the pretty charts. This one also has its own Application.cfc and is located in /bugLog/HQ

So if you are defining per-application mappings programmatically on the Application.cfc don't forget that you need to set them up on both Application.cfc files otherwise you gonna find some weird errors.

Additionally a couple of people in the community reported a few minor bugs that needed to be corrected. The first one dealing with some component references not being created with the full path to the CFC and resulting in some errors. And the second one was that sending of bug reports via email was not working due to a missing setting.

To enable emailing a bug report that has been received you need to edit the /buglog/hq/config/config.xml.cfm file and set the contactEmail setting to the email address you wish to use as the sender.

I have updated the project in RiaForge with these fixes, so you can get the latest release from there. Here is the link.

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!

I realize I'm a bit late posting this now, but better late than never :) Last week I had the opportunity to do a presentation about ColdBricks to the Inland Empire's ColdFusion User Group (IECFUG). I want to thank Luis and all the IECFUG guys for inviting me and enduring my bad english and my blatant lack of PowerPoint/speaker skills; but hopefully they got to see a bit of ColdBricks in action and got a better idea of what ColdBricks brings to the ColdFusion's CMS market.

Here is a link to the recorded Adobe Connect presentation; also attached to this post are the presentation slides in PDF form. Feel free to take a look as it may answer some ColdBricks/HomePortals questions some people may have.

Again, thank you guys for the opportunity!

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?

So it's official, my new venture is now live and open to the public. ColdBricks is a free and open source content management system specially tailored for highly modular websites like portals and dashboards. The current version runs on ColdFusion 7, 8 and Railo 2 (still having problems with BlueDragon though).

[More]

Well, after several years of going back and forth with this project, I finally decided to share it with everyone and release my little baby as an open source project. HomePortals is a framework or platform for creating and running portals in ColdFusion. Most of the features in HomePortals focus around modularity, reusability of visual components, and personalization.

Besides providing the framework, conventions and APIs for creating the sites, HomePortals also acts as a 'runtime' or 'rendering' engine. All pages in a HomePortals application are actually XML documents that describe the elements and modules to display as well as their layout and arrangement. The HomePortals engine is responsible for reading, parsing and rendering the actual pages based on the specifications of the given XML documents. This is a little bit like MXML in Flex, but in ColdFusion.

I have succesfully tested HomePortals in ColdFusion MX 7, ColdFusion 8 and Railo 2. I have not yet had the chance to try it out in BlueDragon.

I created a small site for this project, where you can download the framework, a sample application and find some documentation. The URL for the site is http://www.homeportals.net

HomePortals has an LGPL license, which means that the library itself has to remain open source and any changes have to be shared, but it can also be used by non open source applications as an external library or component of the application.

If someone wants to try HomePortals out I'd really like to hear some feedback.

Another related project I will be releasing soon is ColdBricks... but I'll talk about that some other time :)

I've been always fascinated by the idea of software daemons, like tiny green gnomes lurking in the insides of the computer just waiting to quickly and silently take care of multiple tasks. When ColdFusion 8 came out with the new CFThread tag, for some reason one of my first thoughts was if I could use this tag somehow to create my own ColdFusion-based "daemons". I wondered what would happen it you created a thread and fired it off on an endless loop, always checking for some condition or some occurrence to act on. Of course, after having developed ColdFusion pages for so long, the idea of an infinite loop in CF only brought images of chaos and servers crashing to my mind; however the curious and mischievous mind in me prompted me to just try it out and "see what happens".

[More]

Well, I think is time for a first sneak peak of a project I've been working on for the last few months. The project name is "ColdBricks" and is basically a cross between a Website generation app and a CMS.

Here is a screen cast of myself using ColdBricks to create a simple "Start Page" application. If you don't hear any sound, don't worry, I didn't had a mic at hand; but I guess the video explains itself. Basically I log into the application, create a new site, open the site to mess around with some of the editing features of ColdBricks and then launch the site.

Stay tuned for more ColdBricks info in the following weeks...