Rails 2.0: Why change the scaffolding

Rails 2.0.3 is now in market. There are many changes such as multi-views, using Model objects as resource handlers etc. However, the main change is how the scaffolding is done. Gone are the days of issuing Scaffold command and the table to be scaffolded. For example, if the name of table to be scaffold is Emp having Id and name . In the pre 2.0 era I would have given the following command

ruby script/generate scaffold Emp empAdmin

That would have generated the model named Emp with controller having the name empAdminController and the related views. Now how things have changed in 2.0

ruby script/generate scaffold Emp name:string

Yes, I had to pass the non id attributes to the scaffold command. Now if it is a trivial table with 3 or 4 columns then well and good. However, a table in real world will have atleast 15 columns then its just too much. I know scaffold is not seen as a good parctice in 2.0. However, scaffold was the reason I admired Rails. Now it seems like Rails is also making development a bit complex. Apart from that Rails 2.0 is really great.

Active Records v/s Hibernate - Round II

Welcome to the round two of Active Record v/s Rails. This round is based upon implementation of ORM classes. Lets start with Hibernate. The steps to implement ORM class in Hibernate are:

1. Name the class (preferable) according to the table. For example, if table is named Employee, then the class is also named Employee. This is preferable but optional.
2. Next declare the instance variable corresponding to the attributes of the table with which class is to be mapped. For example, if the Employee table has an attribute named Name, then the class will have an instance variable named Name. Its data-type will be the Java equivalent of SQL type. If Name attribute is varchar, the name instance variable will be String.
3. Last step is to implement getters and setters for the instance variables.

Next let us see how to do this with Active Record

1. Name the class according to the table. For example, if table is named Employee, then the class is also named Employee. This is mandatory if you do not want to override the defaults.
2. Derive the class from Base class of ActiveRecord package. For example, the Employee class needs to be derived from Base::ActiveRecord.

Thats it just two steps. No need to declare any instance variable or any getter/setter. So how does Rails gives you the data? It does it as follows:

1. When the ORM object is created Rails reads the schema of the table and through meta-programming, creates corresponding instance variables in the ORM object.
2. Next, Rails populates the object with the data from the table.
   

Using meta-programming and reflection Rails dynamically does everything. In the next post the third round will start on the basis of Query Language supported by both.

Active Record v/s Hibernate - Round I

You will have heard of shiny new web application framework called Ruby-on-Rails also known as RoR or simply Rails. It provides complete stack from ORM framework to Web Service. From this post onwards for next couple of posts I will compare and contrast between different components of JEE and Rails. I will begin with Hibernate from JEE and Active Record from Rails. The Round I of the Active Record v/s Hibernate will be on the basis of Mapping

The very first aspect is mapping. Hibernate requires the POJO (Java objects that represents the tables) be mapped with the tables using XML. That means if there is even a slight change in the Database schema such as the length of a particular field is changed, then you will have to make changes not only to the corresponding POJO but also to the mapping file. If you fail to do so, then run-time exception is the most common and the least problem that you will face.

Now lets look at Active Record. The driving principle of Rails is "Convention-over-Configuration" (but version 2.0 is deviating from it, more on that later). So , to map a class to a database table you just have to follow conventions. The conventions are

1. The class derives from ActiveRecord::Base i.e. Base class of ActiveRecord module
2. The name of the class must be same as that of the table
3. The name of the class should start with a capital letter (though this applies to all Ruby classes)

Thats it. No XML, no configuration. Even if there is a change in the table, the corresponding class will adapt to it automatically at runtime through reflection and meta-programming. So that is the difference between Active Records and Hibernate on the basis of Mapping. In the next post I will continue comparing the two on how ORM classes are defined.

Authors Note: I am really sorry for the gap between the posts. It wont happen again (this time for sure). For now on you can expect atleast one post in a week.

Accessing Managed Beans from backing bean

Sun created JSF as a competition for ASP.net. Though the idea is good, yet, the Sun stuck with the aspect of configuration. So if I need the framework to manage any of my beans automatically, then I need to specify it in faces-config.xml. Lets say my bean is named ResultBean, then I will have to put it as follows

<managed-bean>

<managed-bean-name>Result</managed-bean-name>

<managed-bean-class>org.me.ResultBean</managed-bean-class<

<managed-bean-scope>session</managed-bean-scope>

<managed-bean>

Now let us say there is another bean named ValueSetter, which is also a managed bean, wants to access the ResultBean, then the technique is classic Java technique. It goes something like as under

• Get a reference to FacesContext which essentially is ServletContex when compared to Servlet
• From FacesContext reference get current Application object
• From Application object get a reference to VariableResolver object
• Call resolveVariable method on it passing reference of the FacesContext and the name of the bean as string (not the class name)

In code it will be as follows

FacesContext context = FacesContext.getCurrentInstance();

ResultBean bean = (ResultBean) context.getApplication().getVariableResolver().resolveVariable(context, "Result");

As you have seen how many objects need to be used. Cant it be made simpler?

JSP and Servlet - Implicit objects

JSP provides following implicit objects

1. request
2. response
3. session
4. page
5. application
6. exception
7. pageContext
8. out

The first question any interviewer or external asks is to name all the implicit object. The next question is which Servlet object corresponds to which JSP implicit object. So from this post onwards I will discuss this aspect. This post looks at request object.

You will be knowing that when JSP is compiled, it becomes a Servlet. HttpServletRequest is one of the two objects passes as arguments to the service method of the Servlet class. In case of compiled JSP, the name of the service method is _jspService, the only method that a developer cannot override. When the compilation takes place the request object is accessed as an object of HttpServletRequest. To cut a long story short request object corresponds to HttpServletRequest. In the next post I will discuss about response and out objects. Till then keep visiting...

Why Annotations cant be used always?

That exactly what my question is. JEE 5 gives you a choice to use annotations instead of configuration files almost everywhere - even in Servlets. However, why such a facility be extended to frameworks such as JSF where I still have to use configuration files.

Frameworks including JSF needs to be compilation stage as well as configuration stage to deploy them successfully. If servlets can be deployed without configuration file(web.xml), then why such a facility is not being extended to JSF? I am leaving out Struts because its outside Sun's control. And get me wrong, I am not against configuration. My only question is when an alternative is available and such an alternative can ease development, then why is not being implemented? With that I stopping my rant.

EJB 3.0: A Step in the Right Direction

In the last post I ranted about problems with GMap. However, this time its not a rant. Thats right EJB 3.0 is a step in the right direction. The reason are as follows

1. No more configuration files. Annotations takes care of all the configuration. For example to tell container that a class Test is a Session bean, you will annotate it as follows
@Stateless public class Test{ //rest of the class }
2. No more home or remote interfaces. Just a simple Java class with annotations. Simple Java classes are known as Plain Old Java Objects or POJO. All the types of Beans in EJB 3.0 are based on POJO. So you dont need to extend or implement any interface. Take a look at the above example. It is a Stateless Session Bean, yet, does not extends or implements any Remote, Home or Bean interface.

3. Clients dont need to depend on JNDI. Instead dependency injection is used. More about dependency injection in next post.

4. Entity Beans now have full support for CRUD operations. CRUD is short for Create, Retrieve, Update and Delete. Prior to version 3.0, Entity Beans supported only limited Retrieve operation (also known as Select operation) that did not include full joins.

Thats all about new features of EJB 3.0. In the future posts, I will discuss about development using EJB 3.0. Visit again...