More notes on this: Say I have the following relationship, a User has a list of OfficeHours. Using the editor framework, I can create OfficeHours proxies, add them to User and persist() and get the whole graph, including new OfficeHours, on the server.
If I add a new OfficeHours proxy and update an existing one and persist(), I get the whole graph (with the update) on the server. However, if all I do is update an OfficeHours proxy, then the JsonRequestProcessor sends me the copy it got from OfficeHours::findOfficeHours() instead of the updated version. On Wed, Oct 20, 2010 at 11:34 AM, Tim Murison <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien <[email protected]> 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
