Content Repositories

Managing content vs. data is something that is becoming more clear to me in recent months. Over the last 2 years I’ve had the opportunity to get familiar with XML repositories (mainly MarkLogic Server) but did not really see the benefit of using such a technology outside of an enterprise-search-like application. MarkLogic provides a rich search API that includes content processing and enrichment along with some other pretty powerful features. All of this functionality is great but what if your project budget can’t accommodate the steep price? Are lesser known or open source content repositories still worth it?

I think so. First - what does it really mean when someone says their application manages content vs. data? In most cases, content and data can describe the same type of information but vary significantly in terms of extensibility. Data has a rigid structure that can be difficult to change over time while content tends to have a less rigid structure that can absorb additions and transformations more gracefully over the life of an application or solution. With that loose distinction between content and data in place picture using an XML repository to store messages exchanged in a SOA publish / subscribe paradigm. The messages will most likely evolve over time requiring developers to update the storage and retrieval mechanisms traditionally involving the update of relational queries in the application along with the structure of the database. Since XML repositories don’t have a set structure – developers are only concerned with how to retrieve the information and don’t need to concern themselves with the semantics behind storing the document (message validation isn’t included in this discussion).

This use case is fundamental and primitive but hopefully illustrates a key benefit for those looking to distinguish managing content from data.

The window.open Saga

A while back I encountered a strange problem with window.open() Javascript function. The offending Javascript looked like this:

  window.open('someurl.aspx', 'My Window');

The code seemed to work fine in Firefox but I got an error when trying to evaluate the expression in Internet Explorer 7. I went crazy trying to figure out what was wrong with my code and soon found the space ' ' in the second parameter ('My Window') was causing the problem. If replaced the space with an underscore (i.e., 'My Window' -> 'My_Window') the error disappeared. I noticed that if I would've read the Mozilla JS documentation (https://developer.mozilla.org/En/DOM/Window.open) I would've seen the warning about not putting a space in the window name but I didn't. However the issue was related to IE7 I turned to Microsoft's documentation (http://msdn.microsoft.com/en-us/library/ms536651%28VS.85%29.aspx) and it should be no surprise that the no-space-in-the-window-name isn't mentioned anywhere.

Quality of Documentation

I spend a lot of team reading API documentation to try and figure out how a particular function works, or most likely, I use the documentation to determine how a set of API calls work together to produce a desirable outcome. On most days I don't consider myself to be one of those developers "who just gets it" so I rely heavily on the completeness and quality of the documentation to complete my task in a timely fashion. Recently I have been developing with Java during the day and PHP (more specifically Drupal) by night. I thought juxtaposing (don't you just love that word?) the documentation for the Java platform with Drupal would provide some meaningful insight for updating Java's javadoc utility.

Since Java's inception, the language has grown to an unimaginable size encompassing everything from Desktop to Enterprise to Mobile development. The javadoc utility has remained consistent throughout each release and produces the same clean, intuitive documentation today as it did several years back. In my opinion Java makes it easy to create quality documentation and the platform documentation that Sun's staff puts out is clear, concise, and objective. Enter the API documentation for Drupal.

The documentation for Drupal is not auto-generated. Someone has to sit down and document a function and then publish the documentation for the rest of the world to see. Pulling yourself away from the code to the documentation will result in a lower quality of documentation because the developer will need to make a mental note to go back through code and extract the documentation - this may not happen as scheduled resulting in incomplete platform documentation. As a result of this, Drupal's documentation is concise but does not provide a big picture view of how a particular function interacts with related functions. Despite this shortcoming, the source code for each function is included with the documentation allowing a developer to dive right into the details to figure out how to best use the function. Additionally, the documentation includes a search utility that makes it easy to find the specific function you're looking for without knowing its exact signature.

PHP and Java differ greatly in functionality so I wouldn't want to see the javadoc utility get cute with an autocomplete, search utility but I would think Sun would update the javadoc utility and provide a "web 2.0" approach to the generation of their documentation. Scrolling through ALL the classes is getting a little old. Has anyone seen a third party javadoc utility that provides a "richer" experience?

Auto refresh div using jQuery and Drupal

Recently I had to figure out how to automatically refresh a Drupal block every 5 minutes. The concept is simple enough but since I am new to jQuery (javascript in general really) and Drupal it was difficult for me to find a straight forward example. What follows is step-by-step example of how I solved the problem...

1. Wrap the content you want to refresh in a <div> tag and give it a meaningful class name or ID (e.g., auto--refresh). The class name (or ID) is arbitrary as you will see in later steps. For example:
   
<div class="autorefresh">
Put something here. It will get updated at a set interval.
<div>

   


2. Create a menu function in Drupal to map the AJAX calback:
   
function blockupdate_menu() {
  $items = array();
  $items[] = array(
    'path' => 'blockupdate/update',
    'callback' => 'block_update',
    'type' => MENU_CALLBACK,
    'access' => TRUE,
  );
  return $items;
}

   


3. Implement the function that assembles the data to get sent back to the browser:
   
function block_update() {
  //The get_data() function is generic here
  //Use this function to get the updated data for display
  $html = get_data();
  print drupal_to_js(array('html' => $html));
  // The exit() call is critical!
  exit();
}

   


4. Implement the client side callback function in jQuery:
   
function autoupdate() {
  $.ajax(
  {
    type: "POST",
    url: "blockupdate/update",
    cache: false,
    success: function(data) {
      var result = Drupal.parseJson(data);
      $("div.autorefresh").fadeIn("slow").html(result['html']);
    }
  });
}

   


5. Use the setInterval Javascript function to perform the auto refresh:
   
if( Drupal.jsEnabled ) {
  $(document).ready(function() {
    setInterval("autoupdate()", 5 * 60000);
  });
}

   Note that the first parameter is the jQuery callback function and the second parameter is the time that will elapse in between a refresh, in milliseconds.

That's all there is to it really! To debug the new functionality make sure you have Firebug extension installed in Firefox and watch the traffic do a full roundtrip with updated content. It's also a good idea to set your interval to no more than a few seconds at first to ensure everything is working properly. Don't forget to read my last post on some of the lessons I learned while exploring jQuery inside of Drupal.

Things you should know about jQuery and Drupal

So in my last post I told you how much I love drupal. Although I had been using drupal to build a web app I hadn't been making use of jQuery at that point. jQuery is almost necessary if you want to add visual effects (client-side) and/or use AJAX within drupal. It was somewhat painful for me to get motivated enough to learn jQuery as I felt there was not a good starting point so in this post I'd like to establish some really basic guidelines for new Drupal developers who wish to use jQuery and do not wish to dig through the Drupal forums or sit through long, sleep-inducing screencasts.

Here's what I learned so far:

• Don't bother with "inline" jQuery via the drupal_add_js function...inline Javascript isn't cacheable and you WILL get bitten when trying to escape quotes. Create a separate .js file and put all of your jquery in it instead - then use drupal_add_js to link to your Javascript.


• Spend some time browsing visualjquery.com and don't move past it until you are comfortable with jQuery's syntax...you really will like it once you get going


• Watch out for relative vs. absolute paths when including external Javascript (jQuery) files within a Drupal module. Use drupal_get_path to build your paths for you.


• Firebug is your friend

Is this advice simple and perhaps somewhat contrived? You bet. Finding this advice all in one place isn't all that easy so I felt it was my duty to post it! And finally, for the love of god, if you are trying to create a sweet lightbox effect inside your web app, steer clear of Facebox and try your luck with ThickBox instead. :-)

Stay tuned as I raise the bar further and use jQuery inside of Drupal to bring my first AJAX module to life.

Drupal

I've been working with Drupal a lot in my spare time. Since my experience with PHP and CMS's is limited at best, starting out with Drupal was somewhat slow going because most of the documentation/tutorials provide contrived examples that require the reader to do some non-trivial extrapolation. After spending a few weeks getting familiar with Drupal's architecture and a few more researching best practices, it is easy to see why there is a large, active community supporting novice and experienced Drupal developers alike.

The Drupal community is constantly providing and supporting modules that further reduce development time and make the process of developing a complex web application more efficient and enjoyable. Support for a large number of themes make it easy to create a professional looking site without requiring extensive knowledge of CSS or graphic design.

If you're looking to put pull off a large web application and don't want to worry about the mundane infrastructure, give Drupal a shot!

You're OK with .NET?

So sue me, I think Visual Studio is a damn fine product. I'd like to elaborate on why, despite Visual Studio's cool factor, I think the majority of .NET products end up being crap.

From talking with a few .NET developers and working with .NET a little lately, I have come to realize that Microsoft forces developers into design patterns and makes it easy for developers to get comfortable with Microsoft dictating their programming style (amongst other things of course). Granted it's not impossible to break out of the canned design pattern(s) but Microsoft would much prefer if you just used what they give you. Microsoft is like the parents in the movie The Christmas Story when they make their son, Ralph (aka you the .NET developer), put on the pink bunny suit. Ralph didn't want to do it but it was easier than starting a fight on Christmas morning.

Why you wouldn't free the developer to make their own decisions is beyond me but I guess developers who pay an arm and a leg for a IDE don't want the extra burden of a white board session or two. All in all Visual Studio is perfect for the lazy developer...you don't have to go through that strenuous activity of thinking about architecture and feel perfectly comfortable doing things such as mixing up business logic with the presentation stuff. It's a good thing you sold all those crazy books on logic and theory for beer money after all because you won't be needing them here.

Before you think I'm being to negative - don't get me wrong, it's entirely possible to build a .NET application that goes above and beyond. Myspace.com is the biggest website out there and that's powered by ASP.NET (come on, who said good products have to be visually pleasing?). Microsoft has a large influence in the enterprise and attract a lot of brilliant developers who hammer away at mission critical applications day in and day out with nary a hiccup. The real issue I still have with .NET is that it makes lazy developers even lazier and those developers end up thinking they are smarter than they really are. There I said it, .NET developers can be successful but they really need to think before they code and they need to keep in mind that it is OK to break free from Microsoft once in a while.

Yea it's rant, yea I haven't posted in a while, but this topic is something that reinforces my frustration with developers who focus entirely on the monetary aspect of software development instead of appreciating the art that it really is. Let me leave you with this last comment, how many happy, inspired .NET developers do you see out there?

Rails

So I've been trying to be more open minded lately, especially when it comes to web development. I decided a few weekends back to take a serious look at RoR and I can easily say it was time well spent. Once you get over the initial setup, you can see how easy it is to develop a web application in a fraction of the time it would take if you were using a competing technology (OK, Java Web Development is the only comparison I really have...).

It has been tough for me to get excited about web development because, to me, a simple task becomes overwhelming due to the amount of code and configuration one must perform. Ruby on Rails has me excited in a big way...And yes I have done my fair share of reading about scalability issues. Captain Obvious says, scalability is always an issue regardless of the underlying technology! Yay for Moore's law (you better appreciate it while it's still around).

Restarting

The title of this post is multi-purpose. This blog has been desolate all summer so I am "restarting" this blog as we move into the fall. I have been busy learning all about the wonderful technologies that make Java web applications run and can't wait to forcefully share my wisdom to my loyal reader(s).

One thing I have decided about Java web apps is restarting your web container of choice is a real pain if its done as often as one would build a Java desktop app. You see, everytime a change is made, the new class files must be deployed to the web container and the web container must be restarted. Restarting a web container can take anywhere from 1 to 30 seconds depending on the size of your web application. At the time of this post most restarts of my web container take 25 seconds plus giving me an opportunity to break away from work, surf unproductive web sites, and totally forget what I was doing by the time the web container comes back online. Fabulous.

Java User's Group

Being new to the Albany area (and a quasi urban surrounding in general), I recently had the opportunity to attend my very first Java User's Group (http://www.cdjdn.com). There were two presentations, the first was from the creator of Sleep an open source scripting language loosely based on Perl with an Objective C-like syntax and the second was from the author of Netbeans 5.5 Enterprise Edition. I was lucky enough to win a free copy of the netbeans book which rounded out my experience with the folks from CDJDN. If you are in the Albany area or know of a local JUG in your hometown, I highly recommend attending a meeting or two.