JSF / Java Design Question

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.

Does the `Addresses` class itself represent a bunch of addresses as well or just a single address? — BalusC, Jan 13 '11 at 18:07
Well it actually represents all the logic dealing with addresses, so inside there is a member variable List and then there is also methods that update, edit, delete addresses from the database and those methods in turn update the List — newtoJSF, Jan 13 '11 at 18:14
I was just targeting on `Addresses` as in `List`. A `List
` makes more sense. — BalusC, Jan 13 '11 at 18:31

BalusC · Accepted Answer · 2011-01-13T19:03:30.093

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.

what is a contact has addresses and phone numbers are you allowed to call two action methods such as this? Thank you for you answer I was not aware you could pass things like this in JSF, but I need it to load a bunch of different lists. — newtoJSF, Jan 13 '11 at 18:40
No, just load both in a single action method. Now your intent is more clear, the approach is a little different. I updated the answer. — BalusC, Jan 13 '11 at 19:04

JSF / Java Design Question

1 Answers1

Linked