SuperSatellite ||

By now, you might have heard of the new Adobe Integrated Runtime, otherwise known as AIR. AIR is aimed at allowing developers to create rich internet applications that are capable of running on a user’s desktop, regardless of operating system. Think Java, but geared more towards self contained web applications. It also results in comparatively superior looking applications. I mean come on, anyone else think Java is generally ugly?

The Adobe® AIR™ runtime enables you to have your favorite web applications with you all the time. Since applications built for Adobe AIR run on your desktop computer without a web browser, they provide all the convenience of a desktop application. Companies like eBay and AOL are using Adobe AIR to create exciting new applications that allow you to use their services on your desktop. In short, Adobe AIR means applications that are easier, more powerful, and more fun to use.

With AIR, you can slap some XHTML and Flash together, and create an application on it that can run independent of a browser. It’s finding wide adoption among crowds like Twitter users. Groups that are looking for applications to plug into a web site’s API (Application Program Interface). Check out Twhirl for an example, it’s what I use to keep up on Twitter. So, this is all super neat, right? Applications install with little more than a couple clicks, and can auto-update themselves to boot. Nice in Windows, but this could be invaluable in the Linux world. Can you guess why?

I run Ubuntu 8.04b on my laptop (I love installing 20 updates every day!). My desktop dual boots XP/Ubuntu (it swings both ways). I’m slowly transitioning to the geek side. But, I fall far short of calling myself a Linux guru (you may still refer to me as Sir, though). I can do anything in Windows, but in Linux…well…I’m like a sixteen year old boy on prom night. Actually, I’m getting much better than that, but for years the largest barrier to entry for me has been installing software. It has gotten easier with RPM’s, apt-get, and Ubuntu’s Add/Remove Applications interface, but if something isn’t listed you might find yourself jumping through a number of hurdles to get things going. And let’s be honest, how many “average” users could master the art of ./configure, make, and make install? Easy for a geek, hard for Grandma Jane (don’t hit me grandma!).

That’s where this whole AIR thing caught my attention. Turns out, Adobe has got an alpha version of AIR for Linux released. Keep in mind, it’s only for testing and not fully functional (like your mom), though I’ve only noticed a little graphical quirkiness so far. First off, the install is fairly painless (though must be done through the command line):

user@system:~$ wget http://download.macromedia.com/pub/labs/air/linux/adobeair_linux_a1_033108.bin
user@system:~$ chmod +x adobeair_linux_a1_033108.bin
user@system:~$ sudo ./adobeair_linux_a1_033108.bin

The installer pretty much does it’s own thing. From there, you can now find and open up an .air file for an application that you want to try out. Sizlopedia has got a nice list of 10 good AIR applications that you can start with. That’s where the whole gap bridging takes place. It’s almost like running your basic install.exe file. The browser will ask if you want to open it with Adobe’s handler (hint: you do), and it runs and installs like a Window’s app would for the most part. Painless. Simple. Easy (hint: also like your mom). And what makes it more perfect is that the process doesn’t differ between using Windows or Linux, so if you’re transitioning, it’d be completely familiar to you.

Which is why I ask the question: could this be part of the key to really mainstreaming Linux? It has always been my opinion that application installation has been the single largest barrier to entry Linux has faced in the general market. If this concept could be passed along to general application installation (like an RPM, only better), I think things would change rapidly. Naturally, that’s just my opinion. But it does make the OS and AIR based applications immediately useful, without any guessing, and that’s really what the install.exe-bred users need to smooth a transition to a new and foreign OS.

Today was a day of days for dotCMS and me. A couple weeks ago I started working on integrating a servlet into dotCMS to handle PHP code. This in part to learn if I could, and also because I know PHP way better than Java. It would also help to keep me from needing to rewrite chunks of code that I might want to keep using or from having to maintain a second server and connect it to Tomcat using mod_jk for the purpose of running PHP. Ideally, I wanted it all wrapped up in one, nice package.

Enter the Tomcat Wiki. That’s where I started out at, specifically this entry about using PHP. It definitely got me started. The only thing that was sorta sucky was that the method did not work with PHP5+. Only PHP4. But I figured I could live with that. Better than nothing, right? After spending two days hammering away at it, I gave up. I was able to eventually get rid of all the errors, but the end result was a big goose egg on code execution. I also wasn’t sure if it’d even work with the 4.4.8 codebase I grabbed from PHP. All around, I just decided this wasn’t a worthwhile course to follow.

Enter IRC, JT, and Quercus two weeks later. Jason got to talking with Chris and I about it yesterday in the IRC channel (#dotcms on Freenode), and pointed out Quercus. Quercus is a PHP servlet designed by Caucho for their Resin Java application server. Released under the GPL, no less. Unfortunately, at this time, their site sucks, the mailing list bounces, and the forums error out when trying to make a new account. So, I started sniffing around. Rob Sinner’s blog turned out to be a great starting place, and has the bulk of the information you will need. Quercus was also picked up and integrated into the Liferay project, which was where dotCMS started. I figured if they got it working, there’s no reason I shouldn’t be able to.

Here’s how it went down. Go get the current .war file from Caucho (3.1.5 as of right now). Extract it using 7-Zip, or some equally useful unzipping program. First off, copy the three .jar file (quercus.jar, script-10.jar, and resin-util.jar) into /common/lib or /common/lib/ext in your dotCMS root directory. Then, go into /liferay/WEB-INF (dotcms/WEB-INF in version 1.6 and up) and open the web.xml file. Add to it:

That sets up the servlet to handle files that it is told to handle that end in .php. There is a sample web.xml folder in the files you extracted from the .war file that has other stuff like datasource and php.ini designations if you want to connect to a database or use custom PHP settings.

Now, shutdown the dotCMS server if you haven’t already. Do an ant clean and ant deploy. Copy a test php file (I used a basic HTML page with <?php phpinfo(); ?> in it) into /liferay/html on the server’s file structure, and start the server back up. Now, you should be able to open the page http://www.yourdomain.com/html/test.php and see the result page above. dotCMS is set to refer to the real file structure when it sees the folder /html in a URI (Uniform Resource Identifier), rather than its internal virtual file structure.

The kicker that fouled us up originally is that you can’t execute PHP pages from within the dotCMS file structure, since it is a virtual file structure and all the files actually exist in /liferay/assets rather than where they appear in dotCMS’s file browser. If you upload a PHP file to a directory in the back end, it will just come out as a 404, because when the Quercus Servlet tries to call the file by dotCMS’s file structure, it can’t find it’s equivalent in the real server file structure. Get it?

The solution is to this is more complicated than simply making it so there’s a way to run PHP code, and I’m working on it with some help and might get it in to 1.6 if we get it figured out fast enough. We’re trying to modify the CMSFilter.java file and extending the QuercusServlet.java file with code from the SpeedyAssetServlet.java file to make it so that when a PHP file within the dotCMS file structure is dropped to the Quercus servlet, it has the ability to ask dotCMS where in the assets folder it is to execute it. In the mean time, the PHP works with the above solution so long as you store the file in the right place.

Following up the completion of one of our first successful forays into using dotCMS on campus, I thought it would be time to discuss what we did and how we did it, to give you an idea of what is possible within the platform. I mentioned in past articles that dotCMS is a powerful CMS (Content Management System) framework, you just have to assemble the pieces. Think of templates, structures, containers, and content like Lego blocks. You can have tons of them, different shapes and sizes, and depending on how you assemble them, you can control what the end result is.  This is exactly how you build more complex displays in the system.

That was the case with the Gorilla Geeks’ newsletter (alternate here). This was the first advanced usage we tackled, and we did so as part of a proof of concept to show others what we’d be able to do in the new CMS to help sell it around campus. It was created to provide a web page based newsletter that would have a URI (Uniform Resource Identifier) emailed out to people when new issues were made available (based on the schedule they settle on). Note that this was not a newsletter that was embedded in an email, and we didn’t use any of dotCMS’s CRM capabilities. The email just told people to visit the page. It is very similar to a blog, in that it has articles and categories. The main difference is how we display the articles and navigate.

Step one was to plot out how to arrange the content. I needed a way to refer to articles individually, or in groups by newsletter, or groups by category. That was clearly a relationship issue for the former, and category issue for the latter. I needed two content structures to do this. One was the “Blog/news item” structure. This already existed in the system and works well as a generic post-type content handler (title, body, image, tags). The second structure was one I created called “Newsletter.” This was a very basic structure that contained a publish date and an issue number. I then created a one to many relationship between newsletters and news items. What this means is that one newsletter could be related to many news items (Newsletter 1 could have 12 articles under it, Newsletter 2 could have 8). First you go in a make a newsletter, giving it an issue number. Then you create a news item, and on the relationships tab tell it that it’s parent is the newsletter that you just created. That solved the basic content question for the project.

Next I started looking at templates and functionality to actually make the display presentation work. The template provides all the basic display information up until articles show up; that includes the headline and sections region. Initially, the template checks to see if an article or issue number is passed in the URI and uses that to see if it needs to call a specific newsletter or if it should call the newest one. It also looks to see if the user has requested a printable version and will serve a custom CSS (Cascading Style Sheets) for that. As for the newsletter call, it starts with:

This is just checking to see if the $displayIssue variable was set (which happens on page load using $request.getParameter()), which indicates a preference for a specific issue. If not, it calls the current newsletter issue, and sets $displayIssue to that. All of this leads into the relationship needed to pull in the issue’s headlines, and the newsletter body, if needed. Once the page enters the body, we move to a container for generic web content. There, a widget is loaded that builds out the article(s) based on the request:

Basically, it figures out which of three Lucene queries to execute, and runs a loop to display them.  This allows one page to serve as the display mechanism for three different views: newsletter, category, single post.  Think of it kind of like how The Loop works in Wordpress.  I could just as easily kick them into another page for different views if I wanted, but that’s the benefit of widgets, which are cleverly crafted content items allowing dynamic content display somewhere that normally would require one piece of static content.

This ended up being a fairly simple setup: one relationship, one template, and one widget does this newsletter make.  With it, they get newsletter functionality, RSS, print versions, categorizing, search (via our Google Mini), and nice archiving.  The biggest catch is just making sure to tell a news item which newsletter it needs to relate to.  From here, I’d like to refine the theme and improve the usability some, but none of that changes the basic setup.  I’ll be happy to share more of the code with anyone if you like.

I felt it was time to take a closer look at a content management system I am getting very involved with. One might say I’m drowning in it. I prefer to think of it as being choked by it, heh. Really, it’s a very interesting system, and a fantastic tool for the price (free!). I have worked with a number of CMS (Content Management System)’s over the years: Coranto, e107, Joomla, Mambo, Wordpress, Drupal, and a few others that I’m sure I’ve forgotten about. It’s easy to get locked into one or two for various purposes, which had been true with me for a long time. The problem is, my short list there is only good for small to mid range sites. Now I’m webmaster for a site of better than 10,000 pages and 70+ editors. Those open source solutions don’t easily or always comfortably scale up to those needs.

That’s where enterprise grade content management comes into play. Swinging big price tags, naturally. You start learning names like RedDot, OmniUpdate, Hannon Hill Cascade Server, Serena Collage (discontinued), and Ektron cms400.net. You also learn they don’t come cheap, some breaking the $80,000 mark. $15,000 in this group is cheap. In some cases, you don’t even have to host it. But the support, features, and scalability you get from this class of tools is in a different league. Wouldn’t it be nice if you could get the best of both worlds though? Something like a Typo3 or Zope/Plone system, but with enterprise grade support and a learning curve within reach of your users? A tool that was open source to boot? Generally there just isn’t demand for this sort of software, at least not enough to make a successful project, it’s enterprise grade and enterprise cost because it’s an enterprise market. However dotMarketing has stepped up to the plate. They have developed dotCMS to augment their design and consulting business, but released it free, charging only for support.

I need to be fair though. dotMarketing really stood on the shoulders of the work done at the Liferay Portal project, that’s where it started. Liferay is the underlying framework that drives dotCMS, written in Java, and running on top of Apache Tomcat. But they forked the project and went a long way towards customizing everything you see and interact with. It isn’t just a fancy admin theme dropped over someone else’s work. It is also tied together intimately with Apache Velocity, which is very slick for writing dynamic templates. Needless to say, this isn’t a simple one-off , self contained type of application. It’s build on several different technologies, all open source, to try and provide the best of each tool to the end user. When you download it, everything is packaged up that you need though, you don’t have to hunt anything down separately.

This does make it more complex than other open source CMS options. Systems like Wordpress or Drupal can be installed to any server that runs PHP and a flavor of database server. On the other hand, dotCMS requires you to have root access to the server to install things like the Apache Tomcat server. This requirement has hurt dotCMS’s market penetration, as many web site owners do not have that kind of server access, opting instead for cheaper hosting solutions. That is a shame, because dotCMS is easily one of the most powerful open source options available, with a much shallower learning curve than equally flexible solutions (I’m looking at you Typo3). It’s also pretty resource intensive, so you won’t be dropping this onto a lightweight web server you built five years ago on an old AMD K6-2 system you had lying around. Plan on needed a couple gigs of RAM and a modern processor to heft it. You can run it in a dev environment in a PC okay, but not with less than a gig of RAM (I know, I tried, I failed). It might be open source, but it is truly enterprise grade, and is built for an environment that reflects such.

Part of what makes dotCMS so good is the way they approach content. As an administrator, you can create structures. These structures result in a form-like input system, that allows you to pull out some or all data for a type (say, a news posting, or product review). Any structure can easily be attached to an RSS feed. Each structure is unique, but can be dynamically related to one or other other types of content in other structures. For instance, you have a structure for “blog posts” and one for “comments,” and the comments can be related to blog posts. But you could also relate certain comments to articles, or news postings as well. This is a basic CMS feature used in most systems, but with dotCMS you see exactly how it works, and can modify or expand it. Better yet, create your own. Players related to teams related to sports. The flexibility allows you to develop to your heart’s content. And you don’t have to be a programmer to do it. Admittedly, relationships aren’t super easy to understand out of the gates, but an example or two gets you going. They really got things right with regards to how content should be created and used, and did a good job taking the cork out of the bottle for the end user to go nuts with it.

Speaking of examples, they do have a complete demo site running that allows you to both test things, and also see how certain things are accomplished. This can be very useful if you want to duplicate some kind of functionality, but need an example. They also outline plenty of macros that allow you to easily accomplish common tasks, like creating slideshows, navigation, MP3 players, RSS feeds, and more. One thing their demo site doesn’t showcase is that it can even run multiple domains through one back end, so you could be running demo.site.com, and blogs.site.com, and www.site2.com all through that one instance of dotCMS.

If you would have asked me before, I probably would have said that Drupal or Typo3 had the best permissioning systems available in open source. That’s no longer even remotely true. dotCMS has a fantastic permissioning system that allows granular access to both content and admin areas. Groups are used to define what a user has access to at the back end, while roles determine what they can use, see, and access with respect to content. This combines with a workflow system that can be used to make sure content is properly reviewed and approved before it hits the page. It’s simple, and it works. Well. On the user side, you can easily tie into an LDAP or Active Directory environment, though it requires manual set up. Users can be tracked through the system to provide some basic analytical data, and attached to CRM functionality to label, organize, and communicate with them. This goes far beyond any other competitive product in open source.

Where it’s lacking: documentation. Right now, it’s pretty scattered and different documents can be out of sync with others. I understand this is changing, and that they are moving to a system a la Apache’s documentation method. It is definitely needed. Luckily, their mailing list is pretty active, and they tend to be responsive on bug reports. I think it would be nice to see a little more stuff built in by default. For instance, dotCMS can be a blog, or host them, but you have to build the structures and relationships yourself. Tools like that are common enough that it wouldn’t hurt to just have it already set up. There is also no file structure, in the normal web sense, so no FTP (File Transfer Protocol) type functionality, you have to upload through the system or via WebDav, if your server supports it.

I will be at the dotCMS Open Minds Conference next week in Miami. After that (and maybe even during), I’ll be following up with some more detailed information regarding their CMS. I’ll get a bit more into how certain things actually work, and what we’re doing to make it work to our advantage. In the mean time, their portfolio can give you an idea of what the system is capable of.

Update (08.04.21): If you are looking for additional support, be sure to either check out the dotCMS mailing list, or visit our newly established forum community. Also, expect new and improved documentation and support tools from the dotCMS development team around the 3Q of 2008.

What follows is a slightly re-edited (for clarity) version of my thoughts on using Adobe Contribute to run a site. It was originally posted to the uwebd mailing list during a discussion of different CMS (Content Management System) options that are out there. This was in response to a question directed to me regarding what I considered a “modern website” with respect to Adobe Contribute.

Why isn’t Contribute equipped to handle large scale (~10,000+ pages) sites? Contribute doesn’t really have the tools to do anything with regards to content reuse across a site. So as a result, there’s no way to develop interactivity (well, really, you can’t develop anything with it, it’s not a developer tool). You can also forget about getting fancy by integrating things like RSS feeds, or dynamic content in any useful ways (consider, Department X wants a list of their courses for the semester, if they are copy/pasting, there’s no way to control that content once they have plugged it in, which hurts when they totally forget about it the next semester). Contribute is best at static content, on static pages. One page at a time. The newest version (CS3) has done marginally better, in that you can at least paste HTML source code now, but the actual audience that Contribute is aimed at won’t really find that useful. If they knew and understood HTML well, they’d be using Dreamweaver, or at least NVU or something. The crazy part is how good it looks on paper, that idea of simple content management. The reality isn’t that good, especially for developers who must then deal with all the deadwood Contribute leaves behind as things get updated, removed, etc (which is substantial). And don’t forget any template changes you have to make, which would have to be filtered into every file, which is very time consuming (we use SSI (Server Side Include) templates to help stave that issue off, but then that has also caused certain bugs preventing people from creating things like bulleted lists. Craziest thing I’ve ever seen).

I am of the mindset that Contribute has lost its market. It was a good tool five years ago. The game has changed a lot in that time though. A good CMS does everything that Contribute can do with no more of an end-user learning curve, but with the added bonus of being flexible for use with the better power users you serve. Contribute doesn’t have any room to scale up that way. Power users get frustrated in it, and basic users just get lost. The key is that a basic user is a basic user. Period. No matter how simple the software seems on paper, you still have to train them before they can use it, so you might as well give them a tool that not only does things easily, but does them right. For instance, workflow is a joke with Contribute, and as a result page management becomes nearly impossible (and in turn confusing for basic users). There is no review mechanism at all, so content can quickly become outdated and never addressed down the road. We have departments that have copied information from other parts of the site that is out of date by years. This is because they haven’t had the tools to do it correctly in the past.

Like I said, Contribute is designed to do one thing very well, edit static content on static pages. If that is all you want, go nuts, but try anything beyond that and it’s just a bad tool for the job. And in today’s web, a “modern site” is one that generally does not rely on static content this way.  Moreover, a “modern site” is one that also provides current, accurate, fresh data. If you have no ability to keep up on your content in some way, you are setting yourself up for failure. Anyone managing a large site knows that you can’t rely on the editors to simply take it upon themselves to review content (assuming that’s not their primary job).  People rely on web sites now, it’s one of their first stops when they want information on something. If they lose faith in the site as a tool to retrieve accurate information on the subject they want, then you lose a customer. The crazy, lock-me-up-I’m-going-cuckoo goal of a “modern website” is therefore to be omniscient in regards to their audience. You must have a current and correct answer to every question your visitors can and will ask. Totally impossible, I know, but it’s what the audience expects, and there are a lot of ways we can certainly fake it with current web technologies. I don’t feel Contribute is up to that kind of job (not by a long shot).

(Caveat: this is all based on my personal experience in our environment with ~70 Contribute users. We do not run the Contribute Publishing Server.  No doubt others might have more positive opinions.)