Posted in json, catalyst, ie, ajax
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...
no comments
Posted in imagemagick, ie, perl
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...
4 comments
Posted in json, ie, ajax, prototype
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.
8 comments