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...

Back again

It has been a long time since the last post. However, from now on I will be posting on a regular basis. There is a chance of changing the name of the blog as well. But thats for the future. Now its time for ranting. Yes rant. Its about GMap API.

The simple app I had created works well from my home where there is no router or proxy per se. But, when I tried it from my friend's home pc which is behind a proxy, it started to show Paulo Alto even when I gave coordinates of India. Whats the problem here? Any idea anybody?

Sorry For No Post

I am extremely sorry as my schedule is not allowing to make any new posts. Once I am through the schedule I will start again.

GMap Animation and Events -II: Events

A quick look at events supported by GMap. GMap supports event handling through the Event listener pattern. The class that provides support for event handling is GEvent class. The addEventListener() method of GEvent class. It takes three parameters:

1. Object of GMap:

The map on which event has to be applied.

2. The event to be Handled:

It is a string. The string contains event names. There are two commonly used events:

i. click:

It is the most common of all the events. It is generated (or happens) when one presses and releases the left mouse button on the map.

ii. moveend:

It is generated when the user stops navigating or panning the map. It essentially means end of moving a map.

Following code shows how to use both types of events:

The code is a slight modification of the initial code to display map.

function load() {

if (GBrowserIsCompatible()) {

var map = new GMap2(document.getElementById("map"));

//map.setMapType(GMapType.G_HYBRID_MAP);

map.addControl(new GSmallMapControl());

map.addControl(new GMapTypeControl());

map.addControl(new GScaleControl());

map.setCenter(new GLatLng(31.122027, 77.111664), 13);

GEvent.addListener(map,"click", function(){

alert(map.getCenter())

}

);

//for the event moveend

GEvent.addListener(map,"moveend", function(){

alert(map.getCenter())

}

)

}

}

The getCenter() method of the GMap2 returns the current focus latitude and longitude of the map. That’s all for this quickie.