ColdFusion on Aptana Cloud with Railo 3.1 Part III. URL Rewrites and Railo 3.1!

URL Rewriting is fun! Well, that may be a bit of an overstatement (to say the least), but it does describe where I am with my deployment of Railo to the Aptana Cloud.

This is what I love about the web development industry. As soon as you step away from a project, something new comes along to eff with you. I had to take a few days off this fun project to actually do some billable work (my dogs really, really want me to have enough money to buy them lots of treats). When I came back, what do I find? That Railo 3.1, the long-awaited, truly open-source version of the Railo CFML engine was released into the wild.

Yeah and ugh! Yeah because I've been waiting to get my hands on this version since last summer. Ugh because I finally decided to give up on waiting and deploy Railo 3.0 to this Cloud.

Of course, this isn't really a big deal. This morning, I simply redeployed my railo.war file to the Cloud. The deployment process cleared out the previous webroot folder and deployd the new WAR file. The only bad part is that I didn't realize that this would wipe out my CFML files and other assets. If I took a little extra time and read the bloody Tomcat documentation, I'd probably have avoided this :). No biggie, nothing more than uploading via SFTP again.

Railo 3.1 is now deployed and operational on my site in the Cloud. Now, as with before, it's back to the URL Rewriting in order to get Tomcat to respond as we wish with SES-style URLs.

In my previous post on Railo and Aptana Cloud, I mentioned learning of a tool, called UrlRewriteFilter, for Java servers (i.e., Tomcat).

Over the past couple of days, and with the help of others, I began to get a set of rewrite rules in place. Some of the rules I've used (thus far) to get ColdBox and Mango Blog rolling follow.


 \.(bmp|gif|jpe?g|png|css|js|txt|pdf|doc|xls|xml)$
 -


 ^/(CFIDE|cfide|CFFormGateway|jrunscripts|railo-context|fckeditor).*$
 -


 ^/(flashservices|flex2gateway|flex-remoting).*$
 -

A quick overview of the presented XML elements:
The rule element defines a URL rule -- duh :)! Each rule element must contain at least one from element and one to element. The from element is the requested URL as is. An example would be the URL you look at in your browser's address bar. It is to this element that we are applying a regular expression (the value of the from element). If our regular expression/text in the from element matches the incoming URL, the user is redirected to the value of the to element.

The first rule (above) ensures Railo (the CFMLServlet) will not process any requests for images or the other specified doc types. In this, and the other two rules listed above, the value of our to element is a dash ( - ). This tells the UrlRewriteFilter to not make any substitutions or otherwise with the request and 'go on like nothing happened.'

The second rule ensures we do not redirect requests for special applications, such as ColdFusion web administration, from being forwarded or redirected to our ColdBox application (based on the rules below.

The third rule has the same end result as the second but is more focused on remoting calls.



 
 ^/(.*)/(.*)$   
 /index.cfm?event=$1.$2 
 

 
 ^/(.*)/(.*)/(.*)$ 
 /index.cfm?event=$1.$2&id=$3

The two rules listed above handle all basic URL types that will come in with a very basic ColdBox application. The first of the two rules above will match any URL with the following format:
http://www.mysite.com/pages/view/3

If such a URL was requested on our application, our expression (the value of the from element) will match (in order) pages, view, 3 and store them in the variables $1, $2, $3 respectively.

The next and final step in this rule is to forward the request to a specific URL. In our case it is the default file (index.cfm) for the ColdBox application. We then build the appropriate URL query string onto the file we're calling: ?event=$1.$2&id=$3

The result is a behind-the-scenes request for the following URL:
http://www.mysite.com/index.cfm?event=pages.view&id=3

We've now 'decoded' our URL (www.mysite.com/pages/view/3) and instructed our ColdBox application to run the pages.view event and supplies that event with a variable id that has a value of 3. On a real site, this would most likely get a page from a database that has an identification value of 3 and then present that content to the viewer in the browser.

Two important notes, first, if you want the UrlRewriteFilter to stop trying to match rules on a given match, you need to set the last attribute of the to tag to true. This attribute's default value is false. I think this is important to know as you test your filters.

Second, when you are writing a value inside an XML element, you must escape the ampersand (&) as I did above. Your rule will not parse otherwise (and your XML will be invalid).

The second rule above does the same as the first but does not look for the third parameter.

This is a basic overview of some UrlRewriteFilter rules I put in place. Please note I am not offering these as the best way to use the UrlRewriteFilter. I'm just getting started and am posting this in the hopes it will help some other newbie. If anyone reading this has a suggestion or resource, please let me know!

This post, obviously, doesn't cover installation and usage of the filter itself. Be sure to check the project site for more details.

Comments

Aaron Greenlee

Helpful post. Thanks for sharing.

I am using ColdBox's SES Interceptor as well; however, I only applied a single rule after excluding unwanted requests: ^/(.*)$

Now, ColdBox's routes file can be used to manage all incoming routes. If an unknown route is called, I resolve it within ColdBox and send the HTTP 404 code while displaying results that best matched their url.

OOP When Done Right = Time Saver

Over the past couple of years, I've been trying to increasingly use Object-Oriented Programming (OOP) in my work/code. For the most part, I've done better and better but I know that I'm still nowhere near where a good OOP programmer would be.

One of the things that always tripped me up was getting the 30,000 foot view of OOP sorted out in my applications design and code. Sometimes I did it well, sometimes I didn't (well, more often than not, it's didn't).

I was working on refactoring (sooooo much more to learn on refactoring that it's actually kind of overwhelming) some Flex/ActionScript code in a PureMV-driven application I'm working on. Because I'm still new to PureMVC, I have these bouts of coding where I just throw everything in the component and sort it out into its appropriate location later. Today was one of those days...the sorting.

While sorting through some bad code to make it palatable code, I came across a situation where I had violated the DRY principle (Don't Repeat Yourself). I have several DataGrids in my application that have a date field. The dates returned from the Web Server are raw SQL Server dates (i.e., 12:15 00:23:59) that clearly need to be formatted! Since it's a DataGrid, I was creating a very basic Label Function for the appropriate column in the grid. As I skimmed the code, I realized that I wrote three functions (in three different views) that were nearly identical.

It was one of those, rather obvious, lightbulb moments. I extracted the common elements of the function, created a DataGrid date formatting class, and wrote a method (converting the unique elements of my three functions into parameters) to format the date and return a string.

My AS Class:

package *{
 import mx.controls.dataGridClasses.DataGridColumn;
 import mx.formatters.DateFormatter;
 
 public class XmlDateFormatHelper
 {
  private var dateFormatString:String = "EEE MMM DD, YYYY";
  
  public function XmlDateFormatHelper()
  {
   
  }
  
  public function formatDateForGrid( item:Object, col:DataGridColumn, dateField:String, formatString:String = null ):String
  {
   var formattedDate:String = "N/A";
   if( formatString != null )
   {
    dateFormatString = formatString;
   }  
   
   if( item[ dateField ] != null && item[ dateField ] != "" )
   {
    var dateFormatter:DateFormatter = new DateFormatter();
    dateFormatter.formatString = dateFormatString;
    formattedDate = dateFormatter.format(item.ScheduledRecallDate);
   }
   
   return formattedDate;
  }

 }
}

My component labelFunction:

private function formatDate( item:Object, col:DataGridColumn ):String
{
 var xmlDateHelper:XmlDateFormatHelper = new XmlDateFormatHelper();
 return xmlDateHelper.formatDateForGrid( item, col, "NameOfDateFieldInObjectOrXML" );
}

Where I previously had to maintain three separate labelFunctions on my DataGrids, I was able to create a single object that I could use across all three grids to format any kind of date.

I know this is an overly simplified example of a decent OOP practice but it was just so nice to finally see an OOP solution in the code and be able to execute it, if not ideally.

Mango Blog on Aptana Cloud with Railo 3.1 (CF-powered Cloud Apps)

On Thursday, I posted about getting Railo 3.1 running on Aptana Cloud, specifically using the UrlRewriteFilter to create the necessary rewrite rules in place for Tomcat. With Railo deployed and ColdBox running and accepting SES URLs, I deployed the open-source, ColdFusion-powered blog software, Mango Blog.

Deploying Mango Blog onto my Cloud instance was not quite as seamless as ColdBox. To start, the Cloud is slightly limited in that you cannot create your own Virtual Host without enabling root access**. Because I don't want to do this (see note below), I am running the blog from its directory (it's at www.imageaid.net/blog instead of blog.imageaid.net).

In my previous post, I noted a couple of UrlRewriteFilter rules I put in place to handle SES URLs for my simple ColdBox application. However, one of the rules for ColdBox is going to present a problem for Mango Blog: ^/(.*)/(.*)$

This rule will match www.imageaid.net/blog/ and redirect it to the main ColdBox application, which will then throw an exception because we have no handler called blog, etc. When you go to setup Mango Blog, you are redirected to an administration url (url.com/blog/admin). This URL also matches our rule and will redirect to ColdBox, resulting in an application exception being thrown.

We need to create a few (well, more than a few actually) Mango Blog rules.

 
 ^(assets|skins|feeds|api|admin|components)
 ^/blog/$ 
 /blog/index.cfm 
 
 
 ^/blog/admin/setup(.*)$ 
 -

The first rule first checks that the Request URI does not contain one of the character sets in the parentheses but does contain '/blog/' (www.imageaid.net/blog/ will be matched but www.imageaid.net/blog/feeds/ will not), the rule processes the to element and forwards the request to /blog/index.cfm, showing our blog's home page.

The second rule checks to ensure we're not in the specific administration setup pages. This rule may not actually be necessary but as I was working through the rule setup process, I needed it and just left it in there.

While UrlRewriteFilter is an excellent tool and a solid 'replacement' for Apache's mod_rewrite, it does lacks a couple of key features, namely %{REQUEST_FILENAME}, which provides the ability to test if a URL contains a file or directory. If the requested file is neither a file nor a directory, you can (re)direct the request to an appropriate URL. This makes handling SES-style URLs quite easy in Apache but not as easy when you use UrlRewriteFilter.

Because of this, and coupled with my craptacular knowledge of regular expressions, I ended up with a larger set of rules for Mango Blog. The reason for this is that, unlike ColdBox, Mango Blog uses several CFML files to handle various requests. For example, the CFML file post.cfm handles the retrieval and display of blog posts. The post page (post.cfm) only looks for one possible URL value (entry is its name). An example would be: www.imageaid.net/blog/post.cfm/my-first-post.

On the other hand, the CFML file archive.cfm handles the retrieval and display of archive entries based on several possible variables. The archive page (archives.cfm) might get archives by month and year (www.imageaid.net/blog/archives.cfm/date/2009/4) or by an alphanumeric category (www.imageaid.net/blog/archives.cfm/category/coldfusion).

With the other relevant CFML files, I need to expand the rules for my Url rewrites. Each of these key CFML pages (post, archives, author, and page) received one or more dedicated rules.

When Apache is serving the files, we can utilize the aforementioned variable %{REQUEST_FILENAME}, coupled with the [QSA] directive (attaching to a query string) to handle all URL rewrites. Since UrlRewriteFilter lacks both the REQUEST_FILENAME and the ability to append values to a query string ([QSA]), I've had to make a larger set of rules. I'm going to continue to try and improve these rules with improved regular expression skills (suggestions welcome!). In the meantime, they work and don't seem to have a negative impact on performance.

Mango Blog rules:



 
 ^(assets|skins|feeds|api|admin|components)
 ^/blog/$ 
 /blog/index.cfm 
 
 

 
 term=(\w*)
 ^/blog/archives.cfm/search/(.*)$ 
 /blog/archives.cfm?archiveType=search&term=%1 
 
 
 ^/blog/archives.cfm/category/(.*)$ 
 /blog/archives.cfm?archiveType=category&category=$1 
 
 
 ^/blog/archives.cfm/(date|author)/(.*)$ 
 /blog/archives.cfm?archiveType=$1&vars=$2
 


 
 ^/blog/(post|page).cfm/(.*)$ 
 /blog/$1.cfm?entry=$2 
 


 
 ^/blog/author.cfm/(.*)$ 
 /blog/author.cfm?alias=$1 
 


 
 ^/blog/feeds/(rss|atom).cfm/(.*)$ 
 /blog/feeds/$1.cfm?category=$2 
 

 
 
 ^/blog/admin/setup(.*)$ 
 -

Mango-Railo Gotcha
A reminder that when you run Mango Blog (1.3.x) on Railo (3.0 and 3.1), you need to go to the datasources section of your Railo administrator and deselect the database option to 'Preserve Single Quotes'. You can see a previous post for more (with links to other bits about it).

Notes:
**While this might not seem like a big deal (and in the big picture, it isn't), it (enabling root access) does nullify your support (well, it's not nullified but they don't have to provide support), disqualify you for managed software patches and updates, and compromise some management features (they may not work).

Comments

Craig Kaminsky

@Marty: Thanks for noting the ampersands! I actually use the HTML entities in my code but the conversion from Blogger's editor (and syntax hightlighter, I'm sure) they always get converted ... I should probably spend some time to figure that out :)!

Again, thanks for pointing that out and I'm very glad the rewrite rules are working for you.

Cheers,
Craig

Marty McGee

These rules work great!!! Thank you Craig for your time on this. However, make sure to change the ampersand & signs in the XML to their HTML equivalent & amp; (without the space) because the ampersand is a special xml character and as written will throw an error like "The reference to entity 'term' must end with the ';' delimiter".

Lines affected:
/archives.cfm?archiveType=search& amp;term=%1
/archives.cfm?archiveType=category& amp;category=$1
/archives.cfm?archiveType=$1& amp;vars=$2

Craig Kaminsky

updated the mango blog rules today to a (I think) complete set

Craig Kaminsky

@steven: I should be posting the rules later today or early tomorrow. The drawback has been that (so far as I can tell from the manual and API), UrlRewriteFilter doesn't allow conditionals in the 'to' element. But, I could be easily missing something and am still working on it. Thanks!

@sami: Thank you and I'll try :)!

Sami Hoda

Keep up these posts Craig.

Steven Parkes

I'm interested in seeing the whole set of rules. Seems like it shouldn't be necessary, so either I might be able to come up with something better or at least understand what makes it impossible.

ColdFusion on Aptana Cloud with Railo 3.1 Part III. URL Rewrites and Railo 3.1!

Comments

Disclaimer

Author

Craig Kaminsky

ColdFusion on Aptana Cloud with Railo 3.1 Part III. URL Rewrites and Railo 3.1!

Comments

Disclaimer

Older · View Archive (109)

OOP When Done Right = Time Saver

Comments

Newer

Mango Blog on Aptana Cloud with Railo 3.1 (CF-powered Cloud Apps)

Comments

Author

Craig Kaminsky