There’s been lots of exciting news this summer about JavaScript performance improvements. We have Firefox’s TraceMonkey, Safari/WebKit’s SquirrelFish, and Google Chrome’s V8 all improving by leaps and bounds. On a sightly less exciting note, IE8 will contain 400 fewer memory leaks.

This is all very exciting for developers of highly-interactive web-apps, and it makes the Appcelerator style of client-side templating and interactivity even more responsive for the end-user. Though you may not see ray-tracers and bioinformatic apps being run in next year’s browsers, you’ll definitely see more processing and application state being moved from the server onto the client.

One rather surprising thing that speedy JavaScript enables is new languages inside your browser, like Objective-J or to some extent Appcelerator’s web expression mini-language. The surprising part about Objective-J is that it actually parses and interprets a full, real programming language when you open up a page. Seems like a lot of work, no? Regardless, the apps it generates are quite responsive.

Another project that could use a modern JavaScript engine to change how we develop web apps is something like Prophet, a distributed database that supports offline use because of its “self-healing conflict resolution”. Though it’s written in Perl, a port to JavaScript might now be feasible, enabling developers to construct applications that operate with all of their data management and business logic in the client.

There will of course be cool uses of JavaScript that we can’t even predict yet. Many thanks are due to the clever compiler hackers at Mozilla, Apple and Google!

ShareThis

The long-held best practice is that an ideally structured website will have it’s content completely separated form it’s presentation. For websites, there’s no fault I can find in this approach. After all, you can change a lot about the site through some simple css tricks, stylesheets give you the most tools to work around browser bugs, and inline javascript is ugly and inflexible.

However, the situation changes when you stop making web-sites and start using the web to build applications. For one, markup is no longer there to suggest to a browser “hey I think this should be bold.” It defines necessary functionality for user interaction. Elements become interactive controls.

This doesn’t mean you can’t separate out the control functionality from presentation, but more that it doesn’t make sense. The fundamental reason for separation of concerns is to allow one aspect to change without the other. However, this no longer holds true. A pretty common semantic refactor is changing the ID of an element because it’s name no longer describes what it does. In JQuery, this means you’ll a situation like this.

<script type="text/javascript" charset="utf-8">
    function attach() {
        $('#submit_button').click(function() { /* do some nasty js for ajax */ });
    }
</script>
 
<button id="submit_button">Request More Info</button>

“Submit_button” is a pretty crappy name, so when you change it, you need to change two different places. The concerns aren’t so separate after all.

With a modern, interactive web application, it makes sense to put the functionality inline with the markup around the content. It’s how you would define things in most thick-clients anyway. It reduces the amount of problems that can arise through simple refactors. It’s also a cleaner for the code-base, since it allows one to move elements around without the need for a monstrous, custom-functions library.

ShareThis

This is the first of a series of blogposts in which I will explore the impact of an open-source business model on different aspects of a software company. During my tenure at both JBoss and Red Hat and now at my current employer Appcelerator, I have witnessed these sometimes subtle, often dramatic, effects from finance to sales to engineering to IT to support to marketing to legal to human resources. Everyone is affected in an open-source company.

I have always enjoyed technical recruiting. Probably a result of my first employer (Tallan) emphasizing the importance of everyone participating in the recruiting process. The company actually tracked statistics on which employees had passed/failed interviewees and the success/failure of those interviewees who were actually hired. There were no direct financial rewards for being the best interviewer, but there were definitely some bragging rights. It was during this time that I realized just how different hardcore technical recruiting is from almost any other position. When companies hire accountants, managers, lawyers, marketers, and salespeople, so much of the decision was based upon a candidate’s history, his/her personality, and his/her attitude. However, when a company is trying to fill a highly technical position, the VAST majority of the decision (hopefully) falls on his/her technical accumen. Technical recruiting is different… and for good reason.

One of the most difficult challenges facing companies who need to fill highly technical positions is to accurately assess a candidate’s skillset and knowledge. Notice that I distinguish between knowledge and skills. While I do actually understand the bodily mechanics, balance, and coordination necessary to dunk a basketball… I still do not possess the athletic skill to do so. Oftentimes, the HR department won’t even attempt to evaluate the technical aptitude of a candidate, just assuming that the candidate’s proficiency on any technical skill listed on the resume is likely to be sufficient for the position’s requirements. That’s not a dig on HR, how on earth would we expect them to evaluate whether a candidate who lists Oracle as a skill is capable of installing Oracle, designing datamodels, or tuning Oracle databases? It takes a rockstar to know one (”…it’s just a handful of people in the world who can tell the difference between you and me. But I’m one of them.” – from Goodwill Hunting). When companies do actually attempt to assess technical talent it is often conducted haphazardly by someone who would rather be coding than interviewing candidates. Either way, the result is that the quality of technical talent within an organization fluctuates more than the price of crude oil. And because companies loathe the concept of shedding weak talent, mediocrity becomes the accepted standard.

Enter open-source.

The introduction of open-source into a software company’s business model adds a new way to evaluate the technical accumen of potential hires. When looking to add new members to the team, no talent pool can compare with the members of that project’s open-source community. Rather than conducting a series of interviews to determine the best candidate, you can easily see who the most engaged, most insightful, and most talented community members are based on their comments, their posts, their blogs, and their code contributions. This approach to recruiting results in a ruthlessly efficient “weedout” process allowing a company to easily identify the best possible candidates. Much like the ability of open-source software to prove it’s value before a company invests in support, this model requires a job candidate to prove his/her value prior to consideration.

During my tenure at JBoss I specifically remember that the HR department was not allowed to interview or source candidates for positions on the core development team. You first had to be a contributor. And if your contributions showed that you were a rockstar, then we would send you an email and ask if you would like to make your hobby into your job. Few people declined because it gives them a chance to work on something they are personally interested in (which isn’t necessarily true for most programmers).

Next week, Appcelerator will have our first official hire directly from our community. Kevin Whinnery (formerly of Lawson Software) will be joining our team as an evangelist. Kevin has been one of our most active members to date and is in the process of writing a book about Appcelerator. This is a perfect example of someone who clearly proved their worth in advance… and we are thrilled to have him coming aboard. Welcome to Appcelerator Kevin! Are you next?

ShareThis

Appcelerator is attending ZendCon this week, talking with developers and vendors about great innovations within the PHP community. To break up the continuous cycle of keynotes and breakout sessions, we decided to capture a few conference attendees on video and find out what they really think about PHP. You might be surprised to hear some of the responses!

We have it all in our footage – PHP lovers and haters, cool apps, the worst PHP gaffes and the highs and lows of working with the scripting language. We even got attendees to confess their true feelings about cars, Disney characters, and Britney Spears. Yes, you heard correctly. Britney Spears. Check out these uncensored ZendCon PHP developers on our YouTube channel.

ShareThis

It’s the GUI stupid!

Many years ago, I consulted for a large semi-conductor company during the early stages of a software project. They had a highly detailed and fairly rigid process for software projects that started with a complete requirements document based on an extremely verbose and granular template. As the project progressed and I saw the size of the document balloon from 50 pages to more than 200 pages, I had the realization that this document would never be read by ANYONE from beginning to end. The business owners who were responsible for ensuring that the requirements fit their actual business needs were completely overwhelmed by the document’s size and complexity. Six months later the business users were given their shiny new software and they were disappointed that the software didn’t match their expectations.

In reality, the software was a very solid effort that met all of the requirements specified in the document. However, business users had no ability to read the requirements document and imagine what the user interface might look like for the requirements provided. I remember feeling that the business owners didn’t know what they really wanted and feeling resentful of that fact. In retrospect, I realize that almost nobody knows exactly what they want, until they see it. Why? Because to a user, the interface IS the software. Concepts like data models, middleware, rules engines, LDAP, and SSL have no real meaning outside of us techies.

So how do we avoid this? Is Agile Development the answer? Agile is definitely a step in the right direction. It codifies the practices that had evolved in the most successful and most productive software development teams of the 1990s. However, we need more. We need to enable our development teams to prototype the user interface quickly and easily so that users can actually see (better yet, use) the software EARLY in the process. In web 1.0 this was a fairly straightforward effort of building static HTML wireframes. The problem was that this work was largely throwaway b/c they had to be rebuilt as servlets, JSPs, ASPs, PHPs, etc.

As our web applications become more sophisticated this approach starts to break down even further. Today, rich internet applications include syndicated content, widgets, DOM manipulation, Ajax calls, and often a substantial amount of JavaScript. Static wireframes just cannot easily emulate this kind of rich user experience accurately.

What If?

What if you could build the user interface prototype in a matter of days or weeks without a single line of server-side code or even a datamodel? What if the business owner could not only play with this prototype, but also provide context specific feedback seamlessly while exploring the prototype? Finally, what if the prototype wasn’t a prototype at all, but was the actual user-interface of the final product (zero throwaway code)… even if you haven’t decided which server-side technology you want to use (Java, .Net, Ruby, PHP, Python, Perl)?

This is exactly how we develop software for our consulting customers today using the Appcelerator platform. We’ve been doing this for over a year now, but we haven’t really given it a name until recently. We call it “Interactive Use-Cases”. Essentially, we skip the entire functional requirements definition phase and move directly from use-cases to working prototype! This is only possible because of the advantages that the Appcelerator platform provides us. Let me explain.

Technological Enablers

First, Appcelerator’s widget library, web expression language, and message-oriented architecture were designed to enable web developers to build UIs with the minimal amount of code (read: JavaScript) possible. As an example, Ajaxian’s Dion Almaer posted a small interactive web page on his blog and invited people to port it to their favorite JavaScript framework. Compare the ViewSource of the Appcelerator version to those of the other frameworks. More app + less code = better productivity.

Second, the fact that you are not generating your HTML from server-side scripts frees you from the wasted effort associated with building throwaway static wireframes. Build applications as Ajax enabled .html files which dynamically pull data/content from the server and (re)render those sections of the page accordingly.

Third, our message-oriented architecture is ideal when prototyping because message subscribers in the browser do not care about the source of their messages (that’s the point of publish/subscribe architectures). So build the entire user interface with the exact messaging code that they will need for production use. But instead of building a datamodel, DAO objects, DTOs, business logic, and such to provide the actual service implementations, just add a single line to your webapp to include a single JavaScript file containing mock implementations of these backend services. In 90% of the cases you can mock that service with a couple lines of JavaScript that generates a JSON message with a mock payload.

My favorite part about this approach is that once you have gotten sign-off from the business owners, you can remove a single line from the application and all of the mock services have now been turned off. And the server-side programmers have a complete contract of every service which needs to be developed along with test data. Even better, they can choose to implement those services in any language they prefer because the UI is just producing/consuming JSON.

Fourth, thanks to a recent enhancement by Andrew Zuercher, we can easily collect user feedback on our user interface prototype by passing an additional URL parameter which highlights the border of any HTML control on mouseOver. By CTRL-clicking on any highlighted element a feedback dialog box appears that includes the specific page and HTML control being commented on. Users can see other users comments so that feedback effort isn’t duplicated. UI elements that already have comments are indicated with red borders.

Everyone knows that prototyping is a valuable exercise that improves the likelihood that the business users will be satisfied with the end-product. However, the limitations of web technology have made it prohibitively expensive and time consuming for all but the most critical web projects…… until now.

ShareThis

I love my Google Reader (especially the VI hotkey navigation). I really love the fact that I can take my RSS feeds offline with me when I’m about to jump on a plane. However, what happens when the concept of being disconnected from the Internet disappears?

I tend to be a ridiculously early adopter of technology and therefore end up with hopelessly outdated technology that costs 5x more than it should. I have always thought that connectivity should be independent of wires & location. From OmniSky (for my Palm Pilot in 1999) to Intel Anypoint (1.5 mbps baby) to digital phone cards (PocketPC) to EvDO cards… there’s almost never a reason not to have an IP address except on an airplane, a submarine, in a faraday cage, or in deep space. Since I’m unlikely to encounter three of those situations it’s really about the ability to access the net at altitudes of 30,000ft.

I just read today that Delta has announced it is going to provide WiFi on all domestic flights. And it seems JetBlue has been offering limited access since 2007.

As competition forces the cost of mobile connectivity to decline, offline may be a stop-gap solution that eventually becomes a solution in search of a problem. Now this doesn’t mean that some of the advancements that have been associated with offline will also disappear (local data storage, desktop integration, etc.).  They will continue to advance the ability of browser-based applications regardless of connectivity.  However, the idea that my user interface needs to be stored locally will soon seem quaint.

note: cross-posted at my personal blog

ShareThis

It was 1997 and I hadn’t really embraced the web yet as a programmer. While I had played with HTML, I was convinced that real developers wrote in C/C++ and PL-SQL. HTML was for sissies. One of my co-workers was building an online search engine for an e-commerce company and he introduced me to CGI programming. The idea of redirecting the incoming HTTP request to a script that generated HTML on the fly instead of regurgitating the contents of a file seemed immensely cool to me at the time. Technology advanced and I followed with SSI, then servlets, then ASP, then JSP, then taglibs, then struts, then JSF, etc.

However, I never really questioned the basic premise that web applications are essentially a simple collection of scripts which dynamically generate HTML documents and share a server-side context (http session). Afterall, all of the server-side web technologies I had used were based on the same fundamental concept that CGI had introduced back in 1995. Most innovations in this area were just further abstractions built on top of this concept (e.g. JSP custom taglibs). But abstraction is a double-edged sword. It eliminates the need to understand everything going on under the covers. However, each abstraction layer typically includes its own configuration (struts XML hell), quirks, and conventions. Which results in the need for someone to define “best practices” based on their personal pain of figuring out where the friction points are between the layers of abstraction that live just above and just below it (e.g. ValueObjects/DataTransferObjects).

Building web applications has become much more complex than necessary and the the development community has responded with simplification efforts (think Ruby on Rails, annotations, configuration by exception, etc.). Each of these efforts were a significant evolution of web application development, but none were revolutionary. While undeniably valuable, they were still just lipstick on CGI.

True Web Clients

There is an opportunity today that really hasn’t existed until recently (outside of building GUIs completely inside a proprietary player like Flash). Stop generating HTML on the server-side. Write rich web applications as standalone clients based on open standards such as HTML, CSS, and JavaScript. Call it Client-Server 2.0 if you like, but without the baggage of software distribution, version management, and platform dependencies. While JavaScript was the foundation of this revolution it was the introduction of CSS, DOM manipulation, and finally AJAX that allowed us to build truly standalone web clients.

So how do you go about building true web clients? Until recently it was actually rather painful to do so. You had to be a JavaScript guru and even then you typically were weaving together multiple 3rd party JavaScript libraries and frameworks to provide the necessary event handling, DOM manipulation, parsing, etc. Appcelerator was designed specifically to simplify the development of web clients so that mere mortals can develop them (not just the PhDs @ Google). Yes, you can use all of the Appcelerator widgets and even leverage the client messaging bus without giving up your HTML generation scripts (and many people do). But once you’ve experienced the elegant simplicity of developing true standalone web clients that invoke services for business logic & data access, you will never go back.

The shift is already underway. The client operating system IS the browser. See the rise of offline, single-site-browsers, and desktop web integration. The clients call services and re-render themselves accordingly. The only question remaining is… how long before you starting writing webapps as standalone web clients?

upcoming blogpost teaser : HTTP sessions are so 1998

ShareThis

The world of web development is moving away from MVC-based web architectures and towards a client/server model that is probably best described as RIA + SOA, where RIA represents the rich user interface and SOA represents the services that it consumes. There has been a lot of buzz around rich Web 2.0 applications, but they will not become mainstream until the next generation of web platforms emerge – fully integrated platforms that enable RIA + SOA.

State of the Union

Currently, in the standards-based world of HTML, CSS and Javascript, RIA developers have to assemble multiple third-party libraries and frameworks in order to build a rich user interface. This “a la carte” approach to building RIAs places an unnecessary burden on the developer. Instead of focusing on building applications, the developer must spend time finding, integrating, and versioning the various pieces of their RIA development platform. The same holds true on the SOA side; developers are left to figure out how to create services and how to integrate them with their RIA front-ends. Developers need a platform that addresses every aspect of building an application, so that they can focus on doing what they do best – build applications. The question is: what should a next-generation RIA + SOA platform look like? The best place to start is with the activities that are required to build an RIA + SOA-based application. At a high-level these activities include:

1. Design the “look” of the application

This is the general appearance of an application. It includes things like: color, fonts, graphics, and a general page layout.

Common toolsets: HTML, CSS and images

2. Integrate widgets

Widgets encapsulate a set of common capabilities within a single component. They typically contain both “look and feel” as well as a set of pre-defined dynamic behaviors. They are a fundamental building block of an RIA.

Common toolsets: ExtJS, Dojo, Yahoo YUI and several other small widget projects

3. Add dynamic behavior to the user interface

Creating dynamic behavior in the user interface involves two things:

• Event handling
• Document Object Model (DOM) Manipulation

Event handling is the ability to know when a particular event occurs (e.g., a user clicks a button or a service response is received). DOM Manipulation allows you to dynamically change the user interface based on the receipt of an event.

Common toolsets: Javascript libraries like JQuery, Prototype, and Scriptaculous

4. Consume services

Consuming backend services is a key capability of an RIA. It enables the creation of single page user interfaces that exchange application data with services. It also enables a clean separation between the user interface and the service tier. The most common method for interacting with services is Ajax.

Common toolsets: Javascript libraries like JQuery and Prototype

5. Create services

Services provide an interface to data and application business logic.

Common toolsets: There are several frameworks available for creating services in your programming language of choice

Now that we have a sense of what is required to build RIA + SOA-based applications, we can take a look at how these activities should be integrated in order to provide the most value to developers. The following sections outline the defining characteristics of a next-generation RIA + SOA platform.

Support for HTML and CSS

These two languages are perfectly suited for implementing the “look” of an application, plus they are familiar to most developers of web-based user interfaces. There is no reason to recreate the wheel.

Provide an Open Widget Framework

As stated earlier, widgets are a fundamental building block of RIAs. There are several widget toolkits available from the likes of Yahoo, Dojo, and ExtJS. There are also several standalone widgets that have been created by smaller projects and individuals. You can build RIAs using these widgets, but there are some catches:

• It’s unlikely that one widget offering is going to meet all of your needs
• Integrating different third-party widgets may require custom code as well as an in depth understanding of how each widget works
• Writing new widgets is challenging because you either have to write to the low-level API of your preferred widget toolkit, or you have to write your own from scratch
• Some widget frameworks require developers to write a significant amount of Javascript just to use their widgets, which is problematic for those with little to no Javascript experience.

In order to address the problems above, an RIA + SOA platform should provide an Open Widget Framework that has the following capabilities:

• Support integration of existing third-party widgets
• Provide a simple API for creating new widgets
• Enable widgets to be used via simple markup (no Javascript required)
• Support a distribution model that makes it easy to submit, find and use new widgets.

An Open Widget Framework will provide developers with one source for obtaining widgets and one simple way to integrate these widgets into their application. If a particular widget is not available, it can be easily created using the Open Widget Framework API.

Given the importance of widgets within RIA development and the fragmented nature of widgets today, an Open Widget Framework should be considered an essential part of any RIA + SOA platform.

Provide an Integrated RIA Programming Model

Developing RIAs requires significantly more user interface code than traditional web-based applications. As a result, a next generation platform needs to provide an integrated RIA programming model that facilitates and simplifies the key user interface programming tasks. These tasks include:

• Event handling
• DOM manipulation
• Service consumption (Ajax).

Event handling, DOM manipulation and Ajax enable the “rich” in rich Internet application. It doesn’t take much investigation to see that they are closely related. To illustrate this point, let’s look at the typical steps involved with an RIA login form submission:

• Login button is clicked (event handling)
• Service request is sent (Ajax)
• Some type of activity indicator is displayed (DOM Manipulation)
• Service returns (Ajax)
• Activity indicator is hidden (DOM Manipulation)
• A Login “success” message is displayed (DOM Manipulation).

Despite their close relationship, most frameworks and libraries provide only light integration between the three, leaving the developer to bridge the gap. To illustrate this point, let’s look at some code. In the example below, we will set the contents of one combo box when the value of a second combo box changes. This example is written using JQuery:

1
2
3
4
5
6
7
8
9
10
11

$(function(){
  $("select#comboOne").change(function(){
    $.getJSON("/combo.php",{id: $(this).val(), ajax: 'true'}, function(j){
      var options = '';
      for (var i = 0; i < j.length; i++) {
        options += '<option value="' + j[i].optionValue + '">' + j[i].optionDisplay + '</option>';
      }
      $("select#comboTwo").html(options);
    })
  })
})

Now, let’s look at how this could be accomplished using a fully integrated approach to event handling, DOM manipulation and Ajax.

1
2
3
4
5
6

<select id=”comboOne” 
on=”change then r:load.combo2.request”>
</select>
<select id=”comboTwo” 
on=”r:load.combo2.response then value[property=rows,text=text,value=value]”>
</select>

These two examples accomplish the same thing, but in very different ways. The first example requires more code and it’s all in Javascript. The second example uses a simple expression language to do the same thing. Let’s take a closer look at the syntax.

1

on=”change then r:load.combo2.request”

In this expression, the Ajax request message r:load.combo2.request will be sent when the <select> gets a “change” event – pretty simple. Now, let’s look at the second expression:

1

on=”r:load.combo2.response then value[property=rows,text=text,value=value]”

When the Ajax response message r:load.combo2.response is received, the contents of the second combo box are set based on data in the response message.

Let’s take this example one step further by adding a visual queue when the response message is received.

1
2
3
4

<select id=”comboTwo” 
on=”r:load.combo2.response then value[property=rows,text=text,value=value]
and effect[Highlight]”>
</select>

By adding and effect[Highlight] to our expression, we are able to incorporate a subtle effect that lets the user know that the combo box values have changed.

These code examples demonstrate the power and simplicity of a fully integrated approach to event handling, DOM manipulation and Ajax. Developers that have little to no Javascript experience will find it easy to learn an expression language like the one above. It will enable them to get productive quickly, since they don’t have to climb a steep learning curve. Of course, there are developers that are comfortable with Javascript and would prefer to use it. As a result, an integrated RIA programming model should also support the use of Javascript, specifically in a way the supports the separation of behavior from markup. This is commonly referred to as unobtrusive Javascript. Let’s look at an example:

1
2

<img id=”progress_image” src=”images/indicator.gif”/>
$(“progress_images”).on(“r:login.request then show”).on(“r:login.response then hide”);

In this example, the <img> markup is separate from the Javascript code that defines its behavior – i.e., “show” when the login request message is received and “hide” when the login response is received. This type of programming model is good for developers that prefer to do their RIA programming in Javascript.

An Integrated RIA Programming model is a fundamental component of an RIA + SOA platform. It provides developers with a single integrated mechanism for handling the major RIA programming activities. The net result is that developers can build rich user interfaces faster and with significantly less code than is required today.

Provide an Integrated Services Platform

RIA only gets us halfway to our goal of building a rich application. We still need to provide an answer for the SOA piece of RIA + SOA. Unfortunately, the current crop of Web 2.0 toolkits and frameworks primarily focus on RIA; they provide little to no support for building services. This is problematic because developers are, once again, left to bridge the gap, which makes application development and maintenance unnecessarily more time consuming and difficult than it should be.

A next generation RIA + SOA platform must address this gap by providing an integrated services platform that provides the following:

• Support for creating services in any programming language
• Seamless interoperability between the RIA and SOA tiers
• Ability to consume local mock services .

Historically, web-based frameworks have been built around a particular programming language, but in the world of RIA + SOA this practice seems outdated and unnecessary. RIAs only need to exchange application data with services, so they should be programming language agnostic. The only required link between an RIA and its SOA-based services should be a lightweight message-based contract. This loose coupling between the RIA and SOA tiers opens the door to a integrated services platform that enables developers to use any programming language for service creation without impacting the RIA tier of the application.

An integrated services platform should also provide seamless interoperability between the RIA and SOA tiers. Specifically, it should handle service routing and data marshalling on behalf of the developer. Here’s an example of a simple integrated approach to building a service. This particular example uses Java.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Service (request = ‘login.request’, response =’login.response’)
protected void loginRequest (Message req, Message resp)
						throws Exception
{
	String username = req.getData().getString(“username”);
	String password = req.getData().getString(“password”);
	User user = UserDAO.login(username,password);
	if (user !=null)
	{
	          response.getData().put(“success”,true);
	          response.getData().put(“user”,user);
	          return;
        }
        response.getData().put(“success”,false);
 
}

In the example above, there are two things to notice. First, a plain Java object is turned into a service by simply adding a “Service” annotation to a Java method. This annotation contains both the service request and service response message that this method handles, which makes routing configuration easy. Second, working with service request and response data is simple and straightforward. In the example, the entire User object is placed into the response message. The service platform handles the data marshalling. The result is that developer can focus on writing service logic instead of writing glue code, which ultimately results in faster development with less code.

Finally, if the contract between the RIA and its services is message-based, then it becomes possible to create local mock services. Local mock services respond to remote requests but they exist locally within the RIA. This is a powerful capability because it opens the door to creating fully functional RIA prototypes without writing a single line of service code. These local mock services can be placed in a single file and removed once user interface development is complete. Let’s look at an example.

1
2
3
4
5
6
7
8
9

<!-- Progress indicator -->
<img src=”images/indicator.gif” style=”display:none
on=”r:login.request then show or r:login.response then hide”/>
 
<!-- Login form -->
Username: <input type=text” fieldset=”login” id=”username”/>
Password: <input type=”password” fieldset=”login” id=”password”/>
<input type=”button” value=”Login” 
on=”click then r:login.request”/>

1
2
3

<app:script on=”r:login.request then execute after 1s”>
	$MQ(‘r:login.response’,{‘success’:true,’username’:’foo’});
</app:script>

In the example above, we have a login form that generates the service request r:login.request. We also have an image that will show when r:login.request is received and hide when r:login.response is received. The second part of the example is the mock service. The mock service listens for the r:login.request service request and responds with a r:login.response message after one second in order to simulate service latency. The login form has no knowledge of the service location; it simply responds to messages. This simple example demonstrates how an entire RIA prototype can be built without writing any service code. This prototype would be 100% reusable, and it has the added benefit of enabling developers to define the service contracts in advance of service creation. The result is that service creation is greatly simplified because service developers not only have a fully functional prototype as a reference; they have a complete set of service interfaces.

Conclusion

Developers are currently caught in the middle of a fundamental shift in web application development. We are moving away from the server-side MVC frameworks of Web 1.0 and towards a client/server architecture for the web, or more specifically RIA + SOA. As a result of this shift, developers have been left to piece together their web development platform for rich web applications. Of course, change creates opportunity. The opportunity in this case is to build a next generation web platform that provides end-to-end support for building Web 2.0 applications. At Appcelerator, we saw this shift coming well over a year ago. Our response was to build the Appcelerator Platform; a platform built from the ground up to support RIA + SOA. The examples used in this article are based on Appcelerator. Of course, many different approaches will be taken to create the next generation of web platforms, but while the specific implementations may differ the general characteristics should remain the same.

ShareThis

Purpose

The Appcelerator framework allows for the extension of the build and deployment process so that you can add components and modify the behavior of your service implementations. It is quite powerful and not only restricted to services, plugins for example could span across to the modification of applications and the entire build and deployment process for that matter. For simplicity, this article will identify how to create a new component added to our java service for monitoring performance.

Install Appcelerator

I’ve assumed that you’ve successfully downloaded and installed Appcelerator from http://www.appcelerator.org/products. Once you’ve gone through the installer you can get the java service

1

  app install:service java

You may want to get an existing plugin (I needed the java:spring plugin to implement my plugin):

1

  app install:plugin java:spring

Plugin Creation

Lets assume that our plugin is going to be called java:perf, to create the plugin project:

1
2

  cd $HOME/workspace
  app create:plugin . java:perf

This will create a sub directory named java_perf, now you will want to create a proper license entry in your build.yml for example check out build.yml. You now have the opportunity to modify the entry points in your java_perf.rb. I personally wanted to setup my install script so that:

• it dynamically builds the jar when we add the plugin to a project
• modifies the spring.xml to include the bean entries for my component

All of this is in before_add_plugin(event) callback. If you want to see where this is called, check out add_plugin.rb. Once my coding is complete (added my source files to java_perf/src), I created the plugin distribution:

1

rake zip

Install the plugin

As you noticed, I haven’t covered debugging the plugin just yet, this is because I want to first set up the plugin for installation and then work with it in my install directory. Lets install it to the local machine:

1

app install:plugin java_perf.zip

Add the plugin to my project

I thought that I’d create a blank java project real quick

1
2

cd workspace
app create:project . myproject java

now we can add the spring plugin and our new java:perf plugin to our project

1
2
3

cd myproject
app add:plugin java:spring
app add:plugin java:perf

You can now directly modify the java_perf.rb file in your install directory

• windows: c:/Program Files/Appcelerator/releases/plugin/java_perf/1.0
• unix: /usr/local/Appcelerator/releases/plugin/java_perf/1.0
• mac os: /Library/Appcelerator/releases/plugin/java_perf/1.0

I suggest that you continue to modify the java_perf.rb this way to debug it and then finalize by copying back over to $HOME/workspace/java_perf

Next Steps

As a final parting you can release your new plugin so that others may be able to leverage it

1
2

cd $HOME/workspace/java_perf
app release java_perf.zip

-andrew

this article is cross posted at:
http://zuerchtech.com/2008/3/4/implementing-an-appcelerator-plugin

ShareThis

Purpose

If you are venturing to implement a Rich Internet Application (RIA) with Appcelerator, then there are features about the framework that I’m really geared up about that help you implement your solution effectively. When used together these items enable the agile creation of solutions in a shorter time that integrate nicely with services in an existing architecture and provide a richer user experience for clients.

Achieving Re-use

There are a bunch of ways to do this, personally I leverage app:content files judiciously. You can provide args in the definition of your content files so that you can use the same content file over again. Some things to keep in mind:

• reference the args as #{argname} in your element ids, any variables, and make sure that functions you call take this into account (possibly make them stateless)
• the order in which the content file is loaded to make sure that listeners are properly setup to respond to messages

here is an example app:content reference

1
2
3

<app:content lazy="false" on="mainstate[person] then show else hide" 
  args="{'prefix':'person'}">
</app:content>

here is the content.html file

1
2

<div id="#{prefix}header" ...
</div>

I know that this may be abstract, but the point is that you can use the arg “prefix” to reuse the file and provide alternative behavior based on it.

Mocking Services

You can mock out server side services extremely easily with the framework. This is extremely useful whether your goal is:

• Visual Use Cases: implementing a prototype that results in 100% useable application code
• Working offline: no need to run a web server at all, you can directly run off of a simple file

Once you have this in place, you have a well defined contract in place which makes knocking out the service implementation a snap.

No restart

If you are just working on your application (no service work), you can directly make changes to your application without requiring rebuilding and redeploying your application. In java I typically work directly in my tomcat deploy directory and have an ant task to pull the web files into my workspace. With our next version of the framework coming out, this will be even easier with our support for Jetty coming and the Ruby based command line tool. In the meantime, the following is useful in your java project:

1

ant pullweb

Make sure that you have your deploy.dir setup in your $HOME/.ant.properties for example:

1

deploy.dir=/Applications/apache-tomcat-6.0.14/webapps

With our Ruby implementation for example, this is even easier (running webbrick directly in your workspace).

Great Support for Model Objects

I’ve touched a bit on this in a previous post on JSON serialization with Appcelerator java services. To summarize the framework enables

• Hibernate persistence: ModelObjects can easily be used with our Hibernate integration
• JSON serialization: Serializing and deserialing complex objects is a snap

Slick support for forms

In case you haven’t looked, you dont need to include a form tag anywhere in the application: simply add a fieldset attribute to your input elements and put something like this

1
2
3
4

<input name="age" fieldset="save_person" type="text"/>
<input name="name" fieldset="save_person" type="text"/>
<input value="Create Person" fieldset="save_person"/>
  on="click then r:create.person.request" type="button"/>

This will create a message of type r:create.person.request with the payload being all your input elements with fieldset of “save_person” ex:

1

{'name':'jim','age':'35'}

To me, this is very eloquent solution to leveraging form input elements with a messaging architecture.

Easy to use UI widgets

I love some of the widgets that are at your fingertips. Some of the ones that i use the most

• app:panel: slick styling
• app:datatable: great way to show rows of data
• app:chart: fantastic visual effects to bring life to data

All these widgets have a very terse usage that is very intuitive. For example, using this set, I was able to knock out a realtime dashboard application in 3 evenings.

Service Platform Options

Pitching the right framework is something that varies from project to project. For example, possibly your client wants to leverage an existing java infrastructure and is sold on its robustness for scaling enterprise applications, while on the other side possibly you want to take advantage of using a Rails controller and ORM/Active Record implementation for rapid development. On the same level you also have the option for implementing services to customers that deliver in a .Net solution architecture. Many other platforms also exist (python, PHP) enabling the opportunity to plug into those services as well.

The app:get non-visual widget also makes pre-existing services accessible as well and since Messaging is at the heart of the implementation, plugging into an ESB or pure MOM framework is perfectly setup as well.

Wrap Up

In this article 7 key tips have been covered

• re-use
• mock services
• no restart
• model objects
• messaging & forms
• UI widgets
• platform options

Although there are more items that have not been covered here, these are the ones that appeal personally to me and have noticed a huge gain in doing much more with less effort.

this article cross-posted at http://blog.zuerchtech.com/2008/02/26/effectively-implementing-appcelerator-rias-and-services/

ShareThis