Enigo Homepage
Client Login
User ID:
Password:

Inline Content Generation

You are writing an application for your department that will produce charts for displaying various system and database performance metrics. One of your requirements is that the images reflect the real time status of the systems. This presents a dilema. One approach would be to have your application generate the images, and then write them to temporary files on each request. Writing to the filesystem for a simple image request seems inefficient, though, and then you always have a potential issue with needing to cleanup the files later.

Another approach would be to create a seperate image server that returns nothing but images. The request into it could carry some parameters that describe which image to return. The system will generate the requested image and return it. This is a reasonable technique, and there may be some code maintenance advantages to having this one segment of the whole application isolated by itself, but there are some drawbacks, too. It is a seperate web application service that someone needs to ensure is running, and by seperating it from the rest of your application's code, there is a greater chance that you will have to duplicate code between your application and your image server.

Iowa offers a third alternative. You can let your application generate the images, and Iowa can return to it URLs unique to that one page that will return the generated resources. This inline content generation is a convenient way to deliver any sort of generated content such as charts and graphs or image data that is stored within a database.

The mechanism for this is a method provided by the session, resource_url(). The resource_url() method can be called in two forms. One is to pass into it a content body as and content type as strings, and the other is to give it an arbitrary list of arguments and a block.

In the first form, the content data and content type will be cached, and the method will return a URL that, when accessed, will return the cached data. In the second form the block will be called with the argument list provided. The block is expected to return an instance of Iowa::Resource that contains the content body and content type. The difference between these two methods is that the first form requires that the content be generated when the HTML for the page is being prepared for the response. The block method, however, only generates the content when the URL is actually accessed.

Do you have a comment or a suggestion?