json iconcatalyst iconie icon

Catalyst - Customizing the view to stop IE from caching JSON

Posted in , , , Tue, 25 Jul 2006 15:49:00 GMT

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.

Read more...
del.icio.us:Catalyst - Customizing the view to stop IE from caching JSON digg:Catalyst - Customizing the view to stop IE from caching JSON reddit:Catalyst - Customizing the view to stop IE from caching JSON spurl:Catalyst - Customizing the view to stop IE from caching JSON wists:Catalyst - Customizing the view to stop IE from caching JSON simpy:Catalyst - Customizing the view to stop IE from caching JSON newsvine:Catalyst - Customizing the view to stop IE from caching JSON blinklist:Catalyst - Customizing the view to stop IE from caching JSON furl:Catalyst - Customizing the view to stop IE from caching JSON fark:Catalyst - Customizing the view to stop IE from caching JSON blogmarks:Catalyst - Customizing the view to stop IE from caching JSON Y!:Catalyst - Customizing the view to stop IE from caching JSON smarking:Catalyst - Customizing the view to stop IE from caching JSON magnolia:Catalyst - Customizing the view to stop IE from caching JSON segnalo:Catalyst - Customizing the view to stop IE from caching JSON

no comments

imagemagick iconie iconperl icon

Automated web screen shots with Perl

Posted in , , Fri, 21 Jul 2006 15:02:00 GMT

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.

Read more...
del.icio.us:Automated web screen shots with Perl digg:Automated web screen shots with Perl reddit:Automated web screen shots with Perl spurl:Automated web screen shots with Perl wists:Automated web screen shots with Perl simpy:Automated web screen shots with Perl newsvine:Automated web screen shots with Perl blinklist:Automated web screen shots with Perl furl:Automated web screen shots with Perl fark:Automated web screen shots with Perl blogmarks:Automated web screen shots with Perl Y!:Automated web screen shots with Perl smarking:Automated web screen shots with Perl magnolia:Automated web screen shots with Perl segnalo:Automated web screen shots with Perl

4 comments

json iconie iconprototype icon

Prototype - X-JSON fails on long value in IE

Posted in , , , Thu, 01 Jun 2006 20:14:00 GMT

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.

del.icio.us:Prototype - X-JSON fails on long value in IE digg:Prototype - X-JSON fails on long value in IE reddit:Prototype - X-JSON fails on long value in IE spurl:Prototype - X-JSON fails on long value in IE wists:Prototype - X-JSON fails on long value in IE simpy:Prototype - X-JSON fails on long value in IE newsvine:Prototype - X-JSON fails on long value in IE blinklist:Prototype - X-JSON fails on long value in IE furl:Prototype - X-JSON fails on long value in IE fark:Prototype - X-JSON fails on long value in IE blogmarks:Prototype - X-JSON fails on long value in IE Y!:Prototype - X-JSON fails on long value in IE smarking:Prototype - X-JSON fails on long value in IE magnolia:Prototype - X-JSON fails on long value in IE segnalo:Prototype - X-JSON fails on long value in IE

8 comments