en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2005/10/16/80f56278e2416568dba888c30bc05ff4.html Sun, 16 Oct 2005 01:53:41 -0600 http://www.keithwatanabe.net/blogs/2005/10/16/80f56278e2416568dba888c30bc05ff4.html http://www.keithwatanabe.net/blogs/2006/1/2/c6bc0746e8129ded98b2f4f0d4f2474c.html Mon, 02 Jan 2006 02:55:38 -0700 http://www.keithwatanabe.net/blogs/2006/1/2/c6bc0746e8129ded98b2f4f0d4f2474c.html http://www.keithwatanabe.net/blogs/2006/2/13/2b44ba65cbc1537f2562f7c66cf7d89b.html Mon, 13 Feb 2006 08:13:42 -0700 http://www.keithwatanabe.net/blogs/2006/2/13/2b44ba65cbc1537f2562f7c66cf7d89b.html http://www.keithwatanabe.net/blogs/2007/10/13/bdfebbe853dae8856c306c974fd0b471.html
Well, the solution if you're using prototype is the following. First upgrade your prototype to 1.5.1+. You might have to use the beta to get it working. Next, do not send the JSON data structure as part of the response header from the server. You have to send it as part of the body. Use "Content-Type: application/json" as your header. Then display your data structure.

On the client side, you might have to modify your javascript if you're using Ajax.Request and utilize the convenience methods that automatically serialize JSON. For instance, if you have a function that looks like:

var ajax = new Ajax.Request(
url,
{
method: 'post', parameters: params, onComplet: someFunction
}
);

then in your function called someFunction, you probably will need to do something like:

function someFunction(r)
{
var json = r.responseText.evalJSON();
// do something with the json data structure
}

i was using the other form of:

function someFunction(r, json)

so the inbound data structure wouldn't get passed if the size was too big. this is a pain and hopefully they can address the convenience mode too. but it was a real pain handling this.

on a similar note, if you upgrade your prototype, you may also have to upgrade your scriptaculous javascript. Additionally, I ran into a "too much recursion" type of error. Geeze.]]> Sat, 13 Oct 2007 19:30:52 -0600 http://www.keithwatanabe.net/blogs/2007/10/13/bdfebbe853dae8856c306c974fd0b471.html http://www.keithwatanabe.net/blogs/2008/2/29/1180c6e83e1c8bf081761a3540944d4a.html killer Javascript framework called Ext JS. It's hot! Basically, it looks like Java Swing for Javascript. It's also quite huge at nearly 1 mb for the main file. However, I believe it's quite worth it. While I enjoy programming with JQuery because of the slick, simply style, Ext JS is far more powerful for building professional looking GUIs. It seems to have taken Java's Swing approach for creating UI components. Even some of the naming conventions appear to be the same.

This Javascript component architecture looks like the future of Javascript. Scriptaculous and even JQuery look ancient by comparison. Just to demonstrate some of the major adapters, you can see sites such as the Dow Jones Industries make use of the component as well as a few other sites. The main thing to me is that the components look good. You can create professional looking windows like the one linked below.

The primary negative issue I see is that the coding complexity increases drastically. Swing never was a fun API to work with. In fact, I think one of the primary reason that Java never took off as a purely client side programming language is that Swing's API was bulky and cumbersome. HTML was more comprehensible such that a kid could program it. Even scripting languages was smoother to program. With Ext JS, it seems as if we've just moved back to Java Applets. Secondly, the fact that the library is ENORMOUS, this is almost similar to the loading time of an applet. The only advantage here over an applet is that no JRE is required for the browser.

Regardless, the biggest contribution I can see is that this library and it's expansion could imply two things: the increase of the Web/Browser as the OS and the death of Windows. Combining the power of this library with other rich media, it's beginning to look like the need for Windows based applications is over. The biggest problem in Web 1.0 applications was the interface and lack of interactivity. Now, the interfaces have become incredibly sophisticated and interactive, making the need for Windows based applications nearly useless.

Whenever I see these elements come alive for the web, I keep thinking back to two things. First is the network computer as proposed by Larry Ellison from Oracle. He kept promising the network computer as being the huge thing. He definitely had the vision, but he was far ahead of his time. He even understood the cost. Unfortunately, because his timing was bad, his product couldn't sell.

I'm going to make a bold prediction here and say that 85% of the applications will be completely web driven in 5 years time.

The other thing that comes back to me is the constant battle between client-server computing. It seems inevitable that this battle will continue to rage as paradigms shift. Ultimately, I see the end form (to a degree) being a mixture of the following. A home server appliance that contains all user data. It will be open with tight preferences linking one to all the communities on the web. Users will have the option of backing up data through rentable massive online storage facilities similar to how one can put their furniture and items away in physical storage. Obviously, companies like Amazon (with S3), Google (Gdata), Box.net, XDrive, etc. are already in this market, but capacity will be in the petabytes range. Data will be segregated into fine grained segments such as photos, video, documents, etc. helping the user organize data. While we do have that now, what will follow is a greater number of these services as well as consolidation of such services that users can easily choose from menus during the backup/storage of their data. This is where the portal idea will make a major comeback, except that the interface will be designed in a slicker, more customizable manner. There will be a client loaded service on their local system that will also interface with the online backup utility. In turn, this will maximize the redundancy and privacy aspects of the user's data.

All terminals will be dumb in the household. Bill Gates recently stated that he sees the death of the keyboard. Well, I doubt that the written word will ever permanently cease. There's too much culture in written language that will kill it from history. However, in going back to the dumb terminals idea, I'm a firm believer that every room in the house will hold some form of interface to your data system and all major appliances will be intelligently interconnected with your local server. For business related points, the keyboard will still play a predominant role. Let's be honest here: unless there's a plug to read our minds, the keyboard will be a continued interface for creating ideas. I doubt that people are going to be dictating into a microphone. The psychology between writing and speaking are far too different (just as a simple example, my reading/writing skills for Japanese are far better than my listening/speaking skills). Not to mention, I doubt that most offices would really want to allow dictation in sending information between people. We just have to be practical about such issues.

Either way, the end vision again is going to be a hybrid because of psychological reasons. People want to own and control their data, where ownership means physical keeping in a tangible location. However, contingency and reliability require redundancy. I doubt these two axioms will go away anytime soon so we should start building with these elements of architecture and psychology in mind.]]> Fri, 29 Feb 2008 19:30:22 -0700 http://www.keithwatanabe.net/blogs/2008/2/29/1180c6e83e1c8bf081761a3540944d4a.html http://www.keithwatanabe.net/blogs/2008/3/6/49c4ff3f8272ab2df16fcd7af6e13195.html style tags. Inside, I used the ID selector to style a particular div element. In particular, I used a kind of display: none; thing.

Well, one of the things I needed was to be able to make that part visible again once a person unchecked that element. Before I was doing something like $(ele).style.display = '';. Turns out, that the precedence of Javascript is lower than the one in inline style. So to rectify this, I had to instead do $(ele).style.display = 'block' (or inline). Pretty annoying but a nice little fix to this problem.]]> Thu, 06 Mar 2008 09:14:44 -0700 http://www.keithwatanabe.net/blogs/2008/3/6/49c4ff3f8272ab2df16fcd7af6e13195.html http://www.keithwatanabe.net/blogs/2008/3/24/423d6c093438d6d70bdff11dba60f1c6.html Javascript library called WireIt. With this library, you can create Yahoo Pipes-like wires. But the key underlying technology is actually another Javascript library called excanvas. It's quite convoluted because excanvas is really a wrapper around VML that allows the dynamic shapes being drawn. WireIt also utilizes Yahoo's UI Javascript to handle events, drag and drop and some level of animation. It took some time to get over the initial hump for learning how to handle the thing. Right now, the hardest part is determining how to get the terminal nodes positioned. Once you get it all hooked up though, it's quite neat as you can create visual workflows with Javascript.

Also, I had been working a bit with extjs. I got to utilize the tree aspect. It felt a bit difficult, but again, it's something you gotta get used to. Lots of server programming to structure the output JSON for extjs to correctly format the tree. The library is quite big so there's plenty to learn. I like the fact that the library creates visually appeasing windows and components. My only criticism, outside of it doing the same thing that Swing does, is that it's kinda awkward to program. So far, only jquery has been easy to utilize.

Finally, at home I'm messing around with Amazon's Web Service system. I had long ago signed up for their API key, but never used it as I was too busy. Now, I found some interesting applications and will make use of it. In conjunction with Amazon's Web Service API, I'm using the Zend Framework. I've been quite critical of the majority of it. However, one nice thing is that it has several web service APIs bundled into their system. So today I finally got a chance to dig a little into those areas. It seemed a lot easier than creating my own parsing tool for handling the XML produced from the web service.]]> Mon, 24 Mar 2008 10:02:20 -0600 http://www.keithwatanabe.net/blogs/2008/3/24/423d6c093438d6d70bdff11dba60f1c6.html http://www.keithwatanabe.net/blogs/2008/6/25/8e2e3444eb720318c1c6a732b675db0a.html
While the author mentioned that the library might be released as a YUI widget, it's the original source code that makes it useful.

I don't know how useful a widget might be. Take Google search results for instance. You have to employ their sucky AJAX library to get the results you want. I prefer to have the raw data. Yahoo actually did a good job in allowing developers to retrieve XML data feeds from their search.

However, we're seeing the shoe on the other foot. Come on Yahoo! Yahoo Pipes is visually interesting for developers but it isn't that special. WireIt.js is one of the more useful Javascript libraries out there for doing data flows and potentially other visual applications that require connecting elements together.

Well, then again that's why all those people are leaving at Yahoo, right Mr. Yang? ;)]]> Wed, 25 Jun 2008 21:48:12 -0600 http://www.keithwatanabe.net/blogs/2008/6/25/8e2e3444eb720318c1c6a732b675db0a.html