One of the new features I really like on the new ColdBricks release is the Module Maker. This feature allows you to create your own customizable widgets or modules that you can add to your own ColdBricks sites.

To better demonstrate the capabilities of the Module Maker, I recorded a quick screen cast (using ScreenToaster) of how to quickly create a widget from Amazon and add it to a site.

Here is the video:

Cheers!

I am finally ready to enter the testing/packaging phase for the new version of ColdBricks. ColdBricks, if you don't know is a CF-based Content Management System (CMS) that is used to build sites on a modular fashion.

This new version includes some nice features such as:

- Template management (author and manage your own page templates and layouts) - Module maker (create and customize your own configurable modules/widgets) - Site monitor (monitor site, cache, and memory status of your sites from within ColdBricks) - Fully modular and extensible architecture (think 'custom plugins') - A new and more simpler page management format - Create your own catalog of resources to use in your site (great complement to the ModuleMaker) - Completely updated rendering engine (yes, that means HomePortals 3.1) - And more!

At this moment there is not an official distribution package, but if you want to play around with it (and help me test and/or provide feedback), here are the download links:

ColdBricks 1.1 (Beta)

Also you will need the new version of HomePortals: HomePortals 3.1

For both of these, just download and unzip on the root folder of your site, and go to http://your_domain/ColdBricks to get started.

Additionally some of the site templates in ColdBricks, like the StartPage and the Blog, require a couple of HomePortals plugins. Here are the links:

HomePortalsAccounts

HomePortalsModules

Again, just unzip on the root and thats it.

As for requirements, this version has been mostly developed on Railo 3, but was tested on CF 8.0.1. I did all my dev on a Windows machine, so if you test on a *nix or mac, let me know if you run into any upper/lowercase issue.

As always, documentation is still trailing behind (far behind), but i'll be happy to explain and even write some blog posts to clarify any doubt.

Feedback and bugs are **really** appreciated.

Cheers!

*** UPDATE: I updated the download links to point to the general downloads page for each project, rather than a specific release. From each download page, you may download the "Beta" version for each project.

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.

[More]

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.

A couple of days ago I wrote a post talking about the new iteration of the HomePortals framework. Today I want to continue talking about the new features for this release. In the previous article I posted an example template of a sample HomePortals page showcasing the new API, today I want to go over the example of provide more insight into the new objects and methods exposed by the framework.

As a reminder, here is the code from the previous template:

index.cfm

if you want to see how the final product looks, click here.

Ok, so lets start from the beginning:

Setting Up The Environment

This line initializes the homePortals environment as a singleton on the Application scope. This reads all the default configuration settings, initializes and loads a few objects, and leaves everything ready for you to start rendering your homePortals pages.

Each HomePortals instance is bound to a specific path, which is where your application is located. This path can be a directory off the webserver root (like in this example), or even be the webserver root itself. To declare an application at the root level, just call the init method as init("/")

After HomePortals is initialized, we use our instance to call any methods, render pages, modify settings or anything else you want to do.

Now we need to need to start customizing our HomePortals instance to do whatever we want. Since what we want to do in our example is render a few RSS feeds, we need to show HomePortals how to do this. The way we do this is by adding "ContentRenderers". A Content Renderer is a little widget that is responsible for generating some kind of content. This content can be anything: rss feeds, calendars, external HTML content, cfincludes, etc. All content renderers are implemented as CFCs and must extend homePortals.components.contentTagRenderer. The details of their implementation go a bit beyond this example, but basically they just generate whatever output they need and return it using an output buffer.

You can take a look at the rss.cfc component included in the example files to see how a contentRenderer is implemented.

The following line illustrates how we can programmatically tell HomePortals about the content renderer that we want to use:

Here we are declaring a content renderer named "rss" and give the path to the corresponding CFC in dot-notation form. Note that you can define as many content renderers as you want or need.

That's all the environment configuration that we need. Now we can building our page.

Building a Page

HomePortals is all about modular content and reusability. For that purpose, everything that goes into the page is defined outside of the page itself, so that it can be reused multiple times across a site or application. Although our example consists of only one single page, we will define our "modules" or content widgets individually. We already saw that it is the content renderer that is the one responsible for knowing HOW to render the output. So we only need to tell it WHAT to render. In our case we just want three different RSS feeds. Let's use the feeds for this blog, the Railo blog and the DZone blog.

Defining the page content is really simple, we just need to do it declaratively using common structures. We need to create a struct variable for each of the widgets we want to add to our page. There are few keys that are used internally and have special meanings like "moduleType" and "title", but everything else will be considered an "attribute" of the widget and will be available to the content renderer to customize the output. The only required key on the struct is "moduleType", which is how you tell HomePortals which content renderer to use. Since we declared our RSS renderer with to be named "rss", then that's what we need to use for each widget.

In this example we are defining the three widgets to use the same content renderer (rss) but there is no restriction here, you can mix and match module types as long as you tell HomePortals about them.

Now it's time to assemble the final page:

Programmatically, all pages are represented as instances of the pageBean object. All the modifier methods in the CFC return the same instance, that way you can chain all your modifier methods together to form a mini DSL to define a page. I think each of the methods have pretty self-explanatory methods as to what each one does.

First, we are initializing the instance, then setting a page title, and setting a skin (this is a way to determine the look and feel of the entire page). Next we are defining three layout regions of type column, with names col1, col2 and col3. Finally we are assigning our widgets to each of the three columns with addModule(). The first argument is a unique identifier for the widget, the second is the layout region name where we want to place it and the third is the struct containing the widget attributes.

Rendering The Output

Finally is time to send something to the screen. This is done by the following lines:

We start by asking HomePortals to process our pageBean instance and prepare it for rendering. Here is where all the magic happens. HomePortals does its thing and the call to loadPageBean() returns an instance of a pageRenderer object. This is the guy responsible for actually spitting the HTML back to us, and HTML is what we get when we call its renderPage() method. Note that homePortals has not actually sent any content to the screen, it just has given us back the HTML for the page we declared, it is up to us to decide how that HTML will be used.

And so we output the generated HTML to our browser for the grand finale...

And here is a screenshot of how this actually looks:

Not bad for a few lines of code, isn't it?

On the next post I'll talk about other new features and fancy tricks.

For the last few weeks I have been working again on the development of HomePortals; picking up where I left a few months back and implementing a couple more ideas that I had. As I get closer to a final "3.1" release, I wanted to start sharing some info on what has changed and explain a bit more on the new features and what possibilities they open.

First of all, if you are unfamiliar with HomePortals it is basically a web-based framework to handle modular layout rendering. The whole point is to provide a declarative way of indicating which content goes where on a page.

Back To Basics

For this release I wanted to zero-in on making HomePortals a framework/environment that would be easy and even fun to program in. I focused a lot on cleaning up and removing everything that was not part of the "core" functionality or was not essential to the main goal of the project, which was to provide an engine to layout modular content on a web page.

This cleanup process led to two major changes:

• a) A more compact API and
• b) An extensible plugin architecture to extend the available features

A cleaned up and easier to use API
First, the directory containing the framework has now been renamed to a more consistent "/homePortals" instead of the awkward and potentially conflictive "/Home" of previous versions.

The whole application environment can now be contained on a single instance of the homePortals.cfc object, which can be initialized at its minimum just by passing the path to wherever the host application is located. No need for config files or special folder structures. You now have the option to completely configure an application programatically (calling a bunch of setters) or, as always, by having a config file with your settings. Its your choice.

So for example, if I want to use homePortals in an application with path /mySuperApp, I just need to have this line somewhere in my application code (Application.cfc, index.cfm, wherever you like):

And you don't even need to use the application.homePortals variable; you can put your instance anywhere. However, since IT IS a whole environment you may really want to consider using it as a singleton to avoid going through the initialization process again and again.

Once initialized, the homePortals instance lets you access any part of the HomePortals environment. You can modify its settings, call the high level features, and even go into a lot of the internal guts to get the exact behaviour you want.

The fact that the entire homePortals environment is contained within a single cfc instance also makes it very easy to integrate homePortals into existing applications or even other frameworks. This way you can have your application driven by your framework/non-framework of choice and still leverage the layout rendering features of HomePortals.

I already mentioned that the new API lets you do everything programmatically (previous versions required a lot of XML files). To give an idea of what kind of things it lets you do here is a brief cfm template that renders a three-column layout and places a small RSS feed reader on each one.

Note: For the purpose of this example, lets assume the following template is located at /testPage/index.cfm

I know there are a lot of things to explain here, and I will go by each one of those, but I think this gives an idea about the "feel" of what can be done programmatically in 3.1.

On the next post I'll go over the previous template explaining what is what, and then talk a bit about the Plugin architecture in 3.1

For now I am attaching to this post the necessary files to run the above example. The current beta for 3.1 can be downloaded here. BE WARNED THAT THIS IS A VERY EARLY BETA, SOME STUFF MAY NOT WORK AND MAY CHANGE BEFORE THE FINAL RELEASE!!!

Any kind of feedback is greatly appreciated.

Have fun!

To the couple of misguided souls that used to pay attention to my blog, you may have noticed that after an unfortunate db crash last year (resulting in loosing a couple of really interesting comment threads) I seemed to drop down from the face of the blogosphere and just abandoned completely my blog. Well, what really happened was that the last few months of 2008 and the beginning of 2009, have been pretty hectic in my life, sorta like a rollercoaster of life changes that took me (literally) from one corner of the country to the other.

First, I left a job I had had for a little more than four years to seek fame and fortune elsewhere. Working at Unique Vacations/Sandals Resorts was a very interesting experience; I made great friendships, learned from a master developer, and tried my hand at building/improving pretty interesting and high profile applications. But in the end I felt it was time for a change and that I had to move on. So I left Miami and headed north to Tampa.

In Tampa something extraordinary happened: our first child, Diego, was born. The experience of being a father for the first time is pretty unbelievable and way too much to put in words. We stayed in Tampa for a couple of months, while I worked for a little bit at a consulting/software company there. Then, with the turn of the new year, I was presented with an extraordinary opportunity to work together with some very smart people on a beautiful place called Oregon. So yep, at the beginning of the year, my wife, the baby and I, packed our things and flew cross-country to start a new life on the other corner of the country.

And so, here I am, living south of Portland, Oregon, surrounded by a beautiful scenery, working with a great team on challenging projects and technologies, and blessed with a wonderful baby and wife.

Finally, I already started working again in a couple of personal projects. Over the next few weeks, I'll post about some improvements for the next versions of HomePortals and ColdBricks to give an idea of where they stand, and hopefully get some feedback about them too.

Until then, have fun and code a lot.

*** 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 IS A REPOST OF AN EARLIER ARTICLE THAT GOT WIPED OUT ON A RECENT DB CRASH. ***

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.