Shindig Architecture: Java Gadget Server 2 – Servlets

More raw Shindig notes. This time, looking at org.apache.shindig.gadgets.http. See Shindigging tag. I’ll structure them just a little more this time.

Main Servlet

BasicHttpContext.java – data struct for country/language/locale

GadgetRenderingServlet.java – The servlet that accepts gadget spec URL and prefs, and outputs the gadget content (typically in an iframe). Delegates heavily to GadgetServer, in order to get a Gadget, and then serialises the Gadget itself with outputGadget(). outputGadget() will output the gadget as either URL or HTML type, depending on the content type. (I expect those output methods will probably be extracted to a seperate class, or to their own strategy classes.)

  1. gadget = servletState.getGadgetServer().processGadget(gadgetId,
  2.           getPrefsFromRequest(req), context.getLocale(),
  3.           RenderingContext.GADGET, options);
  4.       outputGadget(gadget, view, options, contentFilters, resp);

HttpProcessingOptions.java extends ProcessingOptions – Allows URL params to override default options, e.g. to allow caller to suppress caching

Javascript Servlet

JsServlet.java – Outputs Javascript content

Proxy Servlet

ProxyHandler.java – Provides implementation for ProxyServlet, which is a thin wrapper around this class

ProxyServlet.java- Handles Fetch commands for gadgets, i.e. allowing them to get remote content. Delegates everything to ProxyHandler

RpcServlet

RpcServlet is a “meta” servlet. Initially I thought it was just for debugging/administering the container, but it plays a more important role as it lets the browser-side gadget container issue a query to find out about the gadgets it’s hosting. (The gadgets are of course in an iframe, so due to security restrictions, it can’t directly inspect the gadget content to find out, for example, its name, which it needs to know in order to show the gadget chrome/wrapper).

JsonRpcContext.java – Context for JsonRpc stuff. Used by RpcServlet

JsonRpcGadget.java – Meta-model of a Gadget (ie just its defining features – URL and moduleId – and not fields to populate it as in Gadget). Used by RpcServlet

JsonRpcGadgetJob.java – Used by RpcServlet

JsonRpcProcessingOptions.java – Used by RpcServlet

JsonRpcRequest.java – Used by RpcServlet

RpcException.java – Boring exception class

RpcServlet.java – Provides Gadget meta-info – allows a programmer/tester to get info about the gadget server and list its gadgets. See http:[email protected]/msg00317.html.

Used by All Servlets

CrossServletState.java – Servlet scoped state (ie instances of the same servlet always get this state object) – – Defines accessors for globals such as the GadgetServer, so that each Gadget can get a handle on them.

DefaultCrossServletState.java implements CrossServerState – creates globals such as the GadgetServer (and defines accessors for servlets to access them). Also includes some utility methods for the servlet (which could really go elsewhere).

Misc

CajaContentFilter.java implements ContentFilter – Caja filter – adaptor/bridge to Caja project, which sanitises JS, intended for inlined gadget.

Phobos – Server-Side JS Redux

On Ajaxian, Dion points to Sun’s Phobos project, an attempt to build a new platform for server-side Javascript. Phobos came out six months ago, around the time of the May Ajax Experience.

No-one has taken server-side Javascript seriously since it died a premature death in the mid-90s. But there is great potential…

  • Server-side Javascript would allow for code sharing between browser and server. The most obvious application being validation code, but since no-one really bothers with server-side Javascript, there are probably many other patterns as well. One pattern I came up with a while ago is Dual-Side Templating, where you have the same parametized HTML template on both the server (for initial page load) and the browser (for subsequent additions to the page). I implemented the server templating in Ruby, but it would have been a lot easier if the server was running JS. That’s just one example.
  • Server-side Javascript would keep us Ajax types more sane. Right now, an Ajax developer has to constantly flip between JS and [insert favourite server-side language here]. True, you always have to flip over to other “languages” too, viz. HTML, CSS, SQL; but there’s always a special place in the programmer’s head for the core language of the day. With Ajax, you have two such languages. If those languages are quite similar (e.g. Javascript and PHP), it gets frustrating because of all the subtle differences (new Array() versus array()). If they’re different (Javascript and Ruby), you’re trapped in a Whirf-Brock disconnect, constantly flipping between two different worldviews. Slight exaggeration as it’s certainly do-able, but it would be a lot easier if programming in one main language.
  • Server-side Javascript would pose less of an issue for IDEs. With new improved Javascript, IDEs are being forced to support Javascript in order to keep up. It’s far more important than supporting SQL etc; so basically, IDEs now have to provide solid support for at least two serious languages…it would be easier if it was only one.

Now a framework like Phobos has much to offer the world compared to the server-side Javascript of the mid-90s:

  • Phobos is apparently inspired by new frameworks such as Rails. With the right libraries and improved patterns for OO, inheritance, etc, Javascript can compare admirably against Ruby. Not in every regard, but then there are actually some aspects of JS that are superior (e.g. functions as opposed to blockism; dynamic member creation).
  • There’s a lot more known about Javascript now, and it’s almost certainly the most widely understood language in the industry, even though it’s not the primary language for many (cf. English).
  • Because of all the JS code now running in the browser, there are probably a bunch of synergies with server-side JS – these could be exploited by a well-considered server-side JS framework.

As an open platform, Phobos has the best chance right now to make server-side flourish. But I agree with Dion, that there is reason for concern about whether it will happen.

Sun may already have this. Will they be able to market it? Unfortunately, the track record isn’t there, so it will probably languish. Buy maybe not.

State of the Ajax Frameworks

The publicly-editable Ajax Frameworks Page got a nice kick along in the past few days, presumably due to a recent link from Ajaxian. If this list is anything to go by, the most common language is pure-Javascript, and Java is, as you might have guessed, highest on the server-side, followed by .Net and PHP. Sections for Python and Perl were opened up during this time. Thanks for your contributions!

1 Pure Javascript: Application Frameworks

  • 1.1 Isomorphic (Commercial RIA Toolkit)
  • 1.2 Bindows (Since 2003)
  • 1.3 BackBase (from 2003)
  • 1.4 DOJO (Under development; from September, 2004)
  • 1.5 Open Rico (Under development; from May, 2005; based on earlier proprietary framework)
  • 1.6 qooxdoo (Under development; from May, 2005)
  • 1.7 Tibet (Under development; from June, 2005)
  • 1.8 AJFORM (Since June 2005)
  • 1.9 ThyAPI (Under development; Since end of 2004)

2 Pure Javascript: Infrastructural Frameworks

  • 2.1 AjaxCaller (Alpha; from May 2005)
  • 2.2 Flash JavaScript Integration Kit ()
  • 2.3 Google AJAXSLT (Released June 2005)
  • 2.4 HTMLHttpRequest (Beta; from 2005)
  • 2.5 Interactive Website Framework (from May 2005)
  • 2.6 LibXMLHttpRequest (Released; June 2003)
  • 2.7 MAJAX (Released; August 2005)
  • 2.8 RSLite (x)
  • 2.9 Sack (In development; from May 2005)
  • 2.10 Sarissa (Released; from February, 2003)
  • 2.11 XHConn (Released; from April, 2005)

3 Server-Side: Multi-Language

  • 3.1 Cross-Platform Asynchronous INterface Toolkit (May 2005)
  • 3.2 SAJAX (Workable but not 1.0; from ?March 2005)
  • 3.3 Javascipt Object Notation (JSON) and JSON-RPC
  • 3.4 Javascript Remote Scripting (JSRS) (from 2000)
  • 3.5 Bitkraft for ASP.NET

4 Server-Side: Python

  • 4.1 CrackAJAX

5 Server-Side: Java

  • 5.1 WebORB for Java (from August 2005)
  • 5.2 Echo 2 (from March 2005)
  • 5.3 WidgetServer (2004)
  • 5.4 Direct Web Remoting (DWR) (2005)
  • 5.5 SWATO (2005)
  • 5.6 AJAX JSP Tag Library
  • 5.7 AJAX Java Server Faces Framework
  • 5.8 ThinkCAP JX: RAD Environment for AJAX, J2EE, and Open Source (Commercial Framework)
  • 5.9 Struts-Layout

6 Server-Side: Lisp

  • 6.1 CL-Ajax

7 Server-Side: .NET

  • 7.1 MonoRail (from May 2005)
  • 7.2 WebORB for .NET (from August 2005)
  • 7.3 Ajax.NET (from March 2005)
  • 7.4 ComfortASP.NET (from August2005)
  • 7.5 AjaxAspects (from August 2005)

8 Server-Side: Perl

  • 8.1 CGI::Ajax – Export perl methods to javascript for AJAX

9 Server-Side: PHP

  • 9.1 AjaxAC (From April, 2005)
  • 9.2 JPSpan
  • 9.3 XAJAX
  • 9.4 PEAR::HTML::Ajax
  • 9.5 CPAINT

10 Server-Side: Ruby

  • 10.1 Ruby On Rails

Must Have 5 Years “Ruby on Rails” Experience

If there’s one certainty in this industry, it’s the ongoing hilarity of job ads. David Heinemeier Hansson found a job ad that mentions “Rails” in the same breath as “enterprise” and “whitepaper”, and “struts” in the same breath as “latest and greatest”:

Should have ideally 5 years experience with all of the latest and greatest tools out there. The more the better. J2EE, struts, Ruby on Rails, Websphere, etc. Should have experience constructing Enterprise wide Java solutions from whitepapers.

“Why yes, I just pushed the Rational Rose Activationate button and Rose generated the Enterprise wide Java solution for me, along with the whitepaper. I didn’t even have to tell it anything first. Does that count?”

David’s reaction:

Rails has truly broken through the awareness barrier when its included as part of a job application that’s the antithesis of everything Rails is about. Clueless recruiters of the world, I salute you!

The “Must have 5 years Java” requirement, at a time when Java was barely out of the Sun Labs, have become legendary. There can be no finer way to attract dishonest candidates than to construct an infinitely high hurdle. I’ll donate a Pragmatic Rails text to whoever spots the first serious (as in seriously misguided) Rails equivalent.

Reading Open-Source Code

Dave Crane looks into some Scriptaculous code. The main point is that Scriptaculous is easy for novice JS programmers to use, but the source code would be difficult, for novices at least, to understand. Which raises these questions:

So, going back to the bigger picture, here’s something for the authors of JavaScript libraries to consider. How much of a gap are you creating between using your library, and being able to modify or enhance it? Does such a gap present a barrier to its uptake? Should good code be there to be read as well as executed?

In theory, the implementation of a library shouldn’t matter to developers using it. That’s because a good library should offer components that are open for extension, but closed for modification – the open-closed principle. Thus, you should be able to treat the library as a black-box and only care about the API it presents – you never have to maintain it, so why read the code?

But it’s usually not so simple. You might not need to change the code, but you do need to understand it. In an ideal world, there would be abundant documentation. But agile says that all that documentation is valuable, but self-documenting code is much more valuable. In similar vein, the availability of code is often justified as a reason for open-source projects to include less documentation (among other benefits). So open-source code had better be understandable, ideally self-documenting, but at least well-commented.

I have used (by “used”, I mean “wrestled against in a cage match”) a couple of very prominent Java EE frameworks where implementation code is confusing and badly in need of refactoring, with most of the code comments in “TODO” and “Weren’t you going to fix this?” territory. I was stuck and documentation was insufficient, so I could only turn to the source code for help. And that’s actually a pretty good place to work out what’s going on anyway. But, alas, the code did not come to my aid. ** Perhaps that’s the natural consequence of an open-source project becoming a startup with a support-based revenue model, but it makes a mockery of the code-as-documentation argument for open-source.**

The Scriptaculous implementation is good for anyone who knows Javascript, which is all you could hope for … just because it’s API is simple enough for novices, doesn’t mean its implementation has to be. In fact, the implementations of “Puff”, “Fade”, and so on, are actually extensions of the base functionality, and any developer could create their own effects in the same way. The Effect framework is an example of how Javascript can provide decent support for Domain-Specific Languages, in Scriptaculous’s case, a grammar of visual effects. Also, if only want to use an existing effect, but with a little variation, some of them accept an options specification.