Programmers Quotes

Ruby on Rails development took place because of individuals needing a database backed web program that doesn’t have any obligation to an operating system. Ruby Rails also has a wide range of web servers and databases. With Ruby Rails, it was developed to operate with any operating system to build applications that are database backed.

This open source web development framework, which has literally taken the web application world by storm. This is a complete infrastructure that allows for the development of web applications in real time. Its popularity is growing and is proving to be a threat to Java and .Net. when it comes to application development.

Advantages

Ruby on Rails development took place in 2004 and a number of advantages do exist with this type of technology. Here are some of the advantages:

* Ruby on Rails supports MySQL, Postgresql, Oracle, and a variety of others.
* Developers are able to received detailed error logs in order to debug applications.
* Users have the ability to develop URLs and dynamic websites that are search engine friendly.
* Its model view architecture allows a separation between data and logic.
* There are so many libraries that the coding of common programming languages has been simplified.

It is all of these advantages that have made Ruby on Rails a very popular framework. It allows for rapid application development, so that means that there is no more having to wait for long periods of time for an application to be built.

Who has enjoyed Ruby on Rails Development?

There are many sites that have enjoyed Ruby on Rails development? Social networking sites, community sharing sites, blogs, and many more sites have taken advantage of Ruby on Rails. This is why there has been a steep rise in demand. The newest version of Ruby on Rails that was developed in 2008 is 2.0, which enables the development of web 2.0 applications. It is superior to programming languages, such as PHP, ASP, and Java. Ruby Rails development ensured that it would be more advanced than .NET and Java.

Many companies, particularly those that are outsourced to use the power of Ruby Rails to develop websites that are database driven, are finding a lot of success with Ruby Rails. They are able to create applications that benefit their clients greatly. They basically leverage the power of Ruby Rails by combining rails framework with Ruby programming. Even PHP programmers have been successful in developing scalable and robust applications that are very affordable. This also enables these companies to have fast turnaround times because applications are so quick to create.

Being that we live in a world that wants everything done immediately, it only makes sense that Ruby Rails development took place in the first place. It is making the technological world operate a little bit faster than what it used to and everyone is loving it. Eventually, Ruby Rails development will lead to even more advanced technologies that are even faster and better than ever.

For the past couple of months, I’ve been developing a GWT application using a mix of plain ol’ GWT and GXT widgets. When I first started developing it, I didn’t know how to best organize my code and separate the logic. The solution I came up with was to adopt some sort of MVC framework. Since I was already using GXT, I opted for GXT’s lightweight MVC implementation.

As mentioned in Testing GWT Applications, GXT’s MVC doesn’t have much documentation. The best reference documentation seems to be Christian’s Getting started with Ext-GWT: The Mail reference application.

Page Transitioning with Dispatcher
After working with GXT MVC for a couple months, I’m still not sure I fully understand how navigation and event dispatching works. The biggest point of confusion for me is how to best use GXT’s Dispatcher class.

The problem with Dispatcher is it has a two methods that seem to do the same thing.

• forwardEvent (4 variations)
• dispatch (3 variations)

In addition to these methods in Dispatcher, there’s two fireEvent methods in GXT’s View class. According to my calculations, that means there’s 9 different options for transitioning from one view to the next. Which one is best to use?

From what I’ve learned, I think it’s best to use fireEvent in Views and forwardEvent in Controllers and other widgets. IMO, dispatcher should never be used except in your HistoryListener’s implementation onHistoryChanged method. The important thing to realize about this method is it should only work if the View’s Controller is registered for the event.

However, fireEvent seems to work even when the View’s Controller isn’t registered for that event. This is because onHistoryChanged gets called in the EntryPoint. For experienced GXT MVC users, does this navigation handling mesh with your findings?

The most important thing for navigation to work successfully is enabling History support. The next section talks about how to do this effectively.

Enabling History Support
To help explain things better, I created a simple GWT MVC Example application and used Maven to create an archetype with it. You can create a project from the archetype using the following command:

mvn archetype:create -DarchetypeGroupId=org.appfuse.archetypes \
-DarchetypeArtifactId=gwt-mvc -DarchetypeVersion=1.0-SNAPSHOT \
-DgroupId=com.mycompany.app -DartifactId=myproject \
-DremoteRepositories=http://oss.sonatype.org/content/repositories/appfuse-snapshots

To enable history support in this application, I implemented HistoryListener in my EntryPoint (Application.java) and added the following logic to initialize:

In this example, HistoryTokens is a class that contains all the URLs of the “views” in the application.

In order to make URLs like http://localhost:8080/#calendar go to the calendar view, the following logic exists in the onHistoryChanged method.

Controllers are registered in the EntryPoint as follows:

Controllers respond to events they’re registered for. This is done in their constructor:

In order for navigation to work, you have to create links with history tokens¹. For example, here’s a link from the HomeView class:

You’ll notice in this example, I’m using Dispatcher’s fireEvent method. If I wanted to pass some data with your event, you’ll need to use forwardEvent. Here’s an example from CalendarView:

In this example, you could also use Dispatcher.dispatcher(), but I believe this will cause the transition to happen twice because the onHistoryChanged method gets called too. This doesn’t matter for the most part, except when you start to use DispatcherListeners.

Hopefully this article has helped you understand how GXT’s MVC framework works. I’m interested in learning how other GWT MVC frameworks work. If you’ve used one, I’d love to hear about your experience.

Friday Fun Test
Here’s a test for those interested in digging into the GXT MVC example. There’s a bug in this application that prevents something from happening. I’ll buy a drink for the person that finds the bug and I’ll buy two drinks for the person that comes up with a solution.

1. If you use the default constructor on Hyperlink and use setText(), make sure to call setTargetHistoryToken() too. If you don’t, a blank history token will be used and # causes the browser to scroll to the top before a page transition happens.