Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread haiko

Hi Chris,

I would go for option 4. This is how I implement such cases. It has an  
explicit distinction between states 'previewMode' and 'commited Mode'.  
Looks like more coding, but actually is clear about distinction  
between preview and saved. And that would help the programmer that  
picks this code up a half year from now.


My 2 cents.

Best,

Haiko

Chris Snyder chris.sny...@biologos.org schreef:


I'm dealing with an issue that I'm sure has been solved by many people on
this list, but I'm struggling to ascertain the best way to solve it.

I'm working on implementing in-place-edit functionality for some of our
site content. The content is stored in a database and mapped via JPA. The
edit form has the JPA entity as the backing model object.

One of the features I'm implementing is the ability to preview what's been
entered in the form without the updates being committed to the database
(until the user explicitly clicks on the Save button). I can think of a
few ways to accomplish this:

1. Rollback the transaction when not saving - This would require me to
manage the transaction manually (right now, they're being managed
automatically by Guice's PersistFilter).

2. Detach the object from the persistence context, merge it to save - This
seems like the most elegant solution, but I can see how there could be
issues (not intractable) with lazy loading.

3. Prevent the form from updating the model until save - This would break
my preview panel, and seems to be contrary to how forms normally behave.

4. Copy the data into a non-managed DTO, copying it back to the JPA object
on save - Would require a lot of clone/copy code.

This seems like such a common problem to solve - I think my relative
unfamiliarity with JPA is the main stumbling block here. How have others
implemented it? Is there a best-practice pattern that my Googling didn't
discover?

Thanks in advance for the help. I hope that it isn't too off-topic since it
is mainly JPA-related.

Best,
Chris






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Patrick Davids
Hi Chris,
does the Guice's PersistFilter really automatically find and re-attach 
the backed object in the request while leaving the in-place-edit situation?

I thought... as long as nothing/nobody finds and re-attach the backed 
object, your changes are naturally temporary and only stored on page 
cache.

I would expect, it should already work out-of-the-box... But I did not 
work with Guice's PersistFilter, yet. May I miss something...

kind regards
Patrick

Am 05.03.2014 12:47, schrieb Chris Snyder:
 I'm dealing with an issue that I'm sure has been solved by many people on
 this list, but I'm struggling to ascertain the best way to solve it.

 I'm working on implementing in-place-edit functionality for some of our
 site content. The content is stored in a database and mapped via JPA. The
 edit form has the JPA entity as the backing model object.

 One of the features I'm implementing is the ability to preview what's been
 entered in the form without the updates being committed to the database
 (until the user explicitly clicks on the Save button). I can think of a
 few ways to accomplish this:

 1. Rollback the transaction when not saving - This would require me to
 manage the transaction manually (right now, they're being managed
 automatically by Guice's PersistFilter).

 2. Detach the object from the persistence context, merge it to save - This
 seems like the most elegant solution, but I can see how there could be
 issues (not intractable) with lazy loading.

 3. Prevent the form from updating the model until save - This would break
 my preview panel, and seems to be contrary to how forms normally behave.

 4. Copy the data into a non-managed DTO, copying it back to the JPA object
 on save - Would require a lot of clone/copy code.

 This seems like such a common problem to solve - I think my relative
 unfamiliarity with JPA is the main stumbling block here. How have others
 implemented it? Is there a best-practice pattern that my Googling didn't
 discover?

 Thanks in advance for the help. I hope that it isn't too off-topic since it
 is mainly JPA-related.

 Best,
 Chris


Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
Hi Patrick,

Thanks for the response.

does the Guice's PersistFilter really automatically find and re-attach
 the backed object in the request while leaving the in-place-edit situation?


Guice doesn't do anything with whether the objects are attached - I'm
simply never detaching them (unless I implement option #2), so any changes
made to the object are automatically persisted by the JPA engine. Guice's
role here is with transactions - the PersistFilter starts a transaction at
the beginning of the request, and commits it at the end.

Thanks,
Chris


On Wed, Mar 5, 2014 at 8:29 AM, Patrick Davids patrick.dav...@nubologic.com
 wrote:

 Hi Chris,

 I thought... as long as nothing/nobody finds and re-attach the backed
 object, your changes are naturally temporary and only stored on page
 cache.

 I would expect, it should already work out-of-the-box... But I did not
 work with Guice's PersistFilter, yet. May I miss something...

 kind regards
 Patrick

 Am 05.03.2014 12:47, schrieb Chris Snyder:
  I'm dealing with an issue that I'm sure has been solved by many people on
  this list, but I'm struggling to ascertain the best way to solve it.
 
  I'm working on implementing in-place-edit functionality for some of our
  site content. The content is stored in a database and mapped via JPA. The
  edit form has the JPA entity as the backing model object.
 
  One of the features I'm implementing is the ability to preview what's
 been
  entered in the form without the updates being committed to the database
  (until the user explicitly clicks on the Save button). I can think of a
  few ways to accomplish this:
 
  1. Rollback the transaction when not saving - This would require me to
  manage the transaction manually (right now, they're being managed
  automatically by Guice's PersistFilter).
 
  2. Detach the object from the persistence context, merge it to save -
 This
  seems like the most elegant solution, but I can see how there could be
  issues (not intractable) with lazy loading.
 
  3. Prevent the form from updating the model until save - This would break
  my preview panel, and seems to be contrary to how forms normally behave.
 
  4. Copy the data into a non-managed DTO, copying it back to the JPA
 object
  on save - Would require a lot of clone/copy code.
 
  This seems like such a common problem to solve - I think my relative
  unfamiliarity with JPA is the main stumbling block here. How have others
  implemented it? Is there a best-practice pattern that my Googling didn't
  discover?
 
  Thanks in advance for the help. I hope that it isn't too off-topic since
 it
  is mainly JPA-related.
 
  Best,
  Chris
 



Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
Hi Haiko,

Thanks for the response. You raise some good points - it certainly would be
cleaner and easier to understand. It also could be better for my layout,
given the way I've organized the code: The data layer is abstracted behind
a service API, so we could plug in a different storage engine (Cassandra
instead of JPA, for example) without needing to modify the other layers.
The editor code currently has no knowledge of JPA, so I'd have to expose
some of the business layer to implement either of my first two options.

Do you use any tools to make the copying easier, or do you code it by hand?

Thanks,
Chris

On Wed, Mar 5, 2014 at 8:07 AM, ha...@dds.nl wrote:

 Hi Chris,

 I would go for option 4. This is how I implement such cases. It has an
 explicit distinction between states 'previewMode' and 'commited Mode'.
 Looks like more coding, but actually is clear about distinction between
 preview and saved. And that would help the programmer that picks this code
 up a half year from now.

 My 2 cents.

 Best,

 Haiko

 Chris Snyder chris.sny...@biologos.org schreef:


  I'm dealing with an issue that I'm sure has been solved by many people on
 this list, but I'm struggling to ascertain the best way to solve it.

 I'm working on implementing in-place-edit functionality for some of our
 site content. The content is stored in a database and mapped via JPA. The
 edit form has the JPA entity as the backing model object.

 One of the features I'm implementing is the ability to preview what's been
 entered in the form without the updates being committed to the database
 (until the user explicitly clicks on the Save button). I can think of a
 few ways to accomplish this:

 1. Rollback the transaction when not saving - This would require me to
 manage the transaction manually (right now, they're being managed
 automatically by Guice's PersistFilter).

 2. Detach the object from the persistence context, merge it to save - This
 seems like the most elegant solution, but I can see how there could be
 issues (not intractable) with lazy loading.

 3. Prevent the form from updating the model until save - This would break
 my preview panel, and seems to be contrary to how forms normally behave.

 4. Copy the data into a non-managed DTO, copying it back to the JPA object
 on save - Would require a lot of clone/copy code.

 This seems like such a common problem to solve - I think my relative
 unfamiliarity with JPA is the main stumbling block here. How have others
 implemented it? Is there a best-practice pattern that my Googling didn't
 discover?

 Thanks in advance for the help. I hope that it isn't too off-topic since
 it
 is mainly JPA-related.

 Best,
 Chris






 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Igor Vaynberg
have a look here:

https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/

-igor

On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org wrote:
 I'm dealing with an issue that I'm sure has been solved by many people on
 this list, but I'm struggling to ascertain the best way to solve it.

 I'm working on implementing in-place-edit functionality for some of our
 site content. The content is stored in a database and mapped via JPA. The
 edit form has the JPA entity as the backing model object.

 One of the features I'm implementing is the ability to preview what's been
 entered in the form without the updates being committed to the database
 (until the user explicitly clicks on the Save button). I can think of a
 few ways to accomplish this:

 1. Rollback the transaction when not saving - This would require me to
 manage the transaction manually (right now, they're being managed
 automatically by Guice's PersistFilter).

 2. Detach the object from the persistence context, merge it to save - This
 seems like the most elegant solution, but I can see how there could be
 issues (not intractable) with lazy loading.

 3. Prevent the form from updating the model until save - This would break
 my preview panel, and seems to be contrary to how forms normally behave.

 4. Copy the data into a non-managed DTO, copying it back to the JPA object
 on save - Would require a lot of clone/copy code.

 This seems like such a common problem to solve - I think my relative
 unfamiliarity with JPA is the main stumbling block here. How have others
 implemented it? Is there a best-practice pattern that my Googling didn't
 discover?

 Thanks in advance for the help. I hope that it isn't too off-topic since it
 is mainly JPA-related.

 Best,
 Chris

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Chris Snyder
Thanks, Igor - that's very helpful. Not sure how I missed that article
while I was searching.

It would be a bit tricky to implement in my situation (as I described in
another response, the JPA implementation of the data storage is abstracted
behind a service API), but I could make it work - perhaps by adding detach
and merge methods to the API; that would perhaps expose a little too much
of the implementation, but I think that other (hypothetical)
implementations could also need to expose similar functionality.

Of course, I might be over-engineering this whole abstraction anyways. I
have no intention of implementing a non-JPA version - perhaps I should
embrace a hard dependency on JPA and simplify everything. JPA is itself an
abstraction layer, after all...

Thanks,
Chris


On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 have a look here:


 https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/

 -igor

 On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org
 wrote:
  I'm dealing with an issue that I'm sure has been solved by many people on
  this list, but I'm struggling to ascertain the best way to solve it.
 
  I'm working on implementing in-place-edit functionality for some of our
  site content. The content is stored in a database and mapped via JPA. The
  edit form has the JPA entity as the backing model object.
 
  One of the features I'm implementing is the ability to preview what's
 been
  entered in the form without the updates being committed to the database
  (until the user explicitly clicks on the Save button). I can think of a
  few ways to accomplish this:
 
  1. Rollback the transaction when not saving - This would require me to
  manage the transaction manually (right now, they're being managed
  automatically by Guice's PersistFilter).
 
  2. Detach the object from the persistence context, merge it to save -
 This
  seems like the most elegant solution, but I can see how there could be
  issues (not intractable) with lazy loading.
 
  3. Prevent the form from updating the model until save - This would break
  my preview panel, and seems to be contrary to how forms normally behave.
 
  4. Copy the data into a non-managed DTO, copying it back to the JPA
 object
  on save - Would require a lot of clone/copy code.
 
  This seems like such a common problem to solve - I think my relative
  unfamiliarity with JPA is the main stumbling block here. How have others
  implemented it? Is there a best-practice pattern that my Googling didn't
  discover?
 
  Thanks in advance for the help. I hope that it isn't too off-topic since
 it
  is mainly JPA-related.
 
  Best,
  Chris

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Chris Snyder
Web Developer, BioLogos
616.328.5218 x203
biologos.org


Re: Best practice for updating JPA object without persisting changes

2014-03-05 Thread Igor Vaynberg
you simple need to change where the entitymanager instance lives, and
control it via cdi conversation api. no need to expose any more of the
jpa stuff.

-igor

On Wed, Mar 5, 2014 at 9:06 AM, Chris Snyder chris.sny...@biologos.org wrote:
 Thanks, Igor - that's very helpful. Not sure how I missed that article
 while I was searching.

 It would be a bit tricky to implement in my situation (as I described in
 another response, the JPA implementation of the data storage is abstracted
 behind a service API), but I could make it work - perhaps by adding detach
 and merge methods to the API; that would perhaps expose a little too much
 of the implementation, but I think that other (hypothetical)
 implementations could also need to expose similar functionality.

 Of course, I might be over-engineering this whole abstraction anyways. I
 have no intention of implementing a non-JPA version - perhaps I should
 embrace a hard dependency on JPA and simplify everything. JPA is itself an
 abstraction layer, after all...

 Thanks,
 Chris


 On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 have a look here:


 https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/

 -igor

 On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org
 wrote:
  I'm dealing with an issue that I'm sure has been solved by many people on
  this list, but I'm struggling to ascertain the best way to solve it.
 
  I'm working on implementing in-place-edit functionality for some of our
  site content. The content is stored in a database and mapped via JPA. The
  edit form has the JPA entity as the backing model object.
 
  One of the features I'm implementing is the ability to preview what's
 been
  entered in the form without the updates being committed to the database
  (until the user explicitly clicks on the Save button). I can think of a
  few ways to accomplish this:
 
  1. Rollback the transaction when not saving - This would require me to
  manage the transaction manually (right now, they're being managed
  automatically by Guice's PersistFilter).
 
  2. Detach the object from the persistence context, merge it to save -
 This
  seems like the most elegant solution, but I can see how there could be
  issues (not intractable) with lazy loading.
 
  3. Prevent the form from updating the model until save - This would break
  my preview panel, and seems to be contrary to how forms normally behave.
 
  4. Copy the data into a non-managed DTO, copying it back to the JPA
 object
  on save - Would require a lot of clone/copy code.
 
  This seems like such a common problem to solve - I think my relative
  unfamiliarity with JPA is the main stumbling block here. How have others
  implemented it? Is there a best-practice pattern that my Googling didn't
  discover?
 
  Thanks in advance for the help. I hope that it isn't too off-topic since
 it
  is mainly JPA-related.
 
  Best,
  Chris

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 --
 Chris Snyder
 Web Developer, BioLogos
 616.328.5218 x203
 biologos.org

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org