Question

I am running JSF 2.0

I currently have one java controller that is called Contacts.java. Inside there I have a list of addresses stored as a member variable

List<Addresses> addresses;

When my application loads it displays a bunch of contacts and you are able to click on a contact to “open it” to view its data. When you click on the contact the contactId is passed to a method that populates the List based on the contactId. It in turn then displays the data.

I also have a bunch of functionality that will add an address to the list, remove an address, updated etc. which are all dependent on this contactId.

I was considering splitting up my Contacts.java into two controllers Contacts.java and Addresses.java because there is just so much logic having to do with addresses that I figured it should be in its own class.

The issue that I am struggling with is that if I move all of the logic dealing with Addresses into Addresses.java it will need to somehow have a reference to the contactId that was selected after compile time.

At compile time Addresses will compile looking for the current contactId when it is populating the List addresses in the constructor. It will have not been set at this point though because the contactId is set when the user selects a contact in the application.

Is this a bad design idea ? I am very new to Java and OOP and have not full grasped the concepts of how to break these apart. Any help would be appreciated.

Answer 1

In general, a single bean per view/form is preferable, but that also depends on whether you’re using asynchronous requests or not (ajax or not). As to passing the data around, there are several ways depending on the source, the target and/or the route.

At compile time Addresses will compile looking for the current contactId when it is populating the List addresses in the constructor. It will have not been set at this point though because the contactId is set when the user selects a contact in the application.

In your particular case, you seem to expect that the constructor/postconstruct is the only way to load the data. This is not true. You can also do it in the event (action) methods. E.g.

<h:dataTable value="#{contacts.list}" var="contact">
  <h:column>
    #{contact.name}
  </h:column>
  <h:column>
    <h:commandButton value="View info" action="#{contacts.view(contact)}">
  </h:column>
</h:dataTable>

And then in the Contacts backing bean (you only need to make List<Address> and List<Phone> a property of the Contact, with appropriate getters and setters)

public String view(Contact contact) {
    this.contact = contact;
    contact.setAddresses(addressDAO.list(contact));
    contact.setPhones(phoneDAO.list(contact));
    return "view";
}

And then in the page associated with view:

<h:dataTable value="#{contacts.contact.addresses}" var="address">
    ...
</h:dataTable>
<h:dataTable value="#{contacts.contact.phones}" var="phone">
    ...
</h:dataTable>

Or if you’re using JPA, you can also take benefit of lazy loading. But that’s a story and design apart.