Is something I’ve been working on at wso2 for sometime, if you are following me I have tweeted the updates, releases etc. Jaggery went live with its fifth milestone, few weeks ago at jaggeryjs.org, its still young and has alot to improve.
Explaining a little bit about jaggery; Its NOT an alternative to node, its simply a toolkit to easily compose webapps and apis. Its a completely javascript way of writing all parts of the web application, and communicate throughout in json. Jaggery has out of the box features to create RESTfull applications, and its one of it’s value propositions. Jaggery can be easily extended via modules which can be written in javascript or java for that matter.
A very simple page that prints out some request properties in jaggery looks like,
At WSO2 we are busy with something new for the new year 🙂 and we have just pushed the milestone-1 of it, not so complete but you can sure taste it. Everybody knows that WSO2 is big on Web Services, but over the years we have seen that the barrier between Web Services and Web Applications hasn’t been lowered. “Jaggery” is an effort to diminish this barrier and to merge the development process of services and applications.
By definition it is a framework to write webapps and HTTP-focused web services in pure Javascript for all aspects of the application: front-end, communication, Server-side logic and persistence, and yes as I mentioned one of the intents of the framework is to reduce the gap between writing web apps and web services.
In general web engineers are fond of javascript (and JSON of cause), so why not write the server piece, persistence logic and the communication in-between also in JS itself ?
“Jaggery” helps you to do just that! Right now, the Javascript you compose will be fetched by Rhino engine and execute at the server, At Milestone-1 we have pushed features such as,
Compose server side web pages (HTML templates) : Server logic written in javascript (.JSSP)
Compose server side scripts purely in javascript (.JSS)
Today I was working on a customer POC and happened to create few Google gadgets to visualize selected data sets from *.gov.uk sites. The scenario which is implemented was, mixed with inter-gadget communication and content search over data.gov.uk sites. I created three simple gadgets which communicates with each other, and one acted as the controlling gadget which pushed the search parameters to other two gadgets. The two content gadgets showed UK (1) primary school information and (2) electoral information. The pushed parameter was the postal code of different parts of UK. The direct.gov.uk has a form based implementation of this.
The Requirements for the POC was, simple and we already had working samples of such a scenario at WSO2 library.
Show how one gadget can pass the context to other gadgets
How gadgets can harvest data in various formats (in my previous post I explained on how to get data from RDF endpoints, which are also available in *.gov.uk sites)
The building blocks for the implementation was the search url, which was quite straight forward. for all the requests based on postal codes the direct.gov site served in the same manner (because of this important fact, the automation process became trivial). for an instance the url for primary school information retrial was,
Where the param “text” changed according to the postal code. So far everything seemed straight forward, however at implementation, while using Gadgets API for content retrial, I faced problems in parsing text with javascript. Hence the gadgets.io.makeRequest supported HTML as text and the API method returned the retrieved HTML document as string making it quite impossible to process.
With some thinking and advise, I brought the Mashup Server in to the picture and used it to retrieve the data from the gov site and returned the result in XML format. Using the Mashup Server web scraping seems to be a piece of cake, We created a simple mashup using the scraper host-object and captured the result set in the search result page. The mashup code as follows,
function search(searchUrl) {
var scraper = new Scraper(
{searchUrl}
);
return new XMLList(scraper.response);
}
And finally the two gadgets were making service calls to the mashup service and retrieved the data as an XML object, making the data processing painless. The final version at the Gadget Server looked quite appealing.
Gadget Server look - in the end
Special thanks goes to Ruchira for helping me out with the mashup service 🙂 You can download the Gadget code and the Mashup service and try the scenario yourself.