Tuesday, June 1, 2010

Dependency Injection and OO

Once upon a time, there was Object-Orientation, and people liked it and wanted to do complex things with it. One idiom that was widely used was dependency injection:
class PaymentCard {
public boolean validateTransaction(Transaction t, Communicator c);
Here, a transaction (a different Object) is validated using some communication channel (a different object, being injected). The subclass could then just say

class VisaCard extends PaymentCard {
public boolean validateTransaction(Transaction t, Communicator c) {
super.validateTransaction(t, new VisaCommunicator());
Alas, the real world is not that easy. The VisaCommunicator is probably something that needs to be injected into VisaCard, or else it needs other injections like SerialCommunicator, EthernetCommunicator, RandomGenerator, CertificateHandler and whatnot. Pretty soon, the methods become huge.

"This is a bother", says everybody, and proceeds to move the injections into the constructor. However, it still means that to construct an object, you need to know what it and all objects it constructs needs injected.

"This breaks encapsulation", says everybody, and proceeds to make Dependency Injection frameworks where all these things are done automagically with annotations, reflections and all manner of other niftiness. Now several layers of reflection, lookup and wrapping is done for each object creation.

"This is slow", says everybody, and proceed to move the injection into "beans" that handle various layers of services: web service layer, business service layer, data access objects, ... The injections can now be done only when a new bean is needed, and since beans are stateless, they can be pooled and reused. Much faster. Scales nicely.

"This is not object-oriented", says I. My objects no longer have any significant functionality on them, since anything that requires injections (which turns out to be many things) must live in the beans. Code becomes spaghetti once again. However, these injections are almost all "static" injections - the objects injected are always the same class and have no state. So maybe each "OO class" (class that is actually object-oriented) could have an associated class that just holds its injections? It cannot be a static field, as they don't play well with beans. It should just be findable at construction time to be plugged into the object. Surely somebody has done this, I says, and wander off looking for a solution

Friday, April 9, 2010

iPhone development license changes

While my iPhone development has been put on the back burner in favor of other activities at the moment, I still have a plan to develop a memory training program in Lua. However, this would appear to put a more permanent hold on my plans, as Lua development simply won't be allowed anymore. Here's the letter I wrote to Apple in response:

Dear Apple,

One of the news to greet me this morning was the information that you're changing section 3.3.1 of your iPhone Developer Program License Agreement to exclude the use of other languages than Objective-C, C++ and Javascript for iPhone development. I have been planning to develop iPhone apps in Lua, but if this change stands, I will be using my $100 a year on other investments instead.

Banning all but these three languages would be a boneheaded move on your part, as it would extinguish in an instant a number of thriving development communities, most of whose members would probably go to a more liberal platform like Android. I fail to see how this change is beneficial to the future of the iPhone platform.<

If, as some have suggested, you are doing this to prevent systems like Adobe's Flash compiler from allowing cross-platform development that would it easy to have the same application on both iPhone and other mobile platforms, why not just say so? It would be easy enough to disallow applications in the App Store from also being made available on other platforms without excluding exciting new or existing technologies and the multitude of programmers who master them.

This change seems like a complex technological solution to a simple social problem, and will be harmful to the larger iPhone development community in the long run. It also saddens me that such onerous and arbitrary restrictions should be placed on a system I have grown so fond of. While I adore the care and thought that has gone into designing and developing the iPhone and most other Apple products, this and other policies of non-openness makes me question whether this is really a company I want to support with my time and money.

Yours in hope of a change for the better,

-Lars Clausen

Monday, September 28, 2009

Reasons I don't like EJB

At work, we've long since decided to use EJB3 for our main server system. As the conversion from old code goes along, I also learn some of the problems of EJB. I am more and more of the opinion that EJB3 is yet another over-engineered monstrosity as I've come to expect from Sun. Even with nifty annotations. But the worst part is that using EJB denies one access to a lot of the features of Java.
  • Package-level protection. Much as the package-level method protection scheme is inferior in Java (partly due to the lack of true subpackaging), when you switch to EJBs, you give up even that when you use EJBs. An EJB needs to implement an interface, and all other EJBs must get their dependencies through the interface. So unless you cast your injected bean to the implementation all the time, you cannot use package-level protection.
  • Object-orientation. Beans are singletons implemented with objects, their methods static for all practical purposes. Unless your bean is an entity (and thus subject to all the restrictions of being mapped to a database), you only have the one that's injected.
  • It's viral. Which is not so bad if you start out using it, but if you have a big old system it's difficult to gradually change over. Suddenly you find a cluster of classes that are unrelated to what you're doing, but you have to change them to EJBs because one of them calls a method in the class you actually want to change. And since EJB injection happens at runtime, it's tricky to determine if you've done it right. Even once you have all the EJBs injected correctly, if you miss somebody who makes an instance you'll get very subtle errors down the road.
  • EJB-injected objects are not the real objects, merely proxies implementing the interface (at least in some implementations). This means you can't do anything in the way of reflection beyond what the interface has; in particular, you cannot find annotations on the objects. This is particularly ironic with EJB3, which can be done entirely with annotations.
I'm sure more issues will pop up as the conversion goes along.

Wednesday, May 20, 2009

Dojo Templated, Part IIa

Just remembered this while writing the last post, but it merits its own post:

I mentioned earlier that the arguments to a widget that can be passed with attributes are limited to those that are already fields on the object. What I didn't realize then, and which has caused me a great deal of trouble previously, is that the parsing of those arguments depends on what the default value is!

Say that we have a widget like this:
dojo.declare("swadesh.languagePicker", [ dijit._Widget, dijit._Templated ], {
templatePath: dojo.moduleUrl('swadesh', 'templates/languagePicker.html'),
languages: [],
loadDelay: 10,
title: 'language',
hook: null,
postConstruct: function() {
console.log("Title: " + this.title + " hook: " + this.hook
+ " languages: " + this.languages.toSource() + " delay: " + this.loadDelay);

It allows four arguments to be passed with a dojoType style declaration, but they'll be handled very differently. The languages parameter is parsed as a list, so you can say '[1,2]' and it will be an actual list. The loadDelay is parsed as a number, so anything that doesn't parse as a number will become NaN. The title is parsed as a string, so no further evaluation is done. The hook is parsed as raw JavaScript and evaluated! Let's see this happen:
loadDelay="13.3" title="a.b(1+3)"

When this HTML is loaded, it will give the following output on the console:
Title: a.b(1+3) hook: des languages: ["danish", "english"] delay: 13.3

It that not nifty? It would appear that the scope of the hook argument evaluation is the global Dojo scope, rather than the scope of, say, the object whose template is being evaluated. That might make sense just in terms of keeping track of who's initialized when, but it's a mite impractical to not be able to refer to one's own values.

I realize now that I ran into this several months ago and had a hell of a time figuring out why I got errors out of my string arguments. Now I know that had I specified an empty string instead of null as the default, it would just have worked. Tricky!

This little find is probably going to help me quite a bit here and there. Dojo is full of little surprises that seem odd at first, but turn out to be very powerful.

Dojo Templated, part II

Ok, so it's been a little slow in updating this, mainly because I've been busy using Dojo. I have continued working on the application that I showed a tiny bit of last time, which now has a name: LewenTrans (because it helps with transcription into IPA and calculation of Lewenstein distances).

Last time we saw the basics of using Dojo templates. It looked like a lot of work to just get a single variable into a template, but we only scratched the surface of what the Dojo Templated system can do.

Astute readers may have noticed that in the template, there was a div that looked like this:
  <div dojoAttachPoint="tipaDiv"></div>

This special attribute performs a small but extremely useful bit of magic: It assigns that DOM node to a field of that name in your widget object. Why is this so useful? Couldn't I just have used id=tipaDiv and document.getElementById() like normal humans?

Here we get to one of the main benefits of using Dojo Templated: It handles namespaces for you. Normally, when you make a web page, you'd have to take care to not use the same ID several times, or the browser will complain. Once you get into Javascript, you'll have to be even more careful to not define the same Javascript function twice, as the browser will not complain, merely call the last once whether you wanted it to or not. This is bad enough, but consider what happens once you start writing enough JavaScript that you want to reuse some of the code: Each bit of JavaScript you include might overwrite function or variables from other bits, and keeping track of this is a nightmare -- especially since you're not necessarily notified of this happening, things just go mysteriously wrong down the road. I can well imagine many people eschewing the use of Javascript just because of this "feature".

That hell of clashing namespaces is what Dojo Templates helps you with. Not just each class[1], but each instance of your class has its own namespace. Let's see how to do this. If I have a widget called swadesh.languagePicker that creates a little Ajax-based drop-down to pick a language, I can add it to the swadesh.tipaTable class by adding these two functions[2]:
postCreate: function() {
var lp = new swadesh.languagePicker(
{callback: dojo.hitch(this, "languageSelected")});
languageSelected: function(language) {
console.log("Got language " + language.toSource());
This not just creates a new languagePicker instance and plugs it into my HTML, it also gives that instance a callback function that can be called when the language has been selected. Let's take a look at the details:

The argument to languagePicker is an object, which on the languagePicker side is a set of keyword arguments. Customarily, the constructor uses dojo.mixin to add all the keys as fields on the instance. In this case, it's just the callback field, but it could be many others -- up to and including redefinitions of functions, if you feel foolhardy.

The dojo.hitch function makes a thunk out of an object and the name of a function. In this way, the languagePicker does not have to think about the fact that it should call the callback on another object, hitch encapsulates that. Very sneaky.

Next we see the use of the this.tipaDiv field which was assigned due to the dojoAttachPoint in the template. This is the separate namespace in action -- every time I make a new object, the tipaDiv field is a new part of the DOM tree. I can create as many as these as my poor browser will carry on its back, and they will all have each their little tipaDiv.

The template only gets processed once the constructor has been run (and the constructor could indeed create it on the fly if it doesn't require Ajax calls for it), which is why we use the automagically called postCreate function for setting this up. This function gets called once the template has been processed and it's all set up in the web page, ready for our manipulation.

The argument to appendChild is not the languagePicker object, since that object is not a DOM object, but something we have "handcrafted". However, the object has a field domNode that contains the instance of the template that is associated with our object. That one can be inserted in the DOM.

Now let's consider what would happen if we were to create two tipaTable objects (which I will need to do soon). Had these things been done with ordinary functions and id attributes, we would have had to mangle the ids and function names to keep them distinct. With Dojo Templated, all that is handled for us implicitly[3].

The computer savvy amongst you may already be thinking "why can't I use the dojoType attribute to embed this widget automagically from the template?" It's simple recursion, after all. You can, but there are a couple caveats:

First, you will need to tell the widget that there can be other widgets defined in the template, otherwise they won't get processed. This is done by adding a field
widgetsInTemplate: true,

to the widget whose templates contains other widgets.

Second, you might want to use Ajax to get some data to feed the inner widget, I do that on several occasions. Not so here though, so why didn't I use dojoType?

Because, third, you cannot (AFAICT) specify a hitched function in an attribute to the inner widget. Since I want a function on my object to be called, I need to create it by hand. Ways to fix this would be appreciated.

Now you have learned how to make Dojo widgets with JavaScript and how to use widgets within widgets, and also a very simple callback system. With this alone, you can do a fair amount of web page with not a lot of coding, but there's still more to come before we are truly Web 2.0, things like making Ajax calls, handling events and modifying the DOM tree. I'll get back to that.

[1] While Javascript don't have classes in the Java sense, the widget definitions function very much as such, and I will be referring to them as such.
[2] And adding dojo.require("swadesh.languagePicker") in the header.
[3] Though I wouldn't mind a shortcut for dojoAttachPoint, that's a long word to use all the time.

Friday, May 8, 2009

Encodings in Dojo, JSON and mod_python

Just had a hell of a time getting UTF-8 encoding to come all the way through using Dojo, JSON and mod_python. Here's how I ended up doing it:

To get correct encoding from a published python function:
def testJSONFromDB(req):
req.content_type = "application/json; charset=UTF-8"
cur = getCursor()
rc = cur.execute("select Orthography FROM Cognate WHERE CognateId = 609")
return req.write('/*' + simplejson.dumps(cur.fetchone()['Orthography'], ensure_ascii=False) + '*/');

The content-type was subtle; other response headers are set in a different way. The ensure_ascii bit is by default true -- which is annoying if you're trying to be international. (The DB statement is just to get one of the words that have non-ASCII values)

To read the encoding correctly on the Dojo side:
handleAs: 'json-comment-filtered',
url: '/Python/swadesh.py/testJSONFromDB',
headers: {
"Content-Type": "text/plain; charset=utf-8"
load: function(data) {
document.getElementById('JSONFromDB').innerHTML = data;

Here, the trick is that the headers should ask for text/plain in UTF-8, but the handleAs value should indicate JSON. Go fig. It works now.

Also, don't just the code tag when describing Python, it removes the syntactically important whitespace.

Friday, March 20, 2009

Dojo Templated, part I

Dojo is a JavaScript toolkit with a number of really nice widgets. One reason it has so many is that it has a very simple way to make new widgets: Templated. This allows you to have a little bit of boilerplate JavaScript, and then you can use HTML with parameters to define your widget.

To illustrate, I will walk through an application I am currently writing that I call Swadesh. It is intended to allow editing of the orthography and IPA phonetic transcription of a limited series of common words know as the Swadesh list. The main interface will have, on the left, the list of cognates for a given word, and on the right a table of TIPA (TeX-IPA) symbols to insert. Let's start with the TIPA table, as it offers a simple example of basic Templated usage. In each bit of example code, I have bolded the part that is interesting.

This is the (slightly trimmed) HTML for the page itself:
<html> <head>
<script type="text/javascript" language="javascript" src="/dojoroot/dojo/dojo.js.uncompressed.js" djConfig="isDebug: true, parseOnLoad: true"></script><script type="text/javascript">

<div style="width:50%; float:left">
Cognates go here...
<div style="width: 50%; float:right">
<div dojoType="swadesh.tipaTable" language="Danish">
Table of TIPA characters will go here
</body> </html>

The first bit of JavaScript is what loads Dojo itself. The important part to notice there is the src attribute, which not only defines where Dojo is located, but also where local extensions can live - namely under the /dojoroot directory. The dojoroot directory contains the unpacked Dojo source

The next bit of JavaScript loads our home-grown widget, swadesh.tipaTable. This is analogous to import statements in Java or #include in C. Notice that we do not reference a file here, but an abstract name -- we'll see how that works shortly.

The remaining bit of interest is the div with the dojoType attribute. This is how our widget gets inserted - an HTML tag with a dojoType attribute that names our widget. The tag is then going to be replaced with some lovely home-grown HTML defined by our widget. The language attribute is an argument to the widget - here it specifies which language we want to show TIPA characters for. There's nothing more to using a Dojo Templated widget than this - but many possibilities.

Now let's look at how our widget's HTML is defined. So far, it's a simple thing, as most of its content will later be loaded dynamically from a database, but it shows the first big advantage of Dojo's Templated widget: parameter substitution. Even if this is all you use, you've made writing HTML a lot more dynamic.
<div>IPA characters for ${language}</div>
<div dojoAttachPoint="tipaDiv"></div>

This is just a little bit of stand-alone HTML that'll be inserted instead of the tag with the dojoType attribute on it. The noticable part is the ${...} bit - this will be replaced with the argument specified where we used it, in our case "Danish". Seems trivial, but now expand this to a multitude of parameters that can be inserted in numerous places, and you have one sweet little customization engine.

All that's missing now is the glue that actually gets the substitution done. This will look a little cryptic, but most of it is really boilerplate code that can be copied and pasted every time you make a new widget.

dojo.declare("swadesh.tipaTable", [ dijit._Widget, dijit._Templated ], {
templatePath: dojo.moduleUrl('swadesh', 'templates/tipaTable.html'),
language: null,
constructor: function(kwArgs) {
dojo.mixin(this, kwArgs);

I have bolded the only things that need to be changed when making a new widget: The name of the widget, the filename of the template we wrote before, and the list of parameters (of which there is one). The rest can safely be ignored for now.

Now is a good time to look at where we place the files. I mentioned before unpacking the Dojo source in a directory called dojoroot (an arbitrary name, but that's what we specified when we loaded Dojo back at the start, and it's easier to stick with that). Under the dojoroot directory, we make another directory called 'swadesh', which is where we'll keep all our widget-related files. This is the "module" we're defining, which can (and will eventually) consist of several widgets designed to work together. We place the boilerplate code in that directory, in a file called "tipaTable.js". The module name together with the file name is what allow us in the original HTML to use dojo.require('swadesh.tipaTable') to import our code - the module name and the file name (without .js) together form the widget name. This is also the name used in the boilerplate code, both in the dojo.provide statement and the dojo.declare statement.

In the swadesh directory, I create another directory called "templates". This will contain all the bits of HTML that are used by the widgets. In our case, we put the little bit of HTML we defined before in that directory under the name "tipaTable.html". This name is really arbitrary, and could even be dynamically assigned if we so choose, but to keep it simple we use one static piece of HTML with the same name as the widget. The file name is then used in the templatePath statement, which is how our widget knows where to find its defining HTML.

The last thing we need to do is define the parameters that this widget can take. This is done as a series of JavaScript field definitions, so they'll be of the form "parameterName: parameterDefault,". The parameterDefault is a value that will be used if the attribute is not given in the HTML. Frequently, this will be null to indicate a feature not used, but it could as well - and should when possible - be a reasonable default value such that the attribute doesn't need to be specified all the time. Good defaults are a hallmark of useful systems.

This is really all there is to it, and once you've made one widget, the next ones will be easier. You can even use widgets inside your widget by having another tag with the dojoType attribute. Using Dojo Templated, you can change your HTML from huge monsters of cut-and-pasted code with just slight alterations to modular, parameterized pieces -- and these pieces can even be made to do work for you, we'll see how in a later post.