[gwt-contrib] Editor framework and submitting object graphs

2011-05-24 Thread Tim Murison
Hi,

I've recently transitioned my web application from GWT 2.2 to 2.3 and I've 
started to encounter some problems. I have a few editors with multiple 
sub-editors that can be used to both create and edit resources. For example:

Person
[List Offices]
[List Phones]
[List Office Hours]

This is constructed as a PersonEditor with a @UiField CompositeEditor for the 
offices and the CompositeEditor uses CellTable HasDataEditors for the phones 
and office hours.

In GWT 2.2, this all worked perfectly, I can create a Person resource by 
submitting the object graph of sub-resources to the server and I can fetch a 
Person resource as well as all the sub-resources and the editor framework takes 
care of all the magic for me.

In GWT 2.3, fetching works perfectly, but submitting does not. From what I can 
tell, the properties of any type controlled by a CompositeEditor are not filled 
in. This triggers javax.validation errors from my server which I can see on the 
wire. By putting breakpoints in the server, I am certain that the complete 
object graph is not sent.

Since I'm unaware of any changes to the editor framework in GWT 2.3, other than 
renaming the request factory packages, I'm surprised that my editors are 
broken. Do you have any pointers?

Thanks,

-Tim

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors


[gwt-contrib] Issue 6153

2011-05-23 Thread Tim Murison
Hi GWT Devs,

I've recently come across Issue 6153 
(http://code.google.com/p/google-web-toolkit/issues/detail?id=6153) which 
affects the released version of GWT 2.3. Any chance of a patch or a release 
2.3.1 to fix this? Automatic error reporting integrated with the editor 
framework is probably my favourite feature of GWT... it is shame to see it 
broken.

Cheers,

-Tim

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors


[gwt-contrib] Domain type cannot be sent to client

2010-11-11 Thread Tim Murison
Hi,

I've been fiddling with the latest RequestFactory code in gwt trunk. I
keep coming across the following error message: The domain type
com.mtacit.rmddx.server.model.Email cannot be sent to the client.

This occurs with quite a few of my domain types, in fact the
domainToClientType map in RequestFactoryInterfaceValidator has only 4
entries when it should have about 25. If I understand the code
correctly, the map is populated when requesting client types from the
ReflectiveServiceLayer, usually via a request context method
invocation.

In my scenario, UserAccount has a List of Emails. The UserAccount
domain type is in the map since it's proxy was referenced in an
earlier request. However, because the Emails are in a collection on
UserAccount, when the UserAccount proxy is validated
(RequestFactoryInterfaceValidator::validateEntityProxy), the Emails
are skipped. Now when I try to return a UserAccount object,
including Emails, to the client, I get the above error.

Is this a known issue and is there a workaround I can try?

Cheers,

-Tim

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors


Re: [gwt-contrib] Domain type cannot be sent to client

2010-11-11 Thread Tim Murison
On Thu, Nov 11, 2010 at 10:48 PM, BobV b...@google.com wrote:
 Is this a known issue and is there a workaround I can try?

 Are the problematic types only reachable from the RequestFactory
 interface through a parameterized List or Set?

Yes, that's the case.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors


Re: [gwt-contrib] JsonRequestProcessor and multiple findEntity calls

2010-11-03 Thread Tim Murison
 The behavior you're seeing is expected in the current implementation.
 This will be reduced slightly by the server-side refactoring in
 progress. In the 2.1.1
 codebase, all incoming objects will trigger two finds.  The first is
 to load the domain object to process the request.  The second will be
 to determine if the object has been deleted.  A hook will be available
 to inject more efficient logic to determine if an object has become
 irretrievable.

Is there an ETA for GWT 2.1.1?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors


Re: [gwt-contrib] Re: Not using dvsDataMap on child entities

2010-10-20 Thread Tim Murison
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


Re: [gwt-contrib] Re: Not using dvsDataMap on child entities

2010-10-20 Thread Tim Murison
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 tim.muri...@gmail.com 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 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


Re: [gwt-contrib] Re: Not using dvsDataMap on child entities

2010-10-20 Thread Tim Murison
On Wed, Oct 20, 2010 at 12:02 PM, BobV b...@google.com wrote:
 On Wed, Oct 20, 2010 at 11:34 AM, Tim Murison tim.muri...@gmail.com wrote:
 Any updates on this issue?

 I am burning down the server code this week.

Will it be replaced with some shiny new server code?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors