What is best practice for hibernate server side business validation and updates done on form fields

18 views
Skip to first unread message

Cory Showers

unread,
Sep 7, 2014, 12:19:01 AM9/7/14
to gran...@googlegroups.com
Client Javafx 8
server Java 8, Spring 4, Hibernate 4
Granite 3.1.0.GA

I'm not sure whats the best way to go about performing business level validation and/or updates on the server side and have any temp changes done on server be reflected in client.  If I have a user form that performs some business rule when user changes a value, I need this to take place on the server rather than on client.  Some fields can be updated using DataBinding and some have to be calculated.   There will be server side tasks that needs to use the same service interface so it makes sense its in once place.  The problem is that this service may need to create new Hibernate entities or modify entities.  What is the best way to reflect these changes back in the UI but in the user temp local context, so if the user cancels the form the local context can be thrown away along with any modifications.   Now this is easy with Databinding as in the minute the user makes a change a local context is created with the entity and it is now dirty while protecting it from any updates done by other users.  Its not clear how to update the client side entity with these temporary changes when a remote service call is made to do similar updates.   This particular change on server is not published using Granite dataPublisher as in this is only specific to the user making the request.  At the moment I'm just returning the updated entity in the remote service call and relying on granite to automagically update client side entity upon deserialization. Will this update be in a local context to the user?  I don't believe it is or I could be wrong.   Is it common to mix and match the way Entities are getting updated while user is filling out form?  Updates done on client as well as on server in a temporary non persistent way?

wdrai

unread,
Sep 8, 2014, 4:16:30 AM9/8/14
to gran...@googlegroups.com
I don't see how you can change the entity on the server without persisting it globally.
What you want could work by creating a local conversation context and calling the server in this context :

var ctx = Spring.getInstance().getContext("userTempContext");
myService.validateAndSave(ctx, .., .., result, fault);

In this case you would have to bind the whole form to this local context.

Cory Showers

unread,
Sep 8, 2014, 10:00:10 AM9/8/14
to gran...@googlegroups.com
I can change entities on server without persisting because the servers job is just to perform modification based on some onEventListener in comboBox that needs to perform a business validation rule, then entity is sent back to client.   While the user is on the form the client might very well make multiple request to server to perform modifications before actually persisting the newly modified entity.   I guess this kind of flow was driven by the need to just pass a final entity to the server and just persist it rather than do all the validation and updates at the very end of the process.

Another approach I thought about doing was don't pass actual Hibernate entities to the server but pass DTOs instead for modification.  And then return these data objects back to the client, I can then update the user context entity on client from these DTOs.  This will give me the ability to perform business logic on server without the granite magic, but will add the cost of transferring data back and forth between DTOs.   
 
The suggestion you gave was to call the  server in a spring context.  But I'm not familiar with APIs you are using.  Is there a Spring.java class I don't know about Spring.getInstance().getContext().    Is this the SpringContextManager?
Also I make calls to server through the granite generated service code like the following.  I dont see where you can pass a context, or maybe I need to use a completely different API to make server calls.
public Future<List<BlotterView>> getDeals(List<Search> arg0, TideResponder<List<BlotterView>> tideResponder) {
return super.call("getDeals", arg0, tideResponder);
Reply all
Reply to author
Forward
0 new messages