Skip to Navigation | Skip to Content



Archive for the 'Architecture' Category

Extending an Ajax Component | August 14th, 2006

Ajax components are not only cool but actually quite useful - and I am not just saying that as a component vendor but as a web application developer. At nitobi we do both consulting and component development and when doing consulting we shy away from actually changing the component source code to do things that we need and instead focus on extending core components.

Since JavaScript is a dynamic language, one can really easily extend functionality. Most notably, many will have at least heard of aspect oriented programming which is the idea of adding before, after, or around advice - which just means running some code before, after or around some predefined method.

Let’s take a look at a quick example. As many already know, classes in JavaScript are defined as functions.

// Define the Dog class
function Dog()
{
    this.breed = ‘berner’;
}
// Define the speak method on the Dog class
Dog.prototype.speak = function()
{
    alert(’w00f’);
}

That defines a Dog class that has a public property for the dog breed and a public method to make that pooch sing.

So let’s pretend that I am an Ajax component vendor (who knew) and to make my JavaScript load faster I might go ahead and remove the white-space, remove comments, and even replace long variable names with shorter ones. This all happens when I “compile” my JavaScript on my server before I let people access it.

If this were a compiled DLL say, then it would be more problematic to do something like change what the dog says based on the breed of the dog - particularly if this has to be done at runtime rather than compile time. Luckily for us AJAX developers, JavaScript is very flexible :)

The first thing that we can do is create a new instance of our Dog class and actually replace the speak method with something completely different.

// Create a new instance of a Dog
var berner = new Dog();
// Re-define the speak method for this instance only
berner.speak = function() {
  alert(’I am a Bernese Mountain Dog’);
}

If we wanted to change every new instance of the Dog class we can also change the actual class definition by changing the prototype property just as the original author did.

// Re-define the speak method for the class
Dog.prototype.speak = function()
{
  alert(’I am a ‘ + this.breed);
}

Alternatively, we can also add code that will run before or after the speak function. We can define a static function called attachAfter in the aspect namespace that will take an object to which some method belongs (sourceContext), a string that is the name of a method on that object (sourceMethod), and a reference to function object that we want to call after the source method is called (aspectMethod). aspect.attachAfter is pretty simple and looks something like this:

aspect.attachAfter = function(sourceContext, sourceMethod, aspectMethod)
{
    var oldMethod = sourceContext[sourceMethod];
    sourceContext[sourceMethod] = function()
    {
        oldMethod.apply(sourceContext, arguments);
        aspectMethod.apply(sourceContext, arguments);
    }
}

We use the JavaScript apply method here such that we can pass the arguments list that the method is to be called with. To actually use this with our Dog class we could either augment the instance of the class or even the class itself. Here is an example of attaching some function that will alert the breed property of the dog after the dog speaks.

var berner = new Dog();
// This will just alert ‘w00f’ as we expect
berner.speak();
// Now attach an after function to the speak method
aspect.attachAfter(berner, “speak”, function(){alert(’I am a ‘+this.breed)});
// This will now alert ‘w00f’ and then ‘berner’
berner.speak();

Notice that we can even execute the after function in the context of the berner object and therefore we have access to the this keyword in our attached function.

I am going to look at more JavaScript features in the coming weeks including inheritance and dynamic XML parsing. If anyone sees any problems here let me know!

Technorati Tags: ajax, components, javascript, patterns, architecture

Posted in AJAX, Architecture, Components, JavaScript | 4 Comments » | Add to Delicious | Digg It

Podcasting with Duane Nickull | June 21st, 2006

In the latest EBA podcast we were lucky enough to have Duane “Cosmic Genius” Nickull with us from Adobe.

Mostly just discussed SOA and jabbed at SOA 2.0 a bit :)

I am also hacking away at a Flex component for copy and paste functionality between our AJAX Grid and a Flex DataGrid (or Microsoft Excel). I did a quick google and found that someone from Adobe already did a copy/paste to/from Flex and Excel example - just five days ago.

Check it out.

Posted in AJAX, Flex, Service Oriented Architecture, Web2.0 | No Comments » | Add to Delicious | Digg It

AJAX and Java | June 13th, 2006

I have been preparing some screencasts showing how to use DWR with NetBeans over the weekend and I will be presenting that along with a few slides about AJAX + Java on a webcast over at developer.com. Check out the link there for all the details.

Here is the preliminary slide deck if anyone cares to take a look and give any feedback. If you want the real goods you will just have to join the webcast!

We should also be doing another podcast tomorrow night so if you can’t make the webcast maybe check out the pod version. Lots of good EBA news this week and I am sure there will be some stimulating AJAX talk! If wants any topics covered be sure to let us know.

Technorati Tags: java, jsf, ajax, components, webcast, netbeans

Posted in AJAX, Architecture, Components, JSF, NetBeans | 4 Comments » | Add to Delicious | Digg It

Podcasting it up! | May 24th, 2006

Well, Captain AJAX and I finally got around to making our first podcast! It is a bit long and the audio sucks but we will be sure to get that fixed for next time ;) . Anyhow, Dre and I just talked about everything that happened in the past coupld weeks including Dre’s findings down at JavaOne, The AJAX Experience, DCamp and NetBeans Day.

We also talked about the launch of EBA Grid V3…and what's to come down the road - WARNING - could be considered shameless self promotion but we also talk about some AJAX technology stuff :)

Here is the podcast care of Audioblo. If anyone has any tips about posting and or making the old podcasts then let us know!

Technorati Tags: ajax podcast javaone ajaxexperience

Posted in AJAX, Architecture, Business, Components, Declarative Programming, Flex, JavaScript, Web2.0, XML | No Comments » | Add to Delicious | Digg It

ALE Hangover | May 5th, 2006

The always interesting Ross Dargahi from the Zimbra team recently released a draft specification for something they call AJAX linking and embedding (ALE), which is loosely based on the Windows object linking and embedding. They say that there are two key enabling browser capabilities for ALE. The first capability is “design mode”, which many of you web heads know can be used to specify that certain DOM nodes are actually editable in the browser; this of course is what gives us wonderful Web 2.0 goodness such as Writely. Second, they suggest the use of IFRAMEs as a component sandbox.

At first glance these seem quite pragmatic and give us some powerful tools for creating composite AJAX applications such as mash-ups or (in the interests of Zimbra) documents. That being said I also have some constructive criticism to offer. The first thing that comes to mind is why the need for using design mode to edit content? There are many rich AJAX components out there that do not require design mode to enable editing and in fact using it would likely be a hinderance. I could certainly see the usefullness of having a designMode property on an AJAX component just to notify a component when it should be in an editable state. There are of course a few cases where design mode is quite necessary (like the afformentioned Writely rich text editor), however, that is pretty much the only significant case that design mode is of use. For structures such as trees or spreadsheets, design mode is just not useful. Don’t get me wrong here, I am not suggesting that there is no need for rich online content creation, we just don’t necessarily need to use design mode to achieve it.

As for IFRAMEs, personally I don’t want my rich AJAX components to be confined to one square of screen real estate. The DOM API of a web page is quite a unique and powerful abstraction relative to more traditional user interface paradigms such as Windows Forms, to limit DOM usage to small squares of rich user-interface would be rather draconian. Having said that, when you start building web applications that look and feel much more like desktop applications then it may not be all bad. But then again, the AJAX community is in some ways forcing the desktop to be more like the web, not the other way around ;)

In general an OLE like idea is easily achieved on the web since the entire web page DOM is essentially a rich editor sandbox and linking is easily achieved by including resouces (JavaScript, CSS, images etc) over HTTP. So without using IFRAMES or design mode I think it is safe to say that AJAX is OLE ready. Having not come from a Windows OLE type background I have started to look into the concepts a bit more on MSDN to see what we can take away.

I think that the most important point that Ross form Zimbra makes is that we do need to define some object interface that allows one to instantiate and (de)serialize an AJAX component in a standard way. One big thing missing though is a standard way of getting data into and out of an AJAX component; I think that is the really important piece of functionality that OLE brings to the table. That could mean either copying data from one AJAX component to another or from an AJAX component to a desktop application. I want to be able to select a sweet Google financial graph, press ctrl+c (or maybe apple+c) and then be able to paste that data in my AJAX Spreadsheet. Esentially, as Ray Ozzie pointed out, we need a common Web Clipboard - clipboard is a critical part of OLE or ALE. We have been using pretty much this same technique with our products to copy data from Microsoft Excel to an EBA Grid AJAX component and vice-versa.

There are also other kinds of data sharing (like drag-and-drop) and interfacing that need to be standardized to make some really kick-ass mash-ups I think. Microsoft Sharepoint, despite its faults, has some cool and fairly easy run-time connecting of components. Too bad it’s Sharepoint though :) .

Another interesting dimension of ALE is declarative AJAX. Serialization and deserialization of a component with its data and metadata is very important. We take the approach of defining AJAX components declaratively in a web page which is essentially using a serialized object to build the applicaiton from. This will be key and is the way things are going with XForms (W3C), XUL, XAML (Microsoft) and MXML (Adobe Flex). All this has me thinking more about microformats too … hmmmm.

I will say a bit more about what we can learn from OLE, declarative AJAX and clipboard soon!

Posted in AJAX, Architecture, Components, Declarative Programming, Web2.0 | No Comments » | Add to Delicious | Digg It

Scaling AJAX | April 21st, 2006

There has been quite the discussion in the past few days about a post from Billy Newport where he claimed that

AJAX enabled applications generate a higher load on an application server than a non AJAX applications

James Governor is not convinced, and Nate Schutta has his doubts, while Tim Bray takes the every pragmatic stance of “it depends”.

Wise Uncle Ben said it best when he warned young Peter that with great power comes great responsibility. In general, I think that AJAX lets developers better take advantage of client side processing of data and therefore on a one-on-one showdown of some piece of functionality, which can be implemented with either AJAX or using the old skool Web, then AJAX will win. For an example of this check out the story on AJAXian about MacRumours and their AJAX success.

However, once you decide to start using AJAX to record the mouse position on the client every millisecond then you are just asking for a world of hurt!

I think that AJAX does generally reduce server load if you are just streaming data up to the client for processing and keeping things simple.

Posted in AJAX, Architecture, Web2.0 | 2 Comments » | Add to Delicious | Digg It

EBA AJAX ComboBox JSF | April 20th, 2006

Thanks to the hard work of Godfrey, we have just released a beta version of our EBA AJAX ComboBox for Java Server Faces. We are trying to get all our current and new products built with support for JSF from the ground level and need your help to define the direction we want to take. Go and download the beta and let us know what you think!

Posted in AJAX, Architecture, Components, Eclipse, JSF | No Comments » | Add to Delicious | Digg It

Boring AJAX | March 3rd, 2006

Andre, Alexei and I had a chat with Coté and Stephen from RedMonk yesterday. They both seem (and no doubt are) very knowledgeable about the AJAX space - certainly compared to other analysts with whom we have spoken (and shall remain nameless). Not only did they seem genuinely interested and understand the business problem that we are trying to solve but they (thankfully) didn’t even try to sell us their services! They seem like the kind of people we could work worth as we grow our business in the coming year.

What they understood was that the real value of AJAX is quite boring. It is in the mundane spaces like ERP - not the exciting, and ultimately fairly useless, arena of something like online maps. I have been talking about this idea of boring AJAX for some time and maybe people are starting to see that those enterprise systems like CRM are where the real benefits of AJAX will be found. Needless to say, that is precisely the market that we are targeting with our high performance components.

Posted in AJAX, Architecture, Business, Web2.0 | 4 Comments » | Add to Delicious | Digg It

Cross Domain AJAX with XML | February 10th, 2006

On a post I made a few days back I proposed a way to do cross domain AJaX using XML rather than the commonly used JSON. It is essentially an extension of the idea of JSONP (JSON with Padding). Since I generally find myself working with XML more often than JSON I decided to create the equivalent for XML based applications. I have not extensively tested it but did try it on IE6 and FF1.5 on Win2K server.

So here it is. The idea is that we pass an id, a context and a method as querystring parameters to a server script such as http://www.enterpriseajax.com/cross_domain_xml.asp?context=myObject&method=onXmlLoaded&id=1000 and we get back some JavaScript. That JavaScript can then be injected as a script tag in your web page.

This will then return JavaScript code that creates an XML document object and loads an XML string into it. Once the XML string is loaded into the object it then calls a callback method such as myObject.onXmlLoaded() and passes it the XML object that was created.

The id querystring parameter is used to uniquely identify each XML document that is requested, the conext is the object on which the callback is called and the method parameter is the name of the callback function.

The JavaScript returned from the pervious resource is this:

if (typeof(eba_ajax_xmlp) == "undefined"){

    var eba_ajax_xmlp = {x: {}};
    eba_ajax_xmlp.loadXml = function(s, uid){
        if(document.implementation && document.implementation.createDocument) {
            var objDOMParser = new DOMParser();
            this.x[uid] = objDOMParser.parseFromString(s, "text/xml");
        } else if (window.ActiveXObject) {
            this.x[uid] = new ActiveXObject('MSXML2.DOMDocument.3.0');
            this.x[uid].async = false;

            this.x[uid].loadXML(s);
        }
    }
}
eba_ajax_xmlp.loadXml('This XML adata is from EnterpriseAjax.com‘, ‘1002′);
myObject.onXmlLoaded.call(myObject, eba_ajax_xmlp.x[’1002′]);

This is slightly different from the JSONP way of doing things but for the most part it’s the same sort of thing.

Try it out for your self with the sample page here - you should see an alert with contents of the loaded XML (just a root tag).

Note there is nothing on the Enterprise AJAX site but there will be soon :)

Posted in AJAX, Architecture, JSON, XML | 12 Comments » | Add to Delicious | Digg It

What Makes a Service Last? | January 20th, 2006

I have been intently following Dion, as you do, over at the good old SOA Blog. One recent post is, as usual, more of the same commentary about Web 2.0 and SOA.

In his latest post Dion suggests that:

“Writing software from scratch will continue going away. It’s just too easy to wire things together now. Witness the growth of truly amazing mash-ups of which things like Retrievr and Meebo are only two tiny examples.”

This is a bit too far off the Web 2.0 global SOA deep end for me. Retrievr is admitedly an interesting mash-up but is it really “truly amazing”? Is it something you need to use everyday - something to write home to Mom about? I suppose it could be considered amazing from the perspective of available mash-ups but in general mash-up quality and usefulness is relatively low. From what I can tell the main reason to provide API’s to your software is to either:
a) get more users and increase your valuation when selling your Web 2.0 company to Yahoo!
b) hope that Google likes your mash-up and hires you
c) gain the support of the increasingly trendy niche of hybrid “programmer / blogger / never the cool kid in school” types to help you achieve goals a) or b)

d) attract attention to attain status of trendy hybrid “programmer / blogger / never the cool kid in school”
(please leave any other ideas in comments below)

Flickr in itself is only marginally amazing, and it was written from scratch - shock horror!

If one even considers what a mash-up really is, one finds that we have always developed software by “wiring things together” have we not? I can imagine with every level of programming language abstraction there is some journalist somewhere who heralds it as evidence of a new golden age of programming productvity. The only difference here is that programming languages - unlike mash-ups - can actually be useful!

The real amazing software that I find myself using is that which actually *enables* the mash-ups; for example, Google or eBay have great technology and are products/services that can not simply be created by mash’ing up a few JSON based JavaScript streams in a browser.

In his latest post, Dion even says:

“Maybe software developers should just go back to sprouting acronyms and delivering software that doesn’t do what people want.”

To me, he is trying to say that Web 2.0 let’s people build good, useable software - this is sort of true and I am a big believer in AJaX of course. However, I would like to know how many social networking, tagging, blogging, sharing //insert buzz word here// Web 2.0 applications we need!

The actually point that I was thinking about when I gave this post a title was that I just don’t understand why creating REST based services is really that open, easy, or robust? At least with Web Services and WSDL one can automatically build a C# or Java proxy for a service and even have JavaScript emitted for use on the client, can you do the same for the del.icio.us REST API so easily? In fact I find it astounding that an API such as that of Flickr, which is actually quite robust, does not even have a standard WSDL based description of the bindings (addmitedly some aspects of the API are not that complicated to warrant SOAP based services but at least a binding description would be nice) - my point being that it seems to me WSDL descriptions (or any kind of machine readable one for that matter) of mash-up enabling APIs are a few and far between despite the fact that they are actually quite useful for generating proxies etc. Also, how will these supposedly simple services work with the Semantic Web? I am not sure the Semantic Web will be that easy in itself so does that mean we should forego it and just settle for Web 2.0 or maybe 1.5? Well yeah maybe we should :S I guess I could be alone in thinking that the Semantic Web is what we should really be talking about rather than mashing-up Google with Craigslist (I know, Google + Craigslist is sooooooo 2005). The whole idea of an API for a service that one has to actually physically read makes me shudder - haven’t people had enough of mapping inputs and outputs to services (whether they are REST or otherwise)??? Maybe I should quit complaining and define a REST service description language (RSDL) that is a simple version of WSDL …

I suspect this drive to simplicity is going lead us down a path we have been on before. As you make things more simple you also, generally, make them less valuable. I know that many take the KISS principle too literally sometimes and apply it to the nth degree. Sure Google is pretty damn complex but they also have billions of dollars in revenue - complex and valuable. On the other hand, look at Retrievr - simple and worthless. Choose your poison.

Posted in Semantic Web, Service Oriented Architecture, Web2.0, XML | No Comments » | Add to Delicious | Digg It


Search Posts

You are currently browsing the archives for the Architecture category.

Archives

Categories