Google Open Sources Google XML Pages

By Kurt Cagle
August 11, 2008 | Comments: 7

Given the mind-numbingly large number of pages that Google serves up every day, compiled efficiency is a key requirement for their web development team. However, as with many organizations, Google's team has also needed to split up their development efforts, so that web designers do not need to be programmers (and more importantly, do not need to endlessly spend their time validating and debugging low level code), and the core developers could spend time building components.

Given that, it was perhaps not all that surprising that at some point, Google decided that the best way of building such tools would be to use XML as a way of abstracting out complex functionality, then using a Java-based interpreter to convert that XML into a compiled binary object. This technology, Google XML Pages, was first developed by Google engineer Laurence Gonsalves in 2001, largely as an experiment at first. Over the years, it migrated out of the lab and into a number of Google sites including the AdWords, Blogger, Google Analytics, AdSense and Google Checkout.

At OSCON 2008, Gonsalves made the announcement that, after several years of consideration, Google was releasing Google XML Pages (or GXP) under the Apache Open Source License. Gonsalves admitted at the conference that they had intended GXP to be release under open source code earlier, but the GXP team felt that it needed to be as bulletproof as possible before that should happen.

Originally developed as a Python interpreter that produced Java source code, gxp was rewritten in 2006-7 to be a completely Java based application. The idea behind gxp is fairly simple (and is one that is used, in slightly different fashion, for Microsoft's XAML and Silverlight) - a web designer can declare a number of XML namespaces that define specific libraries on an XHTML or GXP container element, intermixing GXP and XHTML code in order to perform conditional logic, invoke server components, define state variables or create template modules. This GXP code is then parsed and used to generate the relevant Java code, which in turn is compiled into a server module invoked from within a Java servlet engine such as Tomcat or Jetty and cached on the server.

book coverbook cover book cover book cover
For a complete list of all things XML,
visit xml.oreilly.com


You might also be interested in:


7 Comments

Great article Kurt. I wonder how far this concept can go.

Hey Kurt,

At first look it seems to have a lot in common with XSLT. Your thoughts?

This reminds me of Apache Cocoon, which is already Apache licensed ;).

Google decided that the best way of building such tools would be to use XML as a way of abstracting out complex functionality, then using a Java-based interpreter to convert that XML into a compiled binary object. This technology, Google XML Pages, was first developed by Google engineer Laurence Gonsalves in 2001, largely as an experiment at first. Over the years, it migrated out of the lab and into a number of Google sites including the AdWords, Blogger, Google Analytics, AdSense and Google Checkout. (If you want more knowledge about XML and creation of a website you can look at kswchina,there are some knowledge about it but chinaese.It's a good learning Chinese place too! )

Facts have proved that google is right to do so.

This is really an interesting article ,thanks for you, Kurt !

A few too many "considerably easier"s for me.

It looks like Jelly?

Basically, DSL - domain specific language. Cool.

I did something similar when I had to develop a credit app with 200+ fields with conditional validtion, and the output needed to use Struts validators. That meant 200+ fields in html, 200+ fields in a Struts form, and 200+ fields in the validator, all with matching fieldnames with no typos. I dreaded the testing of each field.

Instead of hand-coding, I just consolidated WHAT I needed for each section and field using XML tags with ad-hoc attributes for fieldname, caption, type, length, validation, related fields, etc.

Then I worried about HOW by writing 3 XSLT files to extract out the data for each layer (the raw HTML form output was just included by a hand-coded jsp page, so I didn't have worry about non-form related content).

VERY handy, and no fieldname typos to track down. Need documentation? Just write another XLST (admittedly NOT easy).

The 2nd payoff came when the business user decided that some sections should be interactively hidden unless needed based on field input. I wasn't sure how to do it, but I just described WHAT I needed by wrapping a section in a new OPTIONAL tag with fieldname and value constraints, then figured out HOW by adding some javascript output to the XLST. Got it working in about a day.

The nice thing is after you get it working once, it works everywhere specified, no cut-and-pasting code to each section. AND if you code optimizations later, the output is automatically optimized everywhere with a click (XSLT ant task)

Ok, enough blather....

Popular Topics

Archives

Or, visit our complete archives.

Recommended for You

Got a Question?