August 31, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

JavaServer Faces and ASP.NET - A Side by Side Look

  • December 22, 2005
  • By Michael Klaene
  • Send Email »
  • More Articles »

ASP.NET and JSF pages follow very similar lifecycles. We've discussed how components generate events based upon user actions but events are only part of this lifecycle. Taking a high-level view of the lifecycle of a page, it goes something like this: a user makes a request and the page is initialized, the entire component tree of the page is read in and the state of the components is restored, events are handled according to user actions and the values of components are updated, then the resulting page is rendered back to the user. Of course, it is much more complex than that and there are important stages such as data validation that fall in between those steps. One key difference between JSF and ASP.NET is how components are rendered to the user. ASP.NET components render themselves on the page. In JSF, components can render themselves, but more often they delegate rendering to special Renderer objects, made available in a 'RenderKit'. A different RenderKit can be supplied for each different type of presentation medium. A default HTML RenderKit is provided by every JSF implementation. What this all means is that the same JSF component can be rendered differently in a web browser or wireless device by simply plugging in a different Render object. This is a powerful capability.

A convenient point to add code not related to any specific type of user request is when the page object is initialized. ASP.NET provides a Page_Load event that is called when a user makes any kind of request against the page. With JSF pages, you can use the class constructor method for equivalent page initialization logic. Below is the event handling code for both applications that respond to actions users take upon the data display component.

    
    //ConferenceRooms.Java event code:

    public String btnViewReservations_action() {
        //Store selected room id and name of selected row...
        Object id = getValue("#{currentRow.value['conference_rooms.room_id']}");
        Object name = getValue("#{currentRow.value['conference_rooms.room_name']}");
        ReservationsSessionBean resBean =
                (ReservationsSessionBean)this.getBean("ReservationsSessionBean");
        resBean.setRoomId(id.toString());
        resBean.setRoomName(name.toString());
      
        return "view";
    }


    public String btnMakeReservation_action() {
        Object id = getValue("#{currentRow.value['conference_rooms.room_id']}");
        ReservationsSessionBean resBean =
                (ReservationsSessionBean)this.getBean("ReservationsSessionBean");
        resBean.setRoomId(id.toString());
        
        return "reserve";
    }

    //ConferenceRooms.cs event code:

    protected void GrdVwRooms_RowCommand(object sender, GridViewCommandEventArgs e)
    {
        if (e.CommandName.Equals("Sort")) {
            SortDirection sd;
            if (((SortDirection)Session["sortRooms"]).Equals(SortDirection.Ascending)) {
                sd = SortDirection.Descending;
            }
            else {
                sd = SortDirection.Ascending;
            }
            Session.Add("sortRooms", sd);
            this.GrdVwRooms.Sort(e.CommandArgument.ToString(), sd);
        }
        else
        {
            DataKey data = GrdVwRooms.DataKeys[Convert.ToInt32(e.CommandArgument)];
            Session.Add("roomId", data.Values["room_id"].ToString());
            Session.Add("roomName", data.Values["room_name"].ToString());

            if (e.CommandName.Equals("Reserve")) {
                Server.Transfer("Reserve.aspx");
            }
            else
            {
                if (e.CommandName.Equals("View"))  {
                    Server.Transfer("RoomReservations.aspx");
                }
            }
        }
    }

The code is a little different and the Java class is separated into two methods because that is how the IDE chose to do it when I double-clicked the view and reserve buttons from the visual designer. The two Java events are both 'Action' events. I chose to add all event logic in the ASP.NET application in a single 'RowCommand' event and interrogate the event's argument to determine which user event occurred. Grouping related events like this in one method is done quite often. This particular event handler responds to both the view and reserve button clicks and also sorting requests as a bit of sorting logic was necessary for this ASP.NET component. Both applications save the roomId and roomName attributes for use later in the application. Here is the complete code for ConferenceRooms.java and ConferenceRooms.cs. Keep in mind that much of the code in these class files is tool-generated and that you can use code folds in the editor to make things more readable. In these event methods, the values of page components are immediately accessible to you for reading and modification. I alluded to state management being a key benefit of each framework. Developers of thick client applications such as Visual Basic have taken such behavior for granted but it is a welcome change for web developers who used to have to set and retrieve state with additional code. ASP.NET and JSF preserve view state by writing it out in hidden HTML fields and passing it along from request to request. Of course, the same methods you used to store state in traditional ASP and JSP applications are still available to you. For example, in both the ASP.NET and JSF pages, room id and name are placed in the user's Session so it can be retrieved later.

Notice in the event code above that the ASP.NET file invokes a method called 'Server.Transfer' to transfer control to another page. In the JSF event code, however, you will not find any such direct reference to another page, only the return strings "view" and "reserve". This is because JSF handles page flows via the faces-config configuration file that we discussed earlier. This will look familiar to any Java developer who has worked with the Struts open-source framework. There are two entries in faces-config.xml under the ConferenceRooms.jsp, keyed on the strings "view" and "reserve". At runtime, the application looks up the page address using these strings. Below are the navigation rules in XML for the ConferenceRooms.jsp page found in the faces-config file. I created these mappings using a visual designer in Java Studio Creator.


    <navigation-rule>
        <from-view-id>/ConferenceRooms.jsp</from-view-id>
        <navigation-case>
            <from-outcome>view</from-outcome>
            <to-view-id>/RoomReservations.jsp</to-view-id>
        </navigation-case>
        <navigation-case>
            <from-outcome>reserve</from-outcome>
            <to-view-id>/ReserveRoom.jsp</to-view-id>
        </navigation-case>
    </navigation-rule>
Visual designer shows navigation rules in Java Studio Creator




Page 2 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel