Great article about forms and ways of implementing data validation for the web applications.

Highly advised to read.

I’ve preached to all my customers and co-workers the importance of Continuous Integration. Now I’ll be pointing them to this training course – they’ll learn and will have fun at the same time.

It’s hilarious!

Let’s see how we can improve our UI by adding some watermarked “spice”:

Let’s define the primary style for the text box (textInput) and the dependent style for the watermark (textInput-watermark):

.textInput {
	border: 1px solid #C9C7BA;
	font-family:Tahoma, Verdana, Arial, Helvetica, sans-serif;
	font-size: 11px;
	padding-left: 2px;
	padding-top: 2px;
}

.textInput-watermark {
   /* background-image: url('images/overlay.gif');
   background-repeat: no-repeat;
   padding-left: 20px;
   vertical-align: middle; */
   font-style: italic;
   color: DarkGray;
}

Note that the watermark style can contain images as well (see the commented out piece).

After the styles were defined we need to add some code that will apply it to the text box. To do this I’m going to extend the default GWT TextBox. The trick is to hijack the OnBlur and OnFocus events. When the OnBlur is occurring, we’re going to show the watermark and OnFocus – hide it:

public class WatermarkedTextBox extends TextBox implements BlurHandler, FocusHandler
{
	String watermark;
	HandlerRegistration blurHandler;
	HandlerRegistration focusHandler;

	public WatermarkedTextBox( )
	{
		super();
		this.setStylePrimaryName("textInput");
	}

	public WatermarkedTextBox(String defaultValue)
	{
		this();
		setText(defaultValue);
	}

	public WatermarkedTextBox(String defaultValue, String watermark)
	{
		this(defaultValue);
		setWatermark(watermark);
	}

	/**
	 * Adds a watermark if the parameter is not NULL or EMPTY
	 *
	 * @param watermark
	 */
	public void setWatermark(final String watermark)
	{
		this.watermark = watermark;

		if ((watermark != null) && (watermark != ""))
		{
			blurHandler = addBlurHandler(this);
			focusHandler = addFocusHandler(this);
			EnableWatermark();
		}
		else
		{
			// Remove handlers
			blurHandler.removeHandler();
			focusHandler.removeHandler();
		}
	}

	@Override
	public void onBlur(BlurEvent event)
	{
		EnableWatermark();
	}

	void EnableWatermark()
	{
		String text = getText();
		if ((text.length() == 0) || (text.equalsIgnoreCase(watermark)))
		{
			// Show watermark
			setText(watermark);
			addStyleDependentName("watermark");
		}
	}

	@Override
	public void onFocus(FocusEvent event)
	{
		removeStyleDependentName("watermark");

		if (getText().equalsIgnoreCase(watermark))
		{
			// Hide watermark
			setText("");
		}
	}
}

Gotta love this …

Thanks for all the attendees. You’ve made this event a success! Thanks to all the organizers – without you this would have never happened.

You can find all the pictures are on Flickr and all the the presentations are hosted on the on Architect Factory collateral page (hosted on Azure Cloud).

You can access my presentation directly on the Slide Share:

Note: check out the price analysis article of “True Cost of Hosting” of a big web application deployments on Amazon AWS infrastructure – HotPads

Prerequisites: make sure that you have all the Azure SDK tools installed for your VS2008.

(1) Start by creating a new “Web Cloud Service” project in the Visual Studio. Give it a nice name.

(2) Add a new “WCF Service” to the WebRole project.

(3) Define a required contract:

The most important part here is to put attributes that will tell the WCF in what format to send/receive the message body (XML or JSON) …

[ServiceContract(Name = "service", Namespace = "http://www.igorshare.com")]
public interface IContactManagerService
{
    [OperationContract]
    [WebGet(UriTemplate = "/contacts", BodyStyle = WebMessageBodyStyle.Bare,
       ResponseFormat = WebMessageFormat.Json)]
    List<Contact> GetAllContacts();

    [OperationContract]
    [WebGet(UriTemplate = "/contacts/{filter}", BodyStyle = WebMessageBodyStyle.Bare,
       ResponseFormat = WebMessageFormat.Json)]
    List<Contact> GetContacts(string filter);
}

[DataContract]
public class Contact
{
    [DataMember]
    public string FirstName { get; set; }

    [DataMember]
    public string LastName { get; set; }

    [DataMember]
    public string Company { get; set; }
}

(4) Implement the service logic:

public class ContactManagerService : IContactManagerService
{
    private static readonly List<Contact> Contacts = new List<Contact>() { ... };

    public List<Contact> GetAllContacts()
    {
        return Contacts;
    }

    public List<Contact> GetContacts(string filter)
    {
        string f = filter.ToLower();

        var contacts = from contact in Contacts
                       where contact.FirstName.ToLower().Contains(f)
                            || contact.LastName.ToLower().Contains(f)
                            || contact.Company.ToLower().Contains(f)
                       select contact;

        return contacts.ToList();
    }
}

(5) Configure it to be exposed as a RESTful service:

To make it REALLY, REALLY simple for you, do this trick:

a) Comment out the system.serviceModel section in the Web.config file

b) Add the Factory attribute to the .svc file

<%@ ServiceHost Language="C#" Debug="true"
Service="ContactManagerCloudService_WebRole.ContactManagerService"
CodeBehind="ContactManagerService.svc.cs"
Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>

(6) Build the service

You’re interested in 2 artifacts of the build:

1. .cscfg file – configuration for the Cloud Service deployment
2. .cspkg file – all the bits packaged (zipped)

At this moment you have 2 choices:

1. Run your project in the local Development Fabric (for testing and debugging), or …
2. Deploy it to the Azure Cloud (for staging or production)

To deploy your application to the cloud, do right-click on the CloudService project and select “Publish”.

Visual Studio will launch the Azure Service Developer Portal page. Log-in to your account, create a project and deploy your bits to the staging environment:

This is it!  You’re good to go.

BTW: make sure that your application works in the staging environment and then you can push it to Production by just switching it with the Staging.

Note: Check out a great explanation about the difference between the WCF REST Configuration for ASP.NET AJAX and plain REST Services by Rick Strahl.

Stay tuned …

Stay tuned …

As you know that in XML you can represent the same data in variety of ways by using fields, names, attributes, etc..

The same is true to JSON. In many cases different serializers produce different JSON representation of the same objects.

JAX-RS (as well as Jersey) provide you control over what and how you want to serialize. This is accomplished via providers.

Here is an example of such provider (Note that the class should be marked with @Provider annotation):

@Provider
public class JAXBContextResolver implements ContextResolver<JAXBContext> {
    private JAXBContext context;
    private Class<?>[] types = { ListDescription.class }; 

    public JAXBContextResolver() throws Exception {
        JSONConfiguration config = JSONConfiguration.natural().build();
        context = new JSONJAXBContext(config, types);
    } 

    public JAXBContext getContext(Class<?> objectType) {
        for (Class<?> type : types) {
            if (type == objectType) {
                return context;
            }
        }
        return null;
    }
}

Note that by creating an appropriate JSONConfiguration (JSONConfiguration.natural().build()) you, in fact, control the output JSON format. The JSONConfiguration class provide 4 different JSON formatters:

1. natural (Jackson)
2. mapped
3. mappedJettison
4. Badgerfish

Here is how the output will vary, depending on the choice of the configuration. Don’t forget that the class should be annotated with A simple class (with fields (int)ID and (String)Name) added to an ArrayList and then returned back as a @GET return value:

@XmlRootElement
public class ListDescription
{
	public int ID;
	public String Name;
}

@GET
@Produces({MediaType.APPLICATION_JSON })
public List<DataListInfo> getAllLists()
{
	List<ListDescription> lists = new ArrayList<ListDescription>();
	ListDescription ls = new ListDescription();
	ls.ID = 1;
	ls.Name = "Test";
	lists.add(ls);
	return lists;
}

This is what you’ll get from each configuration (respectively):

mappedJettison:

{"listDescriptions":{"listDescription":{"ID":1,"Name":"Test"}}}

mapped:

{"listDescription":{"ID":"1","Name":"Test"}}

natural (jackson):

[{"ID":1,"Name":"Test"}]

Badgerfish:

{"listDescriptions":{"listDescription":{"ID":{"$":"1"},"Name":{"$":"Test"}}}}

In the previous article (Part 1) we’ve seen how to create a web-based REST-full client (and an appropriate server) by using GWT. GWT is not providing any “standard” REST (if you can use this word in REST context at all) interface, but, merely, exposes the server-side logic via a proprietary GWT RPC interface.

Today, the most common REST standard is the JAX-RS specification. By implementing your code along the JAX-RS guidelines you can be rest assured that you can easily switch one REST-RX library with another.

As of today there are a couple of JAX-RS libraries used by the Java community:

1. Jersey
2. Restlet
3. Portlet
4. etc…

On the other hand, being a big fan of Spring, I was hoping that Spring will provide the JAX-RS support in it’s Spring v3 release, but, looking at the M3 drop, I have realized that it’s nowhere near that promise (check my discussion on the StackOverflow).

For this post I’m going to use Jersey JAX-RS implementation. Let’s start with creating

a Dynamic Web Project in Eclipse. I’m going to use:

1. Apache Tomcat v6.0
2. Dynamic Web Module v2.5
3. Default Configuration for Apache Tomcat v6.0

To add Jersey (1.1.0-ea) into this mix, add the following JARs (from this obscure installation instructions page) to your build path:

1. asm-3.1.jar
2. jsr311-api-1.1.jar
3. jersey-bundle-1.1.0-ea.jar
4. jersey-json-1.1.0-ea.jar
5. jaxb-impl-2.1.10.jar

Don’t forget to add these JARs to the “Java EE Module Dependencies” (in the properties of the project) as well.

Let’s define our Web Service. By using the JAX-RS specification it becomes extremely easy:

@PerRequest
@Path("/contacts")
@Consumes({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
public class ContactManagerService {
    final static List<ContactInfo> contacts = new ArrayList<ContactInfo>();
    static {
        contacts.add(new ContactInfo("Joe", "Simth", "Some Company"));
        contacts.add(new ContactInfo("Tom", "Doe", "Another Company"));
    } 

    @GET
    public ContactList getAllContacts()
    {
        return contacts;
    } 

    @GET
    @Path("{filter}")
    public ContactList getFilteredContacts(@PathParam("filter") String filter)
    {
        ...

        return ContactList.fromContacts( contacts );
    } 

}

A couple of things to notice here:

1. The “root” path to the ContactManager Web service marked by tompost annotation @Path("/contacts"), is: /contacts
2. This class returns data in both application/json and application/xml formats. This is defined by the @Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML }) annotations.
3. The “default” method for this web service is “getAllContacts”. This is happening because this method has NO @Path annotation.
4. The “getFilteredContacts” will be called if the Web Services URL will contain a non-empty addition to the root URL, like this: /contact/joe
   1. Note that this addition should be URL-encoded
   2. If you’d like to replace it with the query param – replace the annotation with the @QueryParam one. In this case the call will look like /contacts?filter=joe

The ContactList, that is returned to the client, should be annotated with @XmlRootElement so Jetty will fire up an appropriate the JAXB provider for the serialization (we’ll talk more about providers later):

@XmlRootElement
public class ContactList { 

    @XmlElement
    protected java.util.List<ContactInfo> contacts; 

    public ContactList() { ... }

}

As you can guess, there is no magic in the world (I, actually, still hope that there is some so, to make our service visible to the outside world, we need to make sure that Tomcat loads Jersey which, in its order, will load and expose our service according to our annotations. This is done via the additional configuration in the web.config file:

<!-- Servlets -->
<servlet>
    <servlet-name>ContactManager Web Services</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>ContactManager Web Services</servlet-name>
    <url-pattern>/services/*</url-pattern>
</servlet-mapping>

After completing all the above you can start Tomcat and use any of the available REST test clients like Fiddler, RESTClient or RESTTest (see discussion on StackOverflow) to see our service in action.

The root URL to the ContactManagerService is http://localhost:8080/ContactManagerServer/services/contacts.

If the request will contain header “Accept: application/json” the result will look like this:

{"contacts":[{"FirstName":"Joe","LastName":"Simth","Company":"Some Company"},
{"FirstName":"Tom","LastName":"Doe","Company":"Another Company"}]}

On the other hand the header “Accept: application/xml” will produce result like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<contactList>
	<contacts><FirstName>Joe</FirstName><LastName>Simth</LastName><Company>Some Company</Company></contacts>
	<contacts><FirstName>Tom</FirstName><LastName>Doe</LastName><Company>Another Company</Company></contacts>
</contactList>

Disregard format of the returned content for a moment, we’re going to talk about serialization in later posts.

More information about the JSON support in Jersey can be found in the Jersey User Guide.