Category Archives: Web Development

Articles on Web development.

Internet Explorer 6 Disappearing Images and Text

There is a strange bug in Internet Explorer 6 that causes images or text to disappear. This generally happens if there are floated elements within the element that is disappearing. This website (see #3) shows that by putting position: relative into the CSS style for the element that is disappearing, it will once again cause everything inside it to show up. Very strange.

MiXer Library: mixins in JavaScript

Mixins in JavaScript certainly aren’t a new idea. However, I noticed a lack of libraries for implementing this pattern. JavaScript libraries like Dojo allow the developer to create something akin to traditional classes. Such a thing is an unnatural pattern for the language. It doesn’t have any base support for classical OOP, so the libraries have to implement tricky functions to mimic inheritance. Even these functions have their limits though.

Mixins are another way to do inheritance in JavaScript. It can be a radical departure from the “regular” inheritance model that many developers are used to. However, once one wraps their brain around it, one may find that it’s a good pattern, and perhaps even a better one for JavaScript. As always, the nature of the system should determine what kind of development patterns are used. This is just one more way of doing it. Check out MiXer to learn more.

Google Wave’s Java Bot API: Part 1

Google’s Wave has also come with a host of new development APIs for creating bots and embeddable gadgets. I have not had the chance to mess around with gadgets yet. However, I have been working on a simple bot for Google Wave (see below), written in Java. This project was started to create group management for the Fortress Forever community on Google Wave. Currently the community is extremely small; only seven people. Some of those people may not even remain active on Wave; they just wanted to see it and mess around with it. Anyway, that has not stopped this small project. It started out with simple group management, but is progressing to something bigger, badder, and better.

This is the first in a small series of small reviews about Google’s bot API. As I discover new things about the API, I will review them here. This first article will focus on the basics of the API overall. Subsequent articles will delve into more specific things. This particular article will also be focusing on the Java API, as I have not experimented with the Python version of the client library yet.

The Basics: Pros

Overall, the API is very straightforward for a platform that is as complicated as Wave. All of the complications of the Wave protocol are hidden inside a nice client library (currently Python and Java versions exist). Bots written in Java are J2EE web applications that build on the foundational concepts of servlets. The Java bot API provides a servlet class named AbstractRobotServlet.

You must extend this class and implement its processEvents(RobotMessageBundle bundle) method. This is the entry point for the bot, and will be called every time an event is raised by the Wave platform. From the RobotMessageBundle, you can get the wavelet that raised the event, as well as check some event types. Once you have the wavelet, you can do more things such as create new wavelets, append blips, edit text, and more.

The Basics: Cons

The most annoying thing I’ve found so far is that certain bits of information you may want use in order to process an event tend to be spread across the RobotMessageBundle, the Wavelet, and the Blip objects. This leads to one passing around the three different objects to fully process different events. This problem mostly arises as a design issue in the software, though. With proper design practices, passing around all three objects as parameters to methods can be avoided. However, I don’t see it being completely impossible that a framework built on the Wave robot library will arise.

The other thing I have found to be of minor annoyance is having to increment “version numbers” in the capabilities.xml file when a new event is added to the bot. This forces Wave to update its list of known capabilities on the bot. It seems a bit obtuse, rather than just having a forced capabilites.xml update whenever a new version of the bot is deployed to Google’s App Engine, or allowing the user to manually trigger an update the next time the bot is hit from Wave. I suppose the forced update on every new deployment would eat up more of Google’s resources than necessary, but the manual trigger for an update wouldn’t be that bad.

Perhaps the versioning stuff could be abstracted by the Google Plugin for Eclipse with a checkbox on the deploy screen that gives the option to force the Wave to update the bot’s capabilities cache. It’s a small change (and definitely of low priority given everything else that needs to be finished first), but would make things even easier/straightforward.

Silly Thought: Client-Server Object Bridging

This was a silly thought I had at work the other day that I thought would be cool. I’m not quite sure if it’s practical or not, but I think it’s cool. The basic idea of this system is to use a JavaScript API to create objects in the client-side script, and then have those objects transparently replicated on the server. A possible extension to this would allow objects on the server to be transparently replicated on the client as well.

At the most basic level, neither idea seems too complicated (although client -> server binding is harder than server -> client binding). If the replication were to go both ways, we would have a bridged object, because it can be accessed in either the client or server environment.

Client -> Server Binding
Using XML-RPCs (remote procedure calls), the JavaScript library will send out requests to special receivers on the server. These receivers will use platform-specific methods to decode the XML and translate it into a server-side object. The response of these receivers, then, will be an XML message confirming that the binding was successful.

Server -> Client Binding
This is easier than the above. Basically, this boils down to getting all of an object’s member fields and method names and sending a bunch of JavaScript code in a response, which is then injected into the DOM.

Complications
The idea gets complex very quickly. For example, where does code that modifies the objects get executed? How does synchronization between client and server take place transparently in the background without having the developer have to do anything more than extend from a special object or implement some interfaces? How does this fit into the general lifecycle of a web application going from the user’s request to the server’s eventual response? Could an implementation of this concept be secure? How would the server know it’s receiving a valid request that the developer of the web application programmed in, and not a malicious JavaScript injection?

I propose here some basic answers to these fundamental questions. They are fundamental, because they are likely the most important for this concept to have any chance of working effectively, working only somewhat in a limited context, or if it won’t work well enough at all to be of any use. To start off, I think it would be prudent to begin with how these “bridged” objects fit into the general lifecycle of a web application from user request to server response.

How bridged objects fit into the FORM request-response life cycle?
At the most basic level, a web application consists of an HTML form, some server-side code to process that form, and an HTML response. The server-side code generally generates all or most of the response, so it can include dynamic response information such as a unique order number for a user. The server-side code may use objects to help keep everything in line. These objects will be created the developer and populated with data from the form submission. In order to make this bridged object binding idea work, we can actually re-think how forms are submitted.

Instead of relying on a normal POST request and manually-created code to decode the POST information on the server, we can instead create a server-side object that will encapsulate our data. Through the use of this binding library, then, we can submit the form information as one of these server-side objects. We could specify a special method type for submission with the form. When the page loads, the JavaScript library will take care of all the necessary things in the background. For example:

HTML:

<form action="processform.php" method="bind">
<input name="theBox" size="30" type="text" />
<input name="submit" type="submit" value="Submit" />
</form>

JavaScript:

function theForm_submit() {
     //FormObject's class definition resides somewhere on server.
     FormObject fo = new FormObject();
     fo.setInfo(theBox.value);
     fo.bind();
}

Server-side PHP (processform.php):
FormObject fo = getClientObject("fo");
string $info = fo->getInfo();
//do something with $info

This woefully incomplete pseudo-code example with invalid HTML markup is one of the simpler ways I could see this idea coming into usage. Here we have declared a function in JavaScript that handles the actual binding of the object with the server. Not very transparent at all. The first goal would be to remove the explicit call to the bind() method. The second goal would be to remove the need for the JavaScript entirely, where special values specified in the form itself are automatically interpreted by the JavaScript library and bound objects are created in the background.

Whether or not this usage of this hypothetical JavaScript/server-side library is even good, or useful, is another story entirely. To determine that, we will have to investigate other parts/usages of the web application request-response life cycle where a form is not necessarily being submitted. For example, AJAX calls based on button clicking could create an object and store it on the server. In the coming weeks, I hope to explore answer to those parts of this first question, and of course, answers to the remaining questions.