Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Proper way to update entities in a GUI application

 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the usual way to edit managed entities in a GUI (Swing, in my case) application?

My scenario: I have a list of entities (say, JList). It's populated by actual managed entities. User can select one entity and edit it, in which case the selected entity gets passed to an edit form. The edit form can modify the entity (say, add or remove something from collections in the entity) and always displays the current contents of the entity. My problem is how to handle the situation when user cancels the edit form - I need to "undo" the changes made to the entity in the form.

I can think of several approaches:

1) When the uses cancels the edits (or he saves, but the persist operation fails), I'll revert the entity, probably by reloading its state from the database. My problem is that I don't know whether this is at all possible. I also don't like the reloading bit, but I'd swallow it if it was possible as it sounds like the least amount of work.

2) When editing starts, I'll create a detached copy of the original entity, so that when the edit is cancelled I'd just throw it away and be done. When the edit is confirmed, I copy the detached entity's valued to the original (managed) copy and persist. I see two disadvantages: (a) I need to add code to copy properties between entities, and (b) if there's an error during persisting, the transaction will rollback and I'll end up with a detached, outdated entity which is still contained in the JList.

3) When the uses cancels the edits, I'll detach the edited entity, reload a fresh copy and put it in the original JList instead of the detached one. My problem is that since I've got no experience with JPA yet, I don't know whether this is safe (say that there are references to the edited entity in other entities when I detach it - will these references be properly handled?)

4) Don't modify the entity until the user presses Save. Sounds nice, but doesn't solve the 2)(b) problem.

Which approach is most commonly used? Or is there an even better way?

Thanks.
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's been a while since I used JPA to solve real world cases like these. So what I recommend, is just based on what I remember from those days.

When working on the UI side with these entities, I would detach them from the EntityManager which is managing it. In fact, JPA2 has a EntityManager.detach API which can be used here for explicit detaching. Once detached, the JPA semantics are no longer relevant since it now becomes more a case of how you manage the object for edits/cancels. Once the user has confirmed the edit, you can then link it back to the entitymanager using the EntityManager.merge API (remember that this API returns back the merged object which you are expected to use for further operations like persisting). The merged entity can then be saved. In case of cancels, all you do is discard the object and don't have to worry about the state being updated in the DB (since you never merged it back into the EntityManager). You don't need explicit copying of values from one object to another, the merge API handles that for you.
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot, Jaikiran! I'll give it a try.

It still doesn't solve the problem that the original entity which is passed to the editor is still used and displayed in a JList elsewhere. But I'll handle that somehow (this is just a very simple application).

Isn't there a mechanism to be notified by the JPA that a managed entity has changed? I have a different, much larger application that doesn't use JPA and there I've implemented a notification mechanism, so that the GUI parts can update themselves on their own when something they're depending on changes (and I've found the mechanism immensely useful). Or would similar functionality be actually supported by some caching framework instead? I don't need this for my current task, I'm asking just out of curiosity now.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use CDI events http://docs.oracle.com/javaee/6/tutorial/doc/gkhic.html (CDI can be used in a standalone application as well) but I'm not sure why you would need that if you let your GUI deal with detached POJOs only. Are you worried about other users updating data that was already loaded for the current user?
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, I'll have a look at that link.

At this time, my concern is that the same entity might be displayed several times in different forms. User edited the entity in one of the forms. I can update that form easily, but the others will become stale. If I could get notifications about changes made to an entity, I wouldn't have to keep track of all places an entity might be displayed.
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you say changes made to entities, do you mean the changes that have been finalized and saved into the DB from a particular form? If so, then you could perhaps use the JPA entity listeners http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/listeners.html
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks! This looks like the thing I'm looking for. I didn't get it working for now, but I'll revisit it when I understand the entire JPA philosophy better.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic