Monthly Archive for May, 2006

More Batik Goodness

Last October I posted about using ColdFusion and Batik together to convert dynamically generated SVG content into PNGs for easier consumption. Well thanks to a little more digging and a post by Christian Cantrell, I've improved upon it further.

<cfscript>
  context = getPageContext();
  context.setFlushOutput(false);
  response = context.getResponse().getResponse();
  response.setContentType("image/png");
  transcoder = createObject("java", "org.apache.batik.transcoder.image.PNGTranscoder").init();
  inputStream = createObject("java", "java.io.StringBufferInputStream").init(svg);
  input = createObject("java", "org.apache.batik.transcoder.TranscoderInput").init(inputStream);
  outputStream = response.getOutputStream();
  output = createObject("java", "org.apache.batik.transcoder.TranscoderOutput").init(outputStream);
  transcoder.transcode(input, output);
  output.close();
</cfscript>

The primary difference here is that your SVG content comes from a string (rather than a file), and the PNG content will be sent directly to the browser, rather than stored in a file. If you're operating on files, not much benefit, but if you're generating your SVG on-the-fly every request and sending it directly out, cutting out all the filesystem access (four separate trips) can be a nice benefit.

As before, you need a full installation of Batik (WEB-INF/lib is a good place for it), and if you're on CF7, you'll need to remove the partial install in WEB-INF/cfform/jars as well.

EmailReader Details

Nathan Strutz commented on my last post about EmailReader that he didn't "get" it.  Looking back, I realized I didn't bother to communicate it's purpose very clearly in my post, so here's another one that should do a better job.

EmailReader is designed for being run from a scheduled task to do "something", where "something" is up to you.  You implement a handleMessage method that accepts information detailing a single message from the POP server, and you do something with it.  EmailReader will take care of some basic validity checks (valid sender, has a valid attachment, etc.), as well as post processing cleanup (deleting from the server, deleting downloaded attachments).

It can certainly be used interactively as well, but interactive checking requires a rather different mindset that this component doesn't accomodate gracefully. 

The specific use case was emailing pictures from my phone to my blog, but I wanted to create a general solution for emailing "stuff" to an application.  This is it.

I've posted the current draft of the CFCExplorer-generated docs for the component, so you can take a look.  Typos, inaccuracies, and whatever other issues are likely present; they'll be better before initial release.  Hopefully that'll better illustrate the scope of the component.  processMessages is the method called from your scheduled task, but handleMessage is the interesting one.

New Adobe.com and the Power of Flash

As is old news by now, the new Adobe.com is live, and they've done a great job.  In my mind, definitely eclipsing either the old Adobe.com or Macromedia.com in terms of design.  However, the demons of Flash bite again, and come with a huge helping of irony since Adobe is the purveyor:

The new Adobe.com's Flash Issues

EmailReader CFC 0.1 Nearing Completion

The first feature complete version of my EmailReader component is nearing completion.  I've got it all working with the exception of attachment and message deletion, and it's looking pretty nice.

I'd originally planned on making it an "abstract" base class that you would extend to add your application-specific functionality.  However, like so many initial designs, further reflection illustrated that the standard "favor composition over inheritance" recommendation applied here too.  So while I've left in the ability to extend the component and override the default handleMessage method, I've also provided support for supplying a message handler to the instance that must provide the same method.

In reality, only the latter is supported and the message handler just defaults to this, but the effect is the appearance of supporting both.  Oh abstraction, once again you save the day.

Hopefully I'll get the delete methods and some docs banged out, and release a first version this week (under a liberal license, of course).  But no promises.