Dev411 Blog: Category ie

Catalyst - Customizing the view to stop IE from caching JSON

2006-07-25T10:49:00-05:00

Often times you'll want to customize your response specific to the View being used, e.g. setting extra headers. This can be done directly in your View class by creating a process method. All View base classes have a process method defined in Catalyst::View that gets called at rendering time. By adding a process method in your subclass and redispatching to the parent you can do some preliminary processing.

One use is preventing IE from caching JSON responses by setting the Cache-Control and Pragma HTTP response headers. You can do this in the application's JSON view as follows:

package MyApp::View::JSON;
use strict; use warnings;
use base qw/Catalyst::View::JSON/;

sub process {
  my $self = shift;
  my $c = $_[0];
  $c->res->header( 'Cache-Control' =>
    'no-store, no-cache, must-revalidate,'.
    'post-check=0, pre-check=0, max-age=0'
  );
  $c->res->header( 'Pragma' => 'no-cache' );
  $c->res->header( 'Expires' => 'Thu, 01 Jan 1970 00:00:00 GMT' );
  $self->NEXT::process(@_);
}

1;

Your process method will get called, set it's response headers and then use NEXT to call C::V::JSON's process method.

Automated web screen shots with Perl

2006-07-21T10:02:00-05:00

I've been looking for a program that will take full screen shots of web pages even when the web page is larger than the window size on my physical screen, requiring scrolling. This morning I found such a program in Petr Šmejkal's Win32::CaptureIE when it was mentioned by Displeaser on DevShed Forums in the "Screenshot of webpage" thread. It uses ImageMagick for image manipulation.

From reading the Win32::CaptureIE POD, the CapturePage function does exactly what I want:

CapturePage ( ) Captures whole page currently loaded in the Internet Explorer window. Only the page content will be captured - no window, no scrollbars. If the page is smaller than the window only the occupied part of the window will be captured. If the page is longer (scrollbars are active) the function will capture the whole page step by step by scrolling the window content (in all directions) and will return a complete image of the page.

After installing ImageMagick, Image::Magick and Win32::CaptureIE on my Windows / ActiveState Perl system, I generated this screen shot with the following short program using no additional processing:

#!perl
use strict; use warnings;
use Win32::CaptureIE;

StartIE( width => 900 );
Navigate( 'http://www.dev411.com/blog/' );

my $img = CapturePage();
$img->Write( 'capture.png' );
QuitIE;

Perl and CPAN continue to amaze me with their treasure trove of functionality. Are there similar tools for using Firefox, Linux, other image libraries or languages?

UPDATE: ishnid has found two programs with CLIs (posted to the same thread):

khtml2png on SourceForge. This is a command-line program that looks like it can be run without a browser. It uses libkhtml (used by Konqueror) and ImageMagick's convertn.
Pearl Crescent Page Saver, a commercial app but available in a free version. This is a Firefox extension and requires the browser.

UPDATE 2:: I recently tried Win32::CaptureIE with ImageMagick 6.3.0 and it doesn't work. Apparently there used to be a link to "PerlMagick" in older versions of ImageMagick that may not exist anymore. Unfortunately Win32::CaptureIE relies on PerlMagick.

UPDATE 3:: I just tried the free version of Pearl Crescent with Firefox 1.5.0.7 which it says it should support but I get a "Download error" with pageserverbasic-1.3.xpi.

Prototype - X-JSON fails on long value in IE

2006-06-01T15:14:00-05:00

Unlike Dojo Toolkit and other client-side AJAX libraries that read a JSON object from the response body, prototype.js reads it from the custom X-JSON header. I didn't run into any problems with prototype's approach developing on Firefox but I soon discovered IE 6 has a max header size that will cause prototype 1.5.0 rc0's evalJSON method to silently fail with an unreported [object Error] error. In my case, IE 6 would handle an X-JSON string with length of 138 bytes but would fail with a length of 1659 bytes. Firefox 1.5.0.3 and 1.0.7 worked fine with both strings. I'm not sure what IE 6's exact limit is but the fact there's a limit at all is discouraging IMO.

The argument I've seen for putting the JSON object in X-JSON is that you can put a separate large quanity of HTML in the response body. This design works well when you only have one or zero large quantities of HTML. As soon as you have two, you need to either put them both in the response body using another serialized data notation or put them both in the JSON object and put the JSON object in the response body instead of the X-JSON header. It seems better to simply expect the JSON object in the response body in all cases than in cases when there's only one or zero large return values.

Let's take a look at an example. In the following the one Ajax JSON response can return meta data about the overall response ("Result":"ok") as well as a list of "Posts", say when updating a post list on something like Digg's homepage. Further more a list of "Hot Stories" can simultaneously updated in the same request. Each one of the stories may have a description or overall information that exceeds IE 6's max header length.

{
  "Result":"ok",
  "Posts":[
    {
      "time":1149349580,
      "id":100001,
      "title":"Article 11 title",
      "desc":"Article 11 desc
         (longer than IE header length)",
      "votes":120,
      "comments":5,
      "submitter":"garfield"
    },
    {
      "time":1149349583,
      "id":100002,
      "title":"Article 12 title",
      "desc":"Article 12 desc
         (longer than IE header length)",
      "votes":125,
      "comments":15,
      "submitter":"garfield"
    }
  ],
  "Hot Stories":[
    {
      "time":1149348000,
      "id":1001,
      "title":"Hot Article 1 title",
      "desc":"Hot Article 1 desc
         (longer than IE header length)",
      "votes":1120,
      "comments":115,
      "submitter":"garfield"
    },
    {
      "time":1149349000,
      "id":1002,
      "title":"Hot Article 2 title",
      "desc":"Hot Article 1 desc
         (longer than IE header length)",
      "votes":1120,
      "comments":115,
      "submitter":"garfield"
    }
  ]
}

I understand where having a proprietary X-JSON header and a separate response body is useful however I view those situations as a subset of a more generic, and powerful, use. With more complex return values, putting the JSON object in the response body is ultimately a more flexible and extensible design.

I'll continue to use prototype for now but I'm going to set all my JSON objects in the response body and eval it myself given IE 6's short comings. A bigger concern for me is that I feel Prototype's use of putting the JSON object in X-JSON will encourage inefficient AJAX implementations that end up using more HTTP request/response cycles than necessary. I really hope prototype.js will move their auto-eval feature to operate on the response body due to this problem and to make it more compatible with other JS AJAX libraries at the same time.