querystring values and GET method

[Kevin Taylor]

I am very confused with this one. Where do I process querystring values needed to populate the managed bean in order to say allow a user to edit their personal information on a form. I have done development work in both .net and struts but I am not able to determine a way of performing this task in jsf. This is a standard activity in web applications. Between books and surfing the net I am coming up short on finding a solution for this simple task. Everything seems to indicate that I would need a servlet to stand in front of the page that uses jsf. Please say it aint so This would really make jsf appear limited. Any ideas would be greatly appreciated.

[Sergey Smirnov]

For starter, look at
http://www.jsffaq.com/Wiki.jsp?page=HowToPassAParameterToTheJSFApplicationUsingTheURLString

To initialize the bean property with the parameters string value is even easier. if you have &id=foo, the bean can be initialized like this:

<managed-bean>
 <managed-bean-name>user</managed-bean-name>
<managed-bean-class>bar.User</managed-bean-class>
 <managed-bean-scope>request</managed-bean-scope>
 <managed-property>
 <property-name>id</property-name>
 <value>#{param.id}</value>
 </managed-property>
<managed-bean>

--
Sergey : http://jsfTutorials.net

[Tim Holloway]

JSF is based on the concept of Inversion of Control. Instead of having to explictly request the data, the JSF framework injects the parameters into your backing bean automatically.

In other words, if you have a form with a field named "name", JSF will get its value and invoke the backing bean's "setName()" method, passing in in the value. You don't have to code anything except for the setName() method itself!

[Jeff Albertson]

While what Sergey writes is true, I think you will typically bind a text field on a form to a backing bean as follows:

<h:inputText value="#{user.id}"/>

As far as your servlet comment, I'm confused. If you have developed using Struts, you are familiar with the idea of controller servlet. It's the same in JSF: you will typically have FacesServlet as your one and only servlet.

[Kevin Taylor]

Right. My point of confusion centers around not seeing where or how the bean would be updated with values retrieved from the database. If this page were to allow users to edit personal information after they logged in the fields should prefill or prepopulate with their information, which would be retrieved from the database. Where in the lifecycle should the bean be called be prepopulated with their information. What bean property should be called to facilitate this. The only place I can see having this type of control in this framework would be in the PhaseListener, but that seems like it would kbe grossly inefficient. I am probably looking at this problem wrong but I really need clarity. Thanks.

Originally posted by Jeff Albertson:
While what Sergey writes is true, I think you will typically bind a text field on a form to a backing bean as follows:

<h:inputText value="#{user.id}"/>

As far as your servlet comment, I'm confused. If you have developed using Struts, you are familiar with the idea of controller servlet. It's the same in JSF: you will typically have FacesServlet as your one and only servlet.

[Jeff Albertson]

Ah, the penny just dropped for me. I didn't see where you were asking about database access in your original post... Anyway, I think of a jsp's "backing bean" as being part of the presentation layer, since it has UI component bindings and event handlers, so what I do is have business beans as properties of the appropriate backing beans. Your mileage may vary: my business beans are POJO since I hibernate... it can look like this:

public class BackingBeanX {
    private BusinessBeanY beanY;
 
    public void setBeanY(BusinessBeanY beanY) {
        this.beanY = beanY;
    }
 
    public void BusinessBeanY getBeanY() {
        if (beanY == null) {
            beanY = //get from database
        }
        return beanY;
    }
 
    ...
}

On a jsp page, I write <h:outputText value="#{pc_backingX.beanY.someProperty}"/>. There are some options here. Perhaps the bean is loaded by calling getBeanY (so the setter is not needed) or the setter is always called first, say from an action on another, earlier page.
[ February 02, 2006: Message edited by: Jeff Albertson ]

[Kevin Taylor]

I think I see where you are going with this. Would I have to put the h utputText ahead of the other components on the page for the output text to set all of the other properties on the page or is this necessary. Also, in this scenario would I have to keep an eye on POSTBACK so I dont perform a database pull and overwrite the new information the user just entered? The first page access sets a querystring variable to let the page know it has to populate from the database, which would be a get request. When the user modifies the data and fires the event to save their changes and eventually update the model I dont want the database pull to occur in this case. For data integrity as well as efficiency. Am I thinking along the right lines for this scenario?

Originally posted by Jeff Albertson:
Ah, the penny just dropped for me. I didn't see where you were asking about database access in your original post... Anyway, I think of a jsp's "backing bean" as being part of the presentation layer, since it has UI component bindings and event handlers, so what I do is have business beans as properties of the appropriate backing beans. Your mileage may vary: my business beans are POJO since I hibernate... it can look like this:

public class BackingBeanX {
    private BusinessBeanY beanY;
 
    public void setBeanY(BusinessBeanY beanY) {
        this.beanY = beanY;
    }
 
    public void BusinessBeanY getBeanY() {
        if (beanY == null) {
            beanY = //get from database
        }
        return beanY;
    }
 
    ...
}

On a jsp page, I write <h utputText value="#{pc_backingX.beanY.someProperty}"/>. There are some options here. Perhaps the bean is loaded by calling getBeanY (so the setter is not needed) or the setter is always called first, say from an action on another, earlier page.

[ February 02, 2006: Message edited by: Jeff Albertson ]

[Jeff Albertson]

Let me see if I understand your context -- does this sound right? For my example I assume you will manipulate user records. There is a page, user.jsp, backed by a manager bean that maps to class UserBackingBean which will manipulate business objects of the POJO type UserBean to do basic CRUD operations. Your jsp page is a form with input fields for say, username, password, email, etc... and submit buttons for create, retrieve, update and delete, perhaps.

What I wrote before will have to be tweaked a little for this set up. When you come to this page, unless the calling page or action has set things up with a UserBean, I would start it to be ready for creation or retrieval: (Previously, I assumed you *already* data for a unique index)

public class UserBackingBean {
    private UserBean user;
 
    public void setUser(UserBean user) {
        this.user = user;
    }
 
    public void UserBean getUser() {
        if (user == null) {
            user = new User(); //so that fields would be blank
        }
        return user;
    }
 
    ...
}

UserBackingBean will have actions wired to the user.jsp's submit buttons, and would change user as needed -- for instance if you entered a user name and pressed retrieve, the action would select the user from the database and populate its fields. (Searching with multiple results would need a different UI, of course.) In the case of an update, I typically write code that does an UPDATE (then commits) then a SELECT to recreate the bean over again and redisplay it. I do this as a reassurance to both me and the user that what they typed ended up looking like *this* in the database. If you don't want to do the select, leave the bean alone -- succeeding calls to getUser will retrieve the previous UserBean. Important: this assumes your backing bean has session scope!

I don't understand you concern about ordering components on the page. Also, here are some other common concerns:
1. Accidentally inserting the same data because you resubmitted the page. Here,the most elegant solution is for each business bean to have a natural or business ID that translates to a uniqueness constraint in the database. For user records, perhaps they need to have a unique username.
2. Accidentally updating twice by resubmitting. It's usually a good idea to do optimistic locking generally speaking, and that will catch this.
3. Accidentally updating when you just meant to view data. This is another preference, but I don't like data to be perpetually in "update" mode. When I've not explicitly asking to update, I want the data displayed in "read only mode". I'm not a fan of locked or disabled input fields, so what I typically do is include a state property in my backing bean (READONLY, INSERTING, UPDATING,...) and in READONLY mode render h:outputText instead of h:inputText. JSF makes that easy to do.

I hope this has answered your questions. I suggest you get something up a running to try things out -- create a simple table just for testing purposes with only a field fields, and a jsp page, backing bean and POJO to work with it. It will probably take less time to set that up than it took me to write this!
[ February 03, 2006: Message edited by: Jeff Albertson ]

[Tim Holloway]

One thing to bear in mind. Sometimes when using a POJO-style persistency mechanism such as JDO or Hibernate, the persistency objects don't fit well vs. the display. Among major offenders are date and boolean fields, since Oracle 8 has a date granularity that is in between java.sql.Date's and java.util.Date's, and the database has no boolean datatype at all. I tried a number of pretty complicated solutions before I finally realized that the simplest approach was to construct a Transfer Object that mapped to the display (such as having the fields bound to checkboxes be java booleans) and a Data Access object to pass the TO's contents in and out of the persistency mechanism.

[Jeff Albertson]

Maybe I'm lazy, but I usually can't be bothered to whip up a separate DTO. Take the example of wanting a boolean property but having a database that wants to map to CHAR(1). I would do this in my POJO:

private boolean foo;
 
    public boolean isFoo() {
        return foo;
    }
 
    public void setFoo(boolean foo) {
        this.foo = foo;
    }
 
    //for persistence:
    private char getFooField() {
        return foo ? 'Y' : 'N';
    }
 
    private void setFooField(char fooField) {
        setFoo(fooField == 'Y');
    }

Sometimes the mismatch is larger, like the database has a DATE field, but you want the UI to have separate day, month and year fields. In that case I still POJO-w/o-DTO, but my POJO has a component with individual year, month and day properties but also a Date property. Again, I can see where the mismatch between the UI and your persistent object would be so great (or perhaps your persistent object are outside your control) that the DTO anti-pattern was required, but I'm happier when I can avoid it.

[Kevin Taylor]

Lets explore the searching for multiple results option. Imagine I have a page that displays multiple records in a datatable format and the user clicks a link to perform an update on a particular row of the datatable. This link will take them to a page where they can edit the information for that row. If the link contains the unique id in the querystring, how can I populate the bean with the current values for the row they selected using the querystring value(id)? In other words, where in the bean can I retrieve all of the columns I need in one query and populate the Bean properties with the corresponding values from the database in one method.
Now there will be a getter and setter for each property of the Bean, but for editing I would rather pull the results in one place. Lets assume the page has a series of textboxes. Also, where would this method get called from the page in order for this to take place. This is where the ordering question came from. I would think this would have to be called before the other get methods are called. I am looking to place objects in the request vs. the session.

Originally posted by Jeff Albertson:
Let me see if I understand your context -- does this sound right? For my example I assume you will manipulate user records. There is a page, user.jsp, backed by a manager bean that maps to class UserBackingBean which will manipulate business objects of the POJO type UserBean to do basic CRUD operations. Your jsp page is a form with input fields for say, username, password, email, etc... and submit buttons for create, retrieve, update and delete, perhaps.

What I wrote before will have to be tweaked a little for this set up. When you come to this page, unless the calling page or action has set things up with a UserBean, I would start it to be ready for creation or retrieval: (Previously, I assumed you *already* data for a unique index)

public class UserBackingBean {
    private UserBean user;
 
    public void setUser(UserBean user) {
        this.user = user;
    }
 
    public void UserBean getUser() {
        if (user == null) {
            user = new User(); //so that fields would be blank
        }
        return user;
    }
 
    ...
}

UserBackingBean will have actions wired to the user.jsp's submit buttons, and would change user as needed -- for instance if you entered a user name and pressed retrieve, the action would select the user from the database and populate its fields. (Searching with multiple results would need a different UI, of course.) In the case of an update, I typically write code that does an UPDATE (then commits) then a SELECT to recreate the bean over again and redisplay it. I do this as a reassurance to both me and the user that what they typed ended up looking like *this* in the database. If you don't want to do the select, leave the bean alone -- succeeding calls to getUser will retrieve the previous UserBean. Important: this assumes your backing bean has session scope!

I don't understand you concern about ordering components on the page. Also, here are some other common concerns:
1. Accidentally inserting the same data because you resubmitted the page. Here,the most elegant solution is for each business bean to have a natural or business ID that translates to a uniqueness constraint in the database. For user records, perhaps they need to have a unique username.
2. Accidentally updating twice by resubmitting. It's usually a good idea to do optimistic locking generally speaking, and that will catch this.
3. Accidentally updating when you just meant to view data. This is another preference, but I don't like data to be perpetually in "update" mode. When I've not explicitly asking to update, I want the data displayed in "read only mode". I'm not a fan of locked or disabled input fields, so what I typically do is include a state property in my backing bean (READONLY, INSERTING, UPDATING,...) and in READONLY mode render h utputText instead of h:inputText. JSF makes that easy to do.

I hope this has answered your questions. I suggest you get something up a running to try things out -- create a simple table just for testing purposes with only a field fields, and a jsp page, backing bean and POJO to work with it. It will probably take less time to set that up than it took me to write this!

[ February 03, 2006: Message edited by: Jeff Albertson ]

[Jeff Albertson]

Let's see. You have a link that supplies an id:

<h:commandLink action="???">
<f:param name="id" value="..."/> 
<h:outputText value="edit user"/>
</h:commandLink>

Right away, there are two options:
1. the action attribute can just be a string that causes you to navigate to the editing page:

action="edit_user"

2. The action attribute can be mapped to an action in a backing bean:

action="#{pc_user.doEdit}"

In this second case, if this backing bean has session scope, it needs to
get that parameter:

FacesContext context = FacesContext.getCurrentInstance();
ExternalContext ec = context.getExternalContext();
String id = (String) ec.getRequestParameterMap().get("id");

But if the backing bean has request scope, it is going to be created to handle this request, so you can wire the access to this param in the managed bean's creation, as Sergey mentioned before:

<managed-bean>
 <managed-bean-name>pc_user</managed-bean-name>
<managed-bean-class>pagecode.UserBackingBean</managed-bean-class>
 <managed-bean-scope>request</managed-bean-scope>
 <managed-property>
 <property-name>id</property-name>
 <value>#{param.id}</value>
 </managed-property>
<managed-bean>

In either case, the backing bean associated with the editing page (which may or may not be the same bean as the backing bean of the search page) can expose a UserBean property, as done before:

public void UserBean getUser() {
if (user == null) {
    String id = getId();
    user = //get from database
}
return user;
}

Finally, getId, depending on your solution, will either be getting the value set in the manager bean's xml config, or getting it directly from the ExternalContext.

> Now there will be a getter and setter for each property of the Bean, but for editing
> I would rather pull the results in one place. Lets assume the page has a series of textboxes.
> Also, where would this method get called from the page in order for this to take place.
> This is where the ordering question came from. I would think this would have to be called
> before the other get methods are called.

That ordering is implicit in how you retrieve the bean's fields: to get to the field, you have to mention the bean first, so it's no problem:

<h:inputText value="#{pc_user.user.firstName}"/>

[Sergey Smirnov]

One more useful tip:
Article "How to Make Struts People Happy with JSF" ( http://blog.exadel.com/?p=19 )

It is about Struts-style action mapping.

--
Sergey : http://jsfTutorials.net

[Jeff Albertson]

Thinking about the basics here has got me musing about one aspect of managed beans that seems limiting. When you specify a managed bean, you name the class that will be instantiated:

<managed-bean>
 <managed-bean-name>myBean</managed-bean-name>
<managed-bean-class>com.beans.r.us.Bean</managed-bean-class>
 ...
<managed-bean>

So this is like writing:

com.beans.r.us.Bean myBean = new com.beans.r.us.Bean();

But when creating an object isn't it often useful to call a factory:

com.beans.r.us.Bean myBean = factory.createBean(some_args);

Is there a way to achieve that, with myBean a managed bean?