3

I'm currently building a Java GUI application and I'm about to implement something that seemingly requires a great deal of thinking, at least for someone as relatively inexperienced as me.

The situation

is as follows: I have a class Customer at domain level, that holds a collection of jobs, which is a class too (Job). The application is for a fictious gardening company that wants to manage its customers and the jobs it does for them.

At GUI level, I have a jList for all the customers, with a custom listmodel that extends AbstractListModel. This part of my application works perfectly, I can add/edit/remove customers easily and as it should be.

The goal

now is to implement a jTable that should show the jobs for the customer selected in the jList.

No doubt I'll need a custom TableModel, the question is: where to get the data from? It should be noted that the collection of jobs in the Customer class is an ArrayList, and the class has no method that returns this ArrayList directly, it is only possible to get a copy, since I don't want it to be possible to mutate the collection in the class directly from a public context.

My idea

Is to let the tablemodel have a method to change the internal collection, with a customer parameter. When the index in the jList changes, that method should be invoked, so that the jTable represents the Jobs that have been done for the customer. When I have to edit/create/remove a job, the changes are always done on the tablemodel first, which will propagate the changes to the customer object (in case of a new job or job removal).

The question

Is that a good way to implement it? I feel it is not, because if I forget to do any changes to a Job via the tablemodel, and on the Customer or Job directly, there will be inconsistency and trouble. Are there better ways? If it involves changing other stuff, I do not mind.

(optional) Small subquestion

I lack some knowledge on the different Collections in java. I usually just go with ArrayList, like in this case in Customer for (mutable) jobs. Is there a better collection for this?

MarioDS
  • 12,895
  • 15
  • 65
  • 121

1 Answers1

2

Not saying this is the best way to implement this, but this is how I would do it

  • Make sure the customer Job list is observable. Either by using a 3th party lib which provides collections which fire events (I think Google has some available), or just make sure that every method on the Customer which updates the Job collection fires events
  • The table model representing the Jobs for a certain Customer can then listen for those events and update itself accordingly
  • It is unclear whether you allow to make changes to the table ui, but if you do, the table model should be responsible to propagate those changes again to the Customer

So nothing changes on your current edit/create/remove/add job code. That keeps working with your Customer and does not even know a TableModel exists. The TableModel works also directly against the Customer and does not even know there might be UI to edit/create/remove/add jobs. It just listens for any changes made to the job collection and updates itself accordingly.

It seems like a very bad idea to make the changes to the job list in all parts of your code through the table model. The Customer is your model, and the JTable is the view (MVC pattern anyone). The fact the JTable needs a different representation of your model (a TableModel) is a side-effect.

Robin
  • 36,233
  • 5
  • 47
  • 99
  • That sounds like a good implementation, but the application is so simple and what's more, it's for school... I was hoping rather that I would not need event-like stuff, or at least just be able to do it with the standard java librariers. I know that limits the options, but that's how it's going to have to be done... – MarioDS Apr 11 '12 at 16:59
  • @MarioDeSchaepmeester if your `TableModel` is backed by a standard Java Collection (which does not fire events) and which can be updated externally, you will end up with a corrupted `JTable` since your `TableModel` will had certain updates which were not communicated to the `JTable`. So you will need a mechanism to inform the `TableModel` about any changes made externally – Robin Apr 11 '12 at 17:01
  • good point. The problem is my school never explains the interesting stuff. In our first and only other exercice on tables, the model was a domain class, which is rather stupid of course... I don't have all that much time left and I spent way too much on it already. So suppose I'll just accept it is _possible_ to corrupt the jTable, but I just program my GUI so that it doesn't, is my idea in the question the best/good enough (if you don't think about extreme options that involve doing stuff that smells like hacks)? – MarioDS Apr 11 '12 at 17:06
  • 1
    No, since you will have to update all your code to go through the `TableModel` instead of directly to the customer. This mixes your UI logic code with your domain code. If you later decide to remove the table (or replace it by something else), your can start rewriting your own code. Note that making the `Customer` fire some events is not that much work (nor in time, nor in lines of code). – Robin Apr 11 '12 at 17:10
  • Yeah, luckily I've used events before... So you'd just have the tablemodel be an eventlistener to the customer class? I think it makes sense and I can imagine how it will look. Thanks. – MarioDS Apr 11 '12 at 17:14
  • @Robin wow, it's going to be MUCH easier than I thought! I won't need events - apparantly the tablemodel does not need it's own internal collection - as opposed to jList. The **only** important thing is to retrieve values by index (very simply through the customer class that had a method for that) and call the fireTableDataChanged() method when there are changes (ie after every time I add/remove a job, which was unavoidable all the same. Best to use for this is still events but it's overkill), and the java standard libraries just take care of the rest. Guess i should have waited to ask... – MarioDS Apr 11 '12 at 17:48