Any updates on this issue? It seems very much like a bug as opposed to a purposeful design choice. All the editors work with object graphs and it makes sense to persist changes by sending object graph.
On Fri, Oct 15, 2010 at 11:05 AM, Patrick Julien <pjul...@gmail.com> wrote: > Not to mention that it's right there, it's in dvsDataMap, the only > problem is that it's sending the copy from the wrong map, that's it. > > > > On Fri, Oct 15, 2010 at 11:01 AM, Patrick Julien <pjul...@gmail.com> wrote: >> Do you have any idea on how I could get to the modified sub-entity? I >> have no way of reaching it right now. >> >> Even if this is outside your design for request factory it kind of >> conflicts with the design of editors. Editors want to get an object >> graph and that's what we would want to send back since this is what we >> got. >> >> Also, I don't understand if you're using manual or javax validations >> on how you're suppose to make an informed decision if something passes >> a validation or not in the service handler if pieces of the object >> graph come in one at a time. >> >> >> >> On Fri, Oct 15, 2010 at 10:48 AM, BobV <b...@google.com> wrote: >>> On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien <pjul...@gmail.com> wrote: >>>> As a follow up this, the internal persist() method isn't called on >>>> these modified entities either. >>> >>> Chained persistence is explicitly outside the RequestFactory design >>> because RequestFactory doesn't know anything about persistence. >>> Introducing a proper service layer into the server code should make >>> this easier to implement. >>> >>> -- >>> Bob Vawter >>> Google Web Toolkit Team >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
