Month: April 2008

Adobe Thermo – NextGen Designing

Adobe had announced Thermo a few months back and it sure is expected to heat up things. An Article was posted on eWeek.com. Excerpt..

“Thermo is a design tool that allows designers to choreograph the motion of a rich internet application, and it spits out code that can be handed off to a development team,” Heintz said. “The genesis of the technology came about because of the growing challenge of developers and designers working on projects. We wish we had more ‘devsigners.'”

Technology Hype

I was going through some content and came across an article on how an Emerging Technology goes through a Technology Hype. An excerpt from the article:

Web 2.0 technologies and business models dominate emerging technologies together with Real World Web and Application Architecture.

Egham, UK, August 9, 2006 – Gartner, Inc., today announced its 2006 Emerging Technologies Hype cycle which assesses the maturity, impact and adoption speed of 36 key technologies and trends during the next ten years. This year’s hype cycle highlights three major themes that are experiencing significant activity and which include new or heavily hyped technologies, where organizations may be uncertain as to which will have most impact on their business.

Full article.

AJAX

AJAX is a part of RIA, that has been heating up for some time now. Even though with newer and more richer technologies coming up like Flex, Silverlight, AJAX still remains the most commonly used option. I attended a workshop on AJAX today which had the participation was from a set of Senior Developers and Technical Architects who have been either working on AJAX or plan to use that. Below is a brief summary of the workshop.

Objectives

1. Compare AJAX with web 1.0

2, AJAX fundamentals

3. XHR and its role in AJAX

4. JavaScript and DOM

  1. AJAX and Web 1.0

5. AJAX frameworks – DWR, GWT, RICO and YUI

6. Technical aspects of AJAX in a project

Why AJAX?

  • Conventions Web applications handle data and presentation together and hence that leads to slower bandwidth
  • Faster response time is now desired
  • Enhanced Usability – moving close to Rich Internet Applications
  • Trying to do “Mashups” – bringing various Services together and bring in some meaning to the data

In the past, Sun proposed to use Applets for any kind of RIA stuff, but did not kick-off. Macromedia came up with ActionScript that can be used to create Flash files and help you more interactive content. Moving from a proprietary language to Open Source and more recently Flex is how Adobe acquired Macromedia bring this to developers. DHTML with IFrames was another option – but again is “more of a hack”, and is mostly suited for client-side richness.

Soon, people came up AJAX (Asynchronous Javascript And XML) – which was based on some of the existing frameworks and could be easily integrated with existing code/applications.

Next up was a quick demo of using the XHR object in a JSP and the intent was to show how we can use well constructed HTML v/s XML and then rendering the same on the client.

We moved to a JavaScript 101 and how can we quickly setup and re-use JavaScript and DOM and how to modify the styles and DOM object etc. Some of the very basic stuff, but good one. Very nice quick start demo on how to use the AJAX quickly on JavaScript. We moved on the most talked about issue in a Web 2.0 issue – History and Bookmarking. In a typical web 1.0 application, as we are moving from one page to another, the browser by way of changing URL keeps track of your navigation. But, with the XHR object, no changes to browser URL happen and “KPOW”. Now is the break time, but we are going to come back and see how this problem can be solved.

It was shared that RSH that supports the history with the browser. To understand the very basic, we need to change the browser URL on every request. But, that is something that we do no et out of the box. Some custom code has to be written. This is one way of talking to the browser, but we also need to write listeners for the changes to the browser URL. This way, we can communicate to back and forth to/with the browser. Looking quickly at the RSH library, it seems like a good starting point.
AJAX Cons

  • Increased complexity on Server as well as client
  • Dependency on JavaScript – you need to have advanced JS developers to highly optimize JS code
  • XHR is not yet standardized by W3C
  • Backward compatibility with some of the older browsers

Web 2.0

Web 2.0 is about creating applications which can be integrated with other applications such that users can use data in a anyway they want to view and use it. Web 2.0 application can be one that makes use of data from other applications which offer data as service and simply provide you a combination of all such services. In other words Web 1.0 was “I will create something and then provide that to the user”, while Web 2.0 talks about “I will create a service that someone else can offer to their customers”.

Challenges of writing RIA applications

  • How much code for working with XHR requests
  • How many clients do we need to handle
  • What is the data-format that we need to work with
  • Exposing Business Logic to the client

Hence we need to choose a Framework!! – we have way too many @Ajaxian.com. A framework needs to worry about:

  1. Server side – What kinds of clients do we need to handle
    1. JSF, DWR, GWT etc
  2. Network – How many kinds of clients do you need to provide service to
    1. Jason, XML, SOAP, RSS
  3. Client side – Need to deal with the data and provide that richness to the client
    1. DOJO, YahooUI, script.aculo.us, RICO

A survey was conducted in 2006, that shows what various AJAX libraries were being used

Focus on Server side of an AJAX application

Deep dive on DWR or Direct Web Reporting

Some insights:

  • Is a Java based technology to handle client-based AJAX requests
  • Uses an XML-based configuration that helps creating run-time JavaScript and gets exposed on the client-side
  • Exposes the Java object as Stubs on the client. You can then make calls to the stub and get data from Server
  • Has the capability to expose all the functions of an Object on the client
  • Takes care of the Server side aspects like using the same POJOs and passing on to the client. The Client can then handle the objects as they feel like
  • Offers integration with existing frameworks like Struts and Spring

There were a few more things, but not so much that I can write about. Hope you find this article useful.

Product Review – Flex Builder

Infoworld published a review on Flex Builder 3

You can have what you want !!

I started this endeavor to share my information with you all, so that some of you do not get stuck with the kind of things that I was stuck with. But, seems like I have millions to write about. So, I have decided to let you choose what do I blog about. Game plan is very simple, I will write in some of the topics that I want to write about and you can vote for them, or ask for new stuff. As I get the time (which is mostly a few hours on a weekend), I will pick up the ones with the most vote and start writing about it.

Visit the Vote section on my blog.

Cairngorm – A glamorous pitfall, Is it? – Part I

When I started using Flex a few months back, the very first tings thing that crossed me was the fan-following for Cairngorm. It was amazing how could a framework be so popular, but they claimed to solve all the problems. It seemed a little good to be true, but was worth trying. Over a period of last two months, I have now realized that Cairngorm has quite a few shortcomings that leads to be an overly glorified framework that can not scale for any Enterprise Application, without any changes. “Without any changes” is the key here. With this Article, I start off a series of articles that is my attempt to explain why I feel Some things in Cairngorm need to change.

“Cairngorm is an implementation of design patterns that the consultants at Adobe Consulting have successfully taken from enterprise software development (with technologies including J2EE and .NET) and applied rich Internet application development using Adobe Flex.” – Quoted by Adobe Labs

The benefits of the Cairngorm architecture are realized when developing complex RIA applications with multiple use-cases and views, with a team of developers, and with a multi-disciplinary development team that includes designers as well as creative and technical developers. – Quoted by Adobe

Steven Webster follows up with series of articles explaining details on how to use Cairngorm. The goals that Cairngorm helps us achieve are:

  1. Keeping State on the Client
  2. Architecting the View
  3. Feature-driven Development
  4. Server-side Integration

In this article, I will talk about the “Keeping State on the Client” aspect of the Cairngorm and I will be referring to the “Cairngorm Store Web 2.1” for any examples/references.

Steven introduces us to the Value Object pattern and the Model Locator pattern. As he quotes:

Many developers are familiar with the concept of MVC or Model/View/Control in application development, and wonder where state fits into this discussion. Quite simply, the state is the model.

In this case the ValueObject Pattern is one where you can use objects on the Client (Flex) and pass the same information to the back-end. If you are using LCDS/BlazeDS, then you get the benefit of using the same object in both the tiers. This is a great value add as developers do not have to maintain the overhead of heavy conversions on objects. Also, there are some tools available like XDoclet that will allow you to generate ActionScript objects from your Java POJOs and hence achieve quick and speedy results.

Model Locator pattern is the one that I find is the glorified pitfall. As Steven quotes again:

The Model Locator pattern is unique because it is not a pattern we borrowed from the Core J2EE Pattern catalog. Instead, we created this pattern particularly for Flex application development.Our motivation was to have a single place where the application state is held in a Flex application and where view components are able to “locate” the client-side model that they wish to render.

Great thinking, but the implementation is not what it should have been. A few of my observations:

1. Adobe has provided a marker interface “ModelLocator” which I do not understand why it is needed. The only driver that I can think of is to follow the OO practice – Develop against Interfaces and not implementations. Even though you would like to have your state/model divided into many ways, this does not makes sense. A Marker interface is used is you want to use things at Reflection, but in this case there is not such usage and is redundant. Model/state could have very well lived in the even without the Marker Interface

2. Use of singletons is where I believe which breaks the things. Steven quotes:

Having all the attributes on the Model Locator pattern as static attributes ensures that the Model Locator pattern is a simple implementation of a singleton. You ensure, for instance, that one and only one instance of a ShoppingCart exists per user.

Again, the intent is good, but the example that they took up is not at all good, is very bad. Let us take the example of the Cairngorm Store where they have used the Bindings to bind the Single Instance of the data to the view This simply couples the View with the State/Model and re-usability goes out of the window. <Kaboom/>. Code:

<details:ProductDetails
        id="productDetailsComp"
        width="100%" height="325"
        currencyFormatter="{ ModelLocator.currencyFormatter }"
        selectedItem="{ ModelLocator.selectedItem }" 
        addProduct="addProductToShoppingCart( event )" />

Consider a scenario, where in my application I want to use the component “ProductDetails” elsewhere, but as this component is now bound to the model/state, if I change the model, it effects the data elsewhere. Try adding the capability to compare the products, where you would like to re-use the same component to show the details in a comparative view. This component is useless and you can never get two different data sets to be bound to the same view.

But, do not just write-off this pattern – it is still very useful. All you folks who have ever developed the Web 1.0, know that a user’s session state is something that we have to manage in the HTTPSession and that was known as the state. You can use this pattern very well to do similar things like:

  1. Manage User’s Session State and use the same to check for authorizations;
  2. Show user;s navigation in the application. Almost all the applications have Breadcrumbs which should have just 1 state/model;
  3. Current View/navigation state of the user i.e. -> ViewStack indexes/TabView indexes

I am sure that there are more, but I find this pattern very useful in many ways; just have to be careful that over usage of the same would lead to some serious trouble.

Singleton – Boon or a Sin

Over last few weeks, I have faced quite a few issues with Cairngorm’s Singleton pattern and I decided to put forward a post that should help in making some decision. While I found a few articles about Singletons, but not even one that talks about how should we use Singletons.

Ask any programmer, and they will instantaneously discourage you with the use of global data (objects). But, many a times when you find a need where you have to have some objects available globally and also need a single point of access example: User’s state, permissions which has to be retrieved globally across the user session. And, it is then when you use the design pattern singleton.

When is a class really a Singleton?

Ask yourself:

  • Will every application use this class exactly the same way?
  • Will every application ever need only one instance of this class?
  • Should the clients be unaware of the application that this class is part of?

If you can answer all the above as a Yes, then you found a singleton – remember your Logger / Logging classes. Thats what you need as a singleton.

Now, let us switch focus to Flex, and how can we make use of a Singleton. As we all know that Flex is all about Events and thats how any two components interact wit each other. Singletons here become very handy, as you can dispatch en event on a Singleton Event Dispatcher and the component who needs to listen to it, can easily be listening on the Singleton. Solves many of our problems. Huh!! does it? I am putting down some code for the Buttons (which I am treating as a component). Try executing this code, and you will find that when you click on any one of the buttons, both the buttons handle the event and show and alert twice.

In my next article, I will explore the issues of Singleton with Cairngorm.

Is Defect a defect when not defined in a Test Script?

This question came up during an email thread that I had with some testers. Most of the testers had the view that a defect can be a defect even if it has not been defined in a test script, while I said that this is not true. The conversation went like this:

Tester: We can not put every scenario in a test script

ME: Yes you can

Tester: Can not because we can not think of scenarios while writing test scripts

ME: Then you should. Testers also think when they are testing, so what stops them from thinking when they are creating test scripts

Tester: It is not possible and also it is not feasible

ME: Not possible, I will disagree. Let us focus on the Not Feasible part

Tester: It becomes very difficult to document everything as then the scripts will run into multiple pages and maintaining them would be an overhead

ME That is not reason enough not to capture all that can be in a test script. You have to accept the fact that a test script can be incorrect. For a defect to be a defect, it has to be mapped against a missing requirement that should come from a document that can a client would have provided. If you can not provide a document/reference for the missing functionality, then there is not reason you can call it a defect. It is fine to log it as a TAR and discuss as a change request, but a defect i do not agree to.

Beyond this point, I started finding testers fumbling for words. No one out there could give me a solid answer to convince me. What are your views on the same? I blogged about why do i do unit testing and why do i feel we can cover all the scope in a test script. We developers do that for Unit testing, why can testers not?

Integrating Flex with Spring

When I started to look at building front-end of my application in Flex, the very first challenge was the back-end integration. Being on the J2EE tech stack, it was easy because of the BlazeDS provided by Adobe itself. But, still there was challenge to integrate the application with Spring. There was another option GraniteDS which provided Spring out of the box.

I was getting inclined to BlazeDS, for the top reason that it was provided by Adobe and at a later point if we ever needed to move to LCDS, it would be easy.

Once the decision was made, the problem that loomed at large was the Spring integration that was not taken care in the BlazeDS yet. And, I struggled quite a bit to get that working for my application. Below you will find detailed steps to provide an integration between Flex and Spring. For the purposes of this demo, I am assuming that you know how to configure Spring and already have that in place.

Setup your Spring destinations

1. You need to configure a factory that can be used to fetch spring beans from the J2EE container. To do that, you need to define an entry in the services-config.xml as:

services-config.xml

<factories>
<factory id=”spring” class=”com.kapil.myapplication.flex.common.SpringFactory”/>
</factories>

2. Now you have to define your destinations so that they can ask the Factory to get the bean to them. As I am using remoting (on AMF), I have configured the remoting-config.xml. The entries below state that that the destinaton “userService”, shoudl get the service from the SpringFactory

remoting-config.xml

<destination id=”userService”>
<properties>
<factory>spring</factory>
<source>userService</source>
</properties>
</destination>
Setup Spring Factory on the container

As I said that there is not out-of-the-box integration between BlazeDS and Spring, I wrote my own implementation of the “flex.messaging.FlexFactory” interface and placed that in the classpath of the J2EE container. Various methods that you need to implement are:

public void initialize(String id, ConfigMap configMap);

You do not have to write any implementation, through you can use this for doing any kind of initialization that you may need.

public FactoryInstance createFactoryInstance(String id, ConfigMap properties);

This method is called when we initialize the definition of an instance which will be looked up by this factory. It should validate that the properties supplied are valid to define an instance. Any valid properties used for this configuration must be accessed to avoid warnings about unused configuration elements. If your factory is only used for application scoped components, this method can simply return a factory instance which delegates the creation of the component to the FactoryInstance’s lookup method.

public Object lookup(FactoryInstance inst);

Returns the instance specified by the source and properties arguments. For the factory, this may mean constructing a new instance, optionally registering it in some other name space such as the session or JNDI, and then returning it or it may mean creating a new instance and returning it. This method is called for each request to operate on the given item by the system so it should be relatively efficient.

To do the actual lookup, you need to also subclass the FactoryClass interface. The class should have the following implementation:

public Object lookup();

Is the method that has the actual code for you to find the Spring bean. You can write which ever way to load the SpringContext and then find the bean. I had used the approach of a ServiceLocator which is a singleton and helps me find the bean from the common pool of beans. You can do whatever you like to do.

Hope this helps.

How many mistakes are you making?

James Ward from Adobe published another series of Top-10 on Flex. Great read.