OscarArevalo.com - Homeportals

Version 3.1.570 Released

Thu, 15 Apr 2010 18:46:00 -0500

The new update for HomePortals is now released. The current version is 3.1.570; This is a roll up of all the latest bug fixes since the last release. If you use the nightly build then you will not notice any difference right now. The full post about what is new/fixed on this release is here: http://www.homeportals.net/blog/index.cfm/2010/4/15/Version-31570-Released All comments are welcome!

Introducing the New HomePortals CMS Plugin

Mon, 01 Mar 2010 00:09:00 -0500

A few days ago I released the latest update to the HomePortals framework and its counterpart management platform ColdBricks. Besides the obligatory bug fixes and improvements, there was one new major feature on this release: the CMS Plugin. The CMS Plugin is a HomePortals extension to provide content management and site administration features to any HomePortals-based application without requiring the use of an external application (like ColdBricks) or building your own administration features. [More]

Available Update for HomePortals and ColdBricks

Wed, 24 Feb 2010 17:35:00 -0500

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. [More]

Model-Glue / HomePortals Sample Application

Tue, 17 Nov 2009 18:10:00 -0500

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. [More]

miniwiki: a minimalist wiki

Mon, 02 Nov 2009 02:10:00 -0500

Miniwiki is a very basic and light wiki application for any CFML engine. Although it is designed to have a very small footprint, it can be easily customized in terms of skinning and layout. miniwiki uses a subset of reStructuredText as the syntax for the wiki pages, although it is trivially simple to replace the rendering mechanism to use WikiMedia syntax using the WikiConverter project. miniwiki uses HomePortals as the layout engine and also to manage and store the content. miniwiki is entirely file-based, although since it uses HomePortals resource libraries to store content you can also make it store content in something more exotic as Amazon S3. Here is a demo, and you can download the project from RIAForge here.

HomePortals/ColdBox Integration Revisited

Fri, 30 Oct 2009 14:50:00 -0500

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. [More]

ColdBricks 1.1 Update: Custom Resource Libraries & Extension Modules

Tue, 27 Oct 2009 17:57:00 -0500

A new update to ColdBricks CMS is now available for everyone to download and play. This is still part of the greater 1.1 release but it adds some new interesting features that I thought would be interesting to blog about. Besides the obligatory bug fixes/performance enhancements, the two most prominent features are Custom Resource Libraries and the completion of a full modular architecture, including the option to install/uninstall modules directly by the end user. [More]

Launched 2 New Homeportals/ColdBricks powered Websites

Thu, 01 Oct 2009 01:59:00 -0500

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. [More]

Anyone wants to help test the new ColdBricks CMS?

Wed, 24 Jun 2009 15:26:00 -0500

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.

So, How about a templating engine for BlogCFC?

Fri, 08 May 2009 02:40:00 -0500

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]

Using jQuery.UI.layout to handle HomePortals layouts

Mon, 06 Apr 2009 18:57:00 -0500

** Update: ** Updated code examples and attached file to be compatible with HomePortals 3.1.570 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:




	Using jquery UI Layout with HomePortals. Example 1

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, 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.cfm

Here we declare all the necessary 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


$(document).ready(function () {
	$('body').layout({ applyDefaultStyles: true });
});

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. pageTemplate.htm



	
		$PAGE_TITLE$
		$PAGE_HTMLHEAD$
	
	
		$PAGE_CUSTOMSECTION["HEADER"]$
		$PAGE_LAYOUTSECTION["REGION"]["DIV"]$
		$PAGE_CUSTOMSECTION["FOOTER"]$

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. 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". 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: default.xml




	Using jquery UI Layout with HomePortals. Example 1

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.

HomePortals 3.1 Beta (Part 2)

Fri, 27 Mar 2009 20:53:00 -0500

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



   // initalize homePortals    

   application.homePortals = CreateObject("component","homePortals.Components.homePortals").init("/testPage/");
   application.homePortals.getConfig().setContentRenderer("rss","testPage.rss");


   // declare modules    

   feed1 = {
		 moduleType = "rss",
		 href="http://www.oscararevalo.com/rss.cfm",
		 title="Oscar Arevalo's Blog"
	  };

   feed2 = {
		 moduleType = "rss",
		 href="http://www.railo.ch/blog/rss.cfm?mode=full",
		 title="Railo Blog",
		 maxItems="3"
	  };

   feed3 = {
		 moduleType = "rss",
		 href="http://www.dzone.com/links/feed/frontpage/rss.xml",
		 title="DZone.com",
		 maxItems="10"
	  };


   // assemble page    

   oPage = createObject("component","homePortals.Components.pageBean")
		 .init()
		 .setTitle("My News Page")
		 .setSkinID("rounded")
		 .addLayoutRegion("col1","column")
		 .addLayoutRegion("col2","column")
		 .addLayoutRegion("col3","column")
		 .addModule("mod1","col1",feed1)
		 .addModule("mod2","col2",feed2)
		 .addModule("mod3","col3",feed3)
	  ;

   // load and render page   

   oPageRenderer = application.homePortals.loadPageBean(oPage);
   html = oPageRenderer.renderPage();



#html#

if you want to see how the final product looks, click here. Ok, so lets start from the beginning: Setting Up The Environment


   // initalize homePortals    
   Application.homePortals = CreateObject("component","homePortals.Components.homePortals").init("/testPage/");

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:


   application.homePortals.getConfig().setContentRenderer("rss","testPage.rss");

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.


   // declare modules    
   feed1 = {
		 moduleType = "rss",
		 href="http://www.oscararevalo.com/rss.cfm",
		 title="Oscar Arevalo's Blog"
	  };

   feed2 = {
		 moduleType = "rss",
		 href="http://www.railo.ch/blog/rss.cfm?mode=full",
		 title="Railo Blog",
		 maxItems="3"
	  };

   feed3 = {
		 moduleType = "rss",
		 href="http://www.dzone.com/links/feed/frontpage/rss.xml",
		 title="DZone.com",
		 maxItems="10"
	  };

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:


   // assemble page    
   oPage = createObject("component","homePortals.Components.pageBean")
		 .init()
		 .setTitle("My News Page")
		 .setSkinID("rounded")
		 .addLayoutRegion("col1","column")
		 .addLayoutRegion("col2","column")
		 .addLayoutRegion("col3","column")
		 .addModule("mod1","col1",feed1)
		 .addModule("mod2","col2",feed2)
		 .addModule("mod3","col3",feed3)
	  ;

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:


   // load and render page   

   oPageRenderer = application.homePortals.loadPageBean(oPage);
   html = oPageRenderer.renderPage();

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...



#html#

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.

HomePortals 3.1 Early Beta

Mon, 23 Mar 2009 20:35:00 -0500

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



	// initalize homePortals
	
	application.homePortals = CreateObject("component","homePortals.Components.homePortals").init("/testPage/");
	application.homePortals.getConfig().setContentRenderer("rss","testPage.rss");

	
	// declare modules
	
	feed1 = {
			moduleType = "rss",
			href="http://www.oscararevalo.com/rss.cfm",
			title="Oscar Arevalo's Blog"
		};

	feed2 = {
			moduleType = "rss",
			href="http://www.railo.ch/blog/rss.cfm?mode=full",
			title="Railo Blog",
			maxItems="3"
		};

	feed3 = {
			moduleType = "rss",
			href="http://www.dzone.com/links/feed/frontpage/rss.xml",
			title="DZone.com",
			maxItems="10"
		};
	
	
	// assemble page
	
	oPage = createObject("component","homePortals.Components.pageBean")
			.init()
			.setTitle("My News Page")
			.setSkinID("rounded")
			.addLayoutRegion("col1","column")
			.addLayoutRegion("col2","column")
			.addLayoutRegion("col3","column")
			.addModule("mod1","col1",feed1)
			.addModule("mod2","col2",feed2)
			.addModule("mod3","col3",feed3)
		;
	
	// load and render page		
	
	oPageRenderer = application.homePortals.loadPageBean(oPage);
	html = oPageRenderer.renderPage();



#html#

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!

Back to blogging

Mon, 16 Mar 2009 03:27:00 -0500

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.

Using HomePortals and ColdBox Together

Fri, 20 Jun 2008 19:32:00 -0500

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:




	/hpcoldbox/
	/hpcoldbox/accounts/

accounts-config.xml.cfm





	
	/hpcoldbox/accounts/

	
	xml
	/hpcoldbox/accounts/accounts.xml

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:




	HP+ColdBox

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:


#renderView()#

The last piece was updating the view (views/home.cfm) in the same way.



#html#

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!