Re: [gwt-contrib] Typed Arrays and WebGL
Philip, are you saying WebGL is in IE10 proper? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Was the lack of server side templating in GWT one of the reasons why Google+ team did not choose GWT ?
Why don't you feature the Google products that use GWT in the gallery? http://gwtgallery.appspot.com/ I'm always coming up against the argument that Google doesn't use GWT, always. It's annoying and I shouldn't have to make that sale and I wouldn't need to if the gallery featured those products On Wed, Jul 20, 2011 at 10:07 AM, David Chandler wrote: > Thanks for pointing it out. I've already answered this in the best way > I know how, so I'm happy to let the community hash this one out. > > https://groups.google.com/d/msg/google-web-toolkit/-/eSqUVQ8gKEMJ > > /dmc > > On Mon, Jul 18, 2011 at 10:13 AM, karthik reddy > wrote: >> Note: I am cross-posting this on GWT-contributors group to solicit the >> responses of the GWT team. The original post on the GWT group is at : >> https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/CnjBcJsknS0 >> The following were two direct quotes from Joseph Smarr (tech lead of google >> plus -- plus.google.com): >> (FYI: The full Q & A with the Google+ Tech Lead can be found >> at: http://anyasq.com/79-im-a-technical-lead-on-the-google+-team) >> "we often render our Closure templates server-side so the page renders >> before any JavaScript is loaded, then the JavaScript finds the right DOM >> nodes and hooks up event handlers, etc. to make it responsive (as a result, >> if you're on a slow connection and you click on stuff really fast, you may >> notice a lag before it does anything, but luckily most people don't run into >> this in practice)." >> "The cool thing about Closure templates is they can be compiled into both >> Java and JavaScript. So we use Java server-side to turn the templates into >> HTML, but we can also do the same in JavaScript client-side for dynamic >> rendering. For instance, if you type in a profile page URL directly, we'll >> render it server-side, but if you go to the stream say and navigate to >> someone's profile page, we do it with AJAX and render it client-side using >> the same exact template. " >> >> Going from the tone of the above two quotes, it seems to me that the lack of >> server-side templating system in GWT (GWT has client-side templating in the >> form of UiBinder but not server-side templating) , could have been one of >> the reasons for not choosing GWT for the Google+ project. >> What do you guys think?? >> Was the lack of server side templating in GWT one of the reasons why >> Google+ team did not choose GWT ?? >> >> PS: If you guys haven't tried Google+ yet, I would recommend you try it. >> Setting aside how good of a social network/social collaboration tool it is, >> I suggest you guys try it just to get a feel of its UI architecture. Every >> once in a while, an application comes along and raises the bar(eg., Gmail in >> 2004) in the area of UI design/UI development and I think Google plus has >> done it this time around. >> Also, I really appreciate the fact that GWT is an exceptional work of >> engineering. My desire is to just provoke discussion in a direction that >> hopefully leads to making the product even more better and increases its >> technological "moat" (Warren Buffet >> lingo: http://37signals.com/svn/posts/333-warren-buffett-on-castles-and-moats) >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > > > > -- > David Chandler > Developer Programs Engineer, GWT+GAE > w: http://code.google.com/ > b: http://turbomanage.wordpress.com/ > b: http://googlewebtoolkit.blogspot.com/ > t: @googledevtools > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] rfc on 6068 fix
On May 16, 2011 11:06 AM, "BobV" wrote: > > On Sun, May 8, 2011 at 10:08 AM, Patrick Julien wrote: > > Here is what I am planning to do to fix issue 6068 > > > > http://code.google.com/p/google-web-toolkit/issues/detail?id=6068 > > > > 1. Add to BeanMethod.java (package > > com.google.web.bindery.autobean.vm.impl;) an TO_ARRAY value > > > > 2. Add to JBeanMethod.java > > (com.google.web.bindery.autobean.gwt.rebind.model;) an TO_ARRAY value > > > > 3. in AutoBeanFactoryGenerator#writeShim (package > > com.google.web.bindery.autobean.gwt.rebind;) handle the TO_ARRAY case > > by checking the: > > > > a. if the type is assignable to Collection > > b. Determine if toArray has one of two supported method signatures in > > Collection > > c. Generate code that assigns each element of the newly created array > > by wrapping it first > > This sounds reasonable to me. > > > 4. Add a unit test to check for unfrozen beans. > > > > a. Get a collection of AutoBeans > > b. assert they are frozen > > c. Initialize an ArrayList using this other collection > > d. Assert the objects stored the second ArrayList are unfrozen > > The objects stored in the second ArrayList would still be frozen. Then i'm confused. If the objects in the second array are still frozen, then the bug is still there no? The fact that the second ArrayList is still frozen is what makes ListEditorWrapper/HasDataEditor completely unusable for me. > It's the AbstractRequestContext and BaseProxyCategory that produces > the frozen/unfrozen behavior by cloning the AutoBeans as they're being > read though the external methods facades. > > I think the test that you want here is to ensure that Nth element of a > wrapped collection's toArray() is the same as the Nth element of the > collection. That is, list.get(0) and list.toArray()[0] are both > wrappers. > > > Open Questions: > > > > 1. Should I try to handle immutable collections, i.e., > > Collections.unmodifiable* or guava's Immutable*? > > The mutability of the collection shouldn't matter here, since > toArray() either returns a newly-allocated array or fills in the array > passed to toArray(T[]). > > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] rfc on 6068 fix
Here is what I am planning to do to fix issue 6068 http://code.google.com/p/google-web-toolkit/issues/detail?id=6068 1. Add to BeanMethod.java (package com.google.web.bindery.autobean.vm.impl;) an TO_ARRAY value 2. Add to JBeanMethod.java (com.google.web.bindery.autobean.gwt.rebind.model;) an TO_ARRAY value 3. in AutoBeanFactoryGenerator#writeShim (package com.google.web.bindery.autobean.gwt.rebind;) handle the TO_ARRAY case by checking the: a. if the type is assignable to Collection b. Determine if toArray has one of two supported method signatures in Collection c. Generate code that assigns each element of the newly created array by wrapping it first 4. Add a unit test to check for unfrozen beans. a. Get a collection of AutoBeans b. assert they are frozen c. Initialize an ArrayList using this other collection d. Assert the objects stored the second ArrayList are unfrozen Open Questions: 1. Should I try to handle immutable collections, i.e., Collections.unmodifiable* or guava's Immutable*? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Re : Re: [gwt-contrib] HasRequestContext and 2.3.0rc1
Thanks Thomas, I'm starting to think you know all 6000~ tickets in the
issue tracker from memory. However, I was only pointing it out here,
this is a nice feature to have since this was a 2.2 code base where I
was propagating the RequestContext myself
On Thu, Apr 28, 2011 at 2:44 PM, Thomas Broyer wrote:
> I believe you're experiencing this
> issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=6016
> You're probably running into it because you implement both IsEditor and
> Editor (through HasRequestContext), so the "link" between the parent editor
> and an instance of AchievementDefinitionTable now generates two
> EditorContext-s, or actually should do so, but both are being tentatively
> generated using the same class name, so the other actually reuses the first
> class, whic obviously doesn't use the apropriate types.
> As a workaround, IIRC, you can try replacing IsEditor with a subeditor with
> @Path("")
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HasRequestContext and 2.3.0rc1
The log is this:
Compiling module net.odgn.plasma.Plasma
Scanning for additional dependencies:
file:/C:/Users/pjulien/Documents/odgn/bin/plasma/src/net/odgn/plasma/client/presenter/admin/game/ui/EditGameView.java
Adding '17' new generated units
Validating newly compiled units
[ERROR] Errors in
'generated://3AE2F7E937C7B6ED6978FDAF26D34D18/net/odgn/plasma/client/presenter/admin/game/ui/EditGameView_RequestFactoryEditorDelegate.java'
[ERROR] Line 62: The constructor
EditGameView_possibleAchievements_Context(GameDefinitionHandle,
AchievementDefinitionTable, String) is undefined
See snapshot:
C:\Users\pjulien\AppData\Local\Temp\net.odgn.plasma.client.presenter.admin.game.ui.EditGameView_RequestFactoryEditorDelegate4638522755171937904.java
[ERROR] Errors in
'generated://3AE2F7E937C7B6ED6978FDAF26D34D18/net/odgn/plasma/client/presenter/admin/game/ui/EditGameView_RequestFactoryEditorDelegate.java'
[ERROR] Line 62: The constructor
EditGameView_possibleAchievements_Context(GameDefinitionHandle,
AchievementDefinitionTable, String) is undefined
[ERROR] Cannot proceed due to previous errors
I am trying with this:
public final class AchievementDefinitionTable extends Composite
implements IsEditor>,
HasRequestContext {
or this:
public final class AchievementDefinitionTable extends Composite
implements IsEditor>,
HasRequestContext> {
Removing HasRequestContext fixes the error
On Thu, Apr 28, 2011 at 12:44 PM, BobV wrote:
> On Wed, Apr 27, 2011 at 10:56 PM, Patrick Julien wrote:
>> How does this actually work?
>
> class MyEditor implements HasRequestConext {
> // HasRequestContext extends the Editor interface
> }
>
>> If I implement HasRequestContext anywhere, the containing request
>> factory editor driver that is generated no longer compiles, saying
>> that there is a missing constructor
>
> Can you attach the log output? What is the type declaration for the
> offending Editor class?
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] HasRequestContext and 2.3.0rc1
How does this actually work? If I implement HasRequestContext anywhere, the containing request factory editor driver that is generated no longer compiles, saying that there is a missing constructor -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT SDK 2.3.0.RC1
Since you asked so nicely, I can confirm that changing imports and the gwt.xml file was all I needed to do to fix 2 large gwt applications. On Tue, Apr 26, 2011 at 8:48 PM, Chris Ramsdale wrote: > Hey GWTC folks, > We have a GWT SDK 2.3.0.RC1 build that we would love feedback on. A big > change since M1 is the move of AutoBean and RequestFactory to a new package, > com.google.web.bindery. The old locations of AutoBean and RequestFactory > should still work, but are deprecated. Fixing the deprecation warnings for > the most part should be as simple as changing some import lines. If early > adopters could verify that assumption, we would be grateful. > The RC1 download can be found here: > http://code.google.com/p/google-web-toolkit/downloads/detail?name=gwt-2.3.0.rc1.zip > > -- Chris/Ray, on behalf of the GWT team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
My reaction is that EventBus/SimpleEventBus and friends should be part of this On Fri, Mar 25, 2011 at 5:19 PM, Ray Ryan wrote: > RequestFactory is proving itself useful in non-GWT contexts, so we would > like to give it more independence. Our plan with the GWT 2.3 release is to > copy com.google.gwt.requestfactory to com.google.requestfactory, and > deprecate everything in the old location. We will also provide a jar that > includes the pure JRE version of request factory with no other GWT > dependencies. (This change will probably not make the first 2.3 milestone > release.) > > With 2.4, we'll delete the code in the old location. This is faster than > usual promise of keeping deprecated code in place for two releases, but we > really don't want to leave so much redundant code around any longer than we > have to. > > The API will not change; client code should be able to migrate by simply by > changing import statements. > > Reactions? > > rjrjr > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] ListEditorWrapper frozen autobeans
I don't think so, this issue started showing up when workingCopy was added to ListEditorWrapper. If I backtrack to a version before it, I'm fine. The other thing is I don't seem to have the problem reported in 6081. Mine has to do with the method toArray() being called, so there isn't anything left to unfreeze the bean when List#get is called. On Tue, Mar 1, 2011 at 5:29 AM, Thomas Broyer wrote: > Could this rather be a symptom > of http://code.google.com/p/google-web-toolkit/issues/detail?id=6081 ? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] ListEditorWrapper frozen autobeans
sorry, wrong link
http://gwt-code-reviews.appspot.com/1361802/
On Mon, Feb 28, 2011 at 10:55 PM, Patrick Julien wrote:
> yes, with patch
>
> http://gwt-code-reviews.appspot.com/1159801/show
>
>
> On Mon, Feb 28, 2011 at 8:43 PM, Ray Ryan wrote:
>> Patrick, did you file an issue about this?
>>
>> On Tue, Feb 22, 2011 at 7:15 AM, Patrick Julien wrote:
>>>
>>> http://gwt-code-reviews.appspot.com/1159801/show
>>>
>>> Introduces an autobean is frozen issue. The problem is that the
>>> "workingCopy" variable that is introduced doesn't cause autobeans to
>>> be unfrozen. The scenario that I have is pretty simple:
>>>
>>> public class XEditor extends composite implements Editor {
>>> private SomeChildTable pathToChildren;
>>> }
>>>
>>> SomeChildTable has a CellTable which uses the HasDataEditor wrapper.
>>>
>>> If I remove workingCopy, the various FieldUpdater inside the table are
>>> fine. If I don't, I get an "autobeans is frozen" exception. I
>>> believe this is because workingCopy is a regular ArrayList instead
>>> of the generated RequestFactory list wrapper type
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] ListEditorWrapper frozen autobeans
yes, with patch
http://gwt-code-reviews.appspot.com/1159801/show
On Mon, Feb 28, 2011 at 8:43 PM, Ray Ryan wrote:
> Patrick, did you file an issue about this?
>
> On Tue, Feb 22, 2011 at 7:15 AM, Patrick Julien wrote:
>>
>> http://gwt-code-reviews.appspot.com/1159801/show
>>
>> Introduces an autobean is frozen issue. The problem is that the
>> "workingCopy" variable that is introduced doesn't cause autobeans to
>> be unfrozen. The scenario that I have is pretty simple:
>>
>> public class XEditor extends composite implements Editor {
>> private SomeChildTable pathToChildren;
>> }
>>
>> SomeChildTable has a CellTable which uses the HasDataEditor wrapper.
>>
>> If I remove workingCopy, the various FieldUpdater inside the table are
>> fine. If I don't, I get an "autobeans is frozen" exception. I
>> believe this is because workingCopy is a regular ArrayList instead
>> of the generated RequestFactory list wrapper type
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] ListEditorWrapper frozen autobeans
http://gwt-code-reviews.appspot.com/1159801/show
Introduces an autobean is frozen issue. The problem is that the
"workingCopy" variable that is introduced doesn't cause autobeans to
be unfrozen. The scenario that I have is pretty simple:
public class XEditor extends composite implements Editor {
private SomeChildTable pathToChildren;
}
SomeChildTable has a CellTable which uses the HasDataEditor wrapper.
If I remove workingCopy, the various FieldUpdater inside the table are
fine. If I don't, I get an "autobeans is frozen" exception. I
believe this is because workingCopy is a regular ArrayList instead
of the generated RequestFactory list wrapper type
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RequestFactory access from Android
Ah, never mind, I think the idea is to use this new JSON-RPC support.
This will also solve the issue of accessing from wp7
On Tue, Feb 15, 2011 at 4:40 PM, Patrick Julien wrote:
> Thanks Bob, do you mind if I file an issue to formally request this?
>
> At this stage, I have it compiling but unable to parse requests on the server
>
> On Tue, Feb 15, 2011 at 1:09 PM, BobV wrote:
>> RequestFactoryMagic works on Android, but you'll need to do some build
>> hacking to get RF it to compile against the Android SDK.
>>
>> Here's what I did as an experiment:
>>
>> 1) Extract autobean/{shared, server}/** and requestfactory{shared,
>> server/testing}/** from gwt-user.jar.
>> 1a) There are a few other build dependencies to tease out.
>> 2) Write a RequestTransport that uses java.net.HttpUrlConnection or
>> the Apache HttpClient libs.
>> 3) IIRC, there's one or two minor API incompatibilities in the
>> org.json APIs built into the ADK, but they're simple to fix.
>>
>> Being able to put together a self-contained requestfactory-client.jar
>> would go a long way to improving code re-use for GWT devs who want
>> Android clients (and hopefully the other way around).
>>
>> --
>> Bob Vawter
>> Google Web Toolkit Team
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RequestFactory access from Android
Thanks Bob, do you mind if I file an issue to formally request this?
At this stage, I have it compiling but unable to parse requests on the server
On Tue, Feb 15, 2011 at 1:09 PM, BobV wrote:
> RequestFactoryMagic works on Android, but you'll need to do some build
> hacking to get RF it to compile against the Android SDK.
>
> Here's what I did as an experiment:
>
> 1) Extract autobean/{shared, server}/** and requestfactory{shared,
> server/testing}/** from gwt-user.jar.
> 1a) There are a few other build dependencies to tease out.
> 2) Write a RequestTransport that uses java.net.HttpUrlConnection or
> the Apache HttpClient libs.
> 3) IIRC, there's one or two minor API incompatibilities in the
> org.json APIs built into the ADK, but they're simple to fix.
>
> Being able to put together a self-contained requestfactory-client.jar
> would go a long way to improving code re-use for GWT devs who want
> Android clients (and hopefully the other way around).
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RequestFactory access from Android
Thanks. The worst thing is, is that I remember seeing this thing a while back now that you point it out again. That will help for android and other java based platforms. On Mon, Feb 14, 2011 at 5:35 PM, Thomas Broyer wrote: > """The RequestFactoryMagic type can be used to > instantiate RequestFactory instances in non-GWT runtimes. […] If you > implement your ownRequestTransport (perhaps based on > a java.net.HttpUrlConnection or Apache HttpClientlibrary), you can write > console apps, bulk-query apps, or health probers using your production > RequestFactory endpoints. This is a huge improvement over GWT`s old RPC > system, which only supports GWT-based clients.""" > > — > Source: http://stackoverflow.com/questions/4853188/unit-testing-of-gwt-requestfactory-services-without-gwttestcase/4926160#4926160 > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] RequestFactory access from Android
Anywhere I should start looking? This is JSON and everything but I want to access GWT services from Android and wp7. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Stack overflow problem in HashMap.hashCode() and possible fix
This behavior happens outside of GWT too in regular Java. This has
nothing to do with GWT. HashMap does not support null values or keys
On Sun, Jan 2, 2011 at 1:37 PM, sinelaw wrote:
> Problem can be reproduced with four lines of code:
>
> HashMap testMap = new HashMap();
> testMap.put("me", testMap);
> HashMap testMap2 = new HashMap Object>();
> testMap2.put(testMap, null); // < causes a stack overflow.
>
>
> The problem is in the following line of HashMap.hashCode():
>> result += keyHashCode(unmaskNullKey(key)) ^ valueHashCode(values[i]);
> since value[i] could equal this (the current instance), valueHashCode
> will recurse into hashCode causing an infinite recursion and stack
> overflow. It can be fixed by not calling valueHashCode on values that
> are this instance.
>
> Is this a bug or a "feature"?
>
>
> Thanks!
>
> EntireOne, Inc.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] child entities modifications still not accessible in 2.1.1
Originally from http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/1b67cfebede416b7/e958579badd4613a?lnk=gst&q=pjulien+dvsDataMap#e958579badd4613a and other posts. I've now reported http://code.google.com/p/google-web-toolkit/issues/detail?id=5776 and included a sample. The sample is concise and direct and shows off an assertion failure. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Thu, Dec 9, 2010 at 1:04 PM, Ray Ryan wrote: > Nnnnevermind. I think it's too late for me to make this > not-terribly-popular change. It's already more widely adopted than I > realized internally, so I have to assume that's even more true externally. I > can't imagine such a break being well received. I think it's for the best. > (Yes, we're making more significant changes to RequestFactory in 2.1.1, but > I suspect that has a lower adoption rate so far, and client side the impact > is actually fairly minimal, except for the dropped UserInfo stuff.) That and RequestFactory on the server is still pretty hellish effort wise. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
On Fri, Dec 3, 2010 at 3:35 PM, Ray Ryan wrote: > One more question for Patrick: would you be better able to use > AbstractActivity if the IsActivity interface were available? I don't want to speak for anybody else but not to me no. What AbstractActivity provides is so little that it's either sufficient or not. In my case, it's not. Introducing IsActivity doesn't make it any more useful to me. For list and edit, you can edit, so we need to take charge of all the Activity entry point in order to provide the user with a message about discarding changes. For details, it's fine, but it hasn't really saved us much now has it? I'm just surprised that you would want to make it an abstract class. If we were to re-live the gwt 2.1.0 development cycle, I would have to say that the activity package of classes was one of the most volatile out there. Why? Because making an activity that is both useful and generic for everyone out there is extremely hard and complex. AbstractActivity is certainly generic enough for everyone but how useful is it in its current implementation? If you want to improve on that, great, but how much experimentation would be involved in such a process? I'm just saying that anything added to an abstract Activity that works for all GWT users/applications would have to be out of this world crazy good or be benign like it currently is. That being said, I don't know what new additions you're planning. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
On Fri, Dec 3, 2010 at 3:18 PM, Ray Ryan wrote: > Patrick, you're the case in point. Because you don't use the abstract class, > if we change the API later we will break your app. I guess I don't understand how you're making it better then. I'm currently working on Android and I have two problems that I hope won't be introduced in GWT: 1. The activity class is huge. Anything that doesn't seem to fit somewhere else either goes in Context or Activity (with Activity inheriting from Context) 2. Activity isn't Guice friendly because the framework creates activities for you, we don't get absolute control of the ctors. It's driving me insane. It's nice we don't have to worry about creating activities and other system level objects but kind of sucks that we can't get any kind of support beyond that. Your argument about keeping the class simple helps reassure #1 won't come true... for now at least, I'm more worried about the implications of someone else becoming the steward of such a class. I can only hope #2 will remain like it is now in GWT and not like Android. > Were you unable to use the abstract class? If the Activity interface were > documented to encourage you to do so, would you have? When we break your > app, will you be okay with that? The abstract class didn't provide anything useful so multiple abstract base classes were made. In all, I have list, detail and edit abstract base activities and each define a view interface. Each of those scenarios provided a better, more suitably precise implementation than what's already in AbstractActivity. So even if you add breaking changes to Activity here, and I'm assuming by changes, you mean new methods with a default implementation, otherwise an abstract class wouldn't do much better, I have at most 3 classes to fix. All other activities are rooted in one of those 3 and are pretty light. But again, I wanted to voice my concern, not really trying to change the tide. I don't really mind Activity becoming a class under the conditions you mentioned. At first, I was just a little bit worried of getting something that, sooner or later, would match the stature of android's activity class. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
This is more in line with what we're doing. With what we experienced with the ramp up to 2.1.0, we only use the Activity interface, we don't use the default implementation and instead make our own for common classes of use cases. On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin wrote: > On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien wrote: >> >> I don't know since I don't know what your plans are, will just have to >> trust you. >> >> That being said, the Activity interface is currently really nice and >> it doesn't tie us down to a single class for inheritance. > > I have been very happy with the recent cases where I have used an interface > for the API but provided a default implementation, with the admonishment > that implementing the interface without extending the default implementation > is likely to be broken in the future. That way the people that care more > about being able to substitute alternate implementations or to use it > without having to extend the implementation can implement the interface, and > those that care more about not being broken by future updates can extend the > default implementation. > -- > John A. Tamplin > Software Engineer (GWT), Google > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. On Fri, Dec 3, 2010 at 2:20 PM, Ray Ryan wrote: > Any part of my point is that making sure it remains a trivial class with > only no-ops means you don't need to mock it. Is that a reasonable > assumption? > > On Fri, Dec 3, 2010 at 11:11 AM, Patrick Julien wrote: >> >> making it a class instead of an interface means we can't mock it anymore. >> >> On Thu, Dec 2, 2010 at 10:55 PM, Ray Ryan wrote: >> > We're making a few breaking changes in 2.1.1 to the new features >> > introduced >> > in 2.1. (We're not supposed to do that kind of thing, but are hoping to >> > get >> > away with it in this quick follow up release before there is much >> > adoption.) >> > I'd like to add a change to Activity to that list, in order to allow it >> > to >> > evolve in later releases when breakage of any kind won't be an option: >> > I'd >> > like to make Activity an abstract class instead of an interface, >> > basically >> > rename AbstractActivity. >> > Any objections? >> > rjrjr >> > >> > -- >> > 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
making it a class instead of an interface means we can't mock it anymore. On Thu, Dec 2, 2010 at 10:55 PM, Ray Ryan wrote: > We're making a few breaking changes in 2.1.1 to the new features introduced > in 2.1. (We're not supposed to do that kind of thing, but are hoping to get > away with it in this quick follow up release before there is much > adoption.) > I'd like to add a change to Activity to that list, in order to allow it to > evolve in later releases when breakage of any kind won't be an option: I'd > like to make Activity an abstract class instead of an interface, basically > rename AbstractActivity. > Any objections? > rjrjr > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Comment on Editors in google-web-toolkit
On Tue, Nov 23, 2010 at 11:18 AM, wrote:
> Comment by vinays.work:
>
> I am seriously disappointed with the Editor framework. What we need is a
> Bean Binding framework much like those that have existed in Swing. You just
> associate the bean property with the widget and the interchange of UI value
> with the bean needs to be automatic. JSF has a pretty effective Bean Binding
> framework as well. As a developer, your work needs to get minimized. Here,
> it is a silly mapping scheme that results in little benefit. I was expecting
> more from Google.
the values you have in your beans and the UI are bound. It's just by
default the paths to the properties are matched with what's in the UI
by default. When you call driver.edit(someObjectGraph);, or
display(), those values are filled in the UI. If you save from the
driver, all the values from the UI will make it back to your beans.
>
> The framework must also have bindings with tables, where in, you specify the
> List as associated with a Table and the information exchange is automatic
> - much the same way as:
This is already possible. See ListEditor and HasDataEditor.
HasDataEditor is an adapter for any HasData implementer. CellTable
being an implementation of HasData, you already have that.
interface User extends EntityProxy {
// ...
List addresses;
}
interface Address extends EntityProxy {
//...
}
class UserEditor extends Composite {
// ...
HasDataEditor addresses = HasDataEditor.of(cellTable); //
named the same otherwise use @Path, assuming cellTable here is from
uibinder
}
When you bind an instance of a UserEditor to a user, addresses in
UserEditor will have the data from the user address list. If you
modify this list via its CellTable, when you save, the entity proxy
will have the modifications too.
>
> http://publicobject.com/glazedlists/
>
>
> Vaadin Toolkit - build on the top of GWT - has data binding containers,
> which can be used as datasources in ... that the way of programming is like
> programming any Swing application
>
I think the editor framework is still missing a bit of
documentation/samples, mainly dealing with how you pull in object
graphs using information provided by the editor driver, but yes, what
you're talking about is all possible.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Overhaul the RequestFactory server code. (issue1080801)
I know it is, but the idea to have direct support is that constraint violations must be translated properly in order to make it back to the UI, I'm talking mainly about the editor framework here. Currently, a first pass is done to validate, any constraints are translated and then the service method is invoked. When invoked, there is no catch for that exception, so we would get the raw exception back on the client instead of a payload that the GWT machinery expects in order to bind this properly to the UI On Fri, Nov 5, 2010 at 4:08 PM, Nick Chalko wrote: > > >> >> If I would have to choose, I would definitely go for "invocation to >> return both validation errors and a result object". > > ContraintViolationExcpetion, is serializable, but it does not return the the > "root" object. see > http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/org/hibernate/validator/engine/ConstraintViolationImpl_CustomFieldSerializer.java > -- > Generate you java flags for easier testing. > go/java_flags > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Overhaul the RequestFactory server code. (issue1080801)
On Fri, Nov 5, 2010 at 11:35 AM, BobV wrote: > Just to be explicit, this is just the first in a series of patches to > graduate RequestFactory from toy status into something that's usable > with real systems. understood. > > http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 > > On Fri, Nov 5, 2010 at 11:21 AM, Patrick Julien wrote: >> I think this is still missing one core feature that makes it unusable. >> The problem is still validators. ConstraintViolation cannot be >> returned or thrown from our methods which means only the default group >> validation can be used. > > Would it be sufficient for your use case for the service layer to > delegate the validation work to a helper? Does it achieve the desired effect? Yes, I think so, but I also think that validation is so core to the server piece that we're just creating extra classes for no real reason. If we're using javax.validation groups, those helper classes will be mostly empty unless they have to understand the context they are in. I also worry we would need to duplicate access and security checks that we implement in the service methods. Basically, I think you need the "full" context of the service handler in order to make an intelligent choice about which validation group you should be using, hence, I still think what makes the most sense is to provide support at the service method level. > > - Read payload > - Load all objects and apply property changes > - Validate (possibly delegating to helper) > - Invoke service methods > - Return values > > Do you need a post-invocation validation pass or the ability for an > invocation to return both validation errors and a result object? > If I would have to choose, I would definitely go for "invocation to return both validation errors and a result object". Otherwise, all these independent handlers, (pre-validation, service, post-validation) are going to end up having to check what's passed in before they can do any real work. If these passes are separate, we just end up doing the same checks over and over again in different spots of the same service call because each spot now becomes a different state in a state machine that can, especially with post-validation, have many different entry points. If that's the case, it becomes tedious to figure out which validation group needs to be applied without reproducing the work the service handler method did. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Overhaul the RequestFactory server code. (issue1080801)
I think this is still missing one core feature that makes it unusable. The problem is still validators. ConstraintViolation cannot be returned or thrown from our methods which means only the default group validation can be used. e.g., let's say we have a UserAccount. Depending if the user has a validated email, I might require different validation groups. The way this is done in javax.validation is to use validation groups, instead of Set> errors = service.validate(domainObject); we get Set> errors = service.validate(domainObject, ValidationGroup.class); Otherwise we're stuck with only the default group which makes javax validation in GWT very much a toy. The main problem however why we can't call a validation group ourselves is because we need to translate back the ConstraintViolation violation into something the client side will interpret correctly, i.e., as a constraint violation versus a generic exception. When calling a user method from the service layer, this should be guarding for constraint violations and re-translating any errors that it gets the way it does now for the default group On Fri, Nov 5, 2010 at 10:14 AM, wrote: > Reviewers: rjrjr, > > Description: > Overhaul the RequestFactory server code. > Make RequestFactory usable from non-GWT code. > http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 > > Move AutoBeans to a top-level package and add AutoBeanCodex. > Add explicit support for Collections and Maps to AutoBeanVisitor. > Add support to AutoBean and AutoBeanCodex for Map properties. > Add @PropertyName annotation to decrease the size of the RF payload. > http://code.google.com/p/google-web-toolkit/wiki/AutoBean > > Patch by: bobv > Review by: rjrjr, rchandia > > > Please review this at http://gwt-code-reviews.appspot.com/1080801/show > > Affected files: > A > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/console/Console.java > A > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/console/HttpClientTransport.java > M tools/api-checker/config/gwt20_21userApi.conf > A user/src/com/google/gwt/autobean/AutoBean.gwt.xml > A user/src/com/google/gwt/autobean/client/impl/AbstractAutoBeanFactory.java > A user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java > A user/src/com/google/gwt/autobean/rebind/AutoBeanFactoryGenerator.java > A user/src/com/google/gwt/autobean/rebind/model/AutoBeanFactoryMethod.java > A user/src/com/google/gwt/autobean/rebind/model/AutoBeanFactoryModel.java > A user/src/com/google/gwt/autobean/rebind/model/AutoBeanMethod.java > A user/src/com/google/gwt/autobean/rebind/model/AutoBeanType.java > A user/src/com/google/gwt/autobean/server/AutoBeanFactoryMagic.java > A user/src/com/google/gwt/autobean/server/BeanMethod.java > A user/src/com/google/gwt/autobean/server/BeanPropertyContext.java > A user/src/com/google/gwt/autobean/server/Configuration.java > A user/src/com/google/gwt/autobean/server/FactoryHandler.java > A user/src/com/google/gwt/autobean/server/GetterPropertyContext.java > A user/src/com/google/gwt/autobean/server/MethodPropertyContext.java > A user/src/com/google/gwt/autobean/server/ProxyAutoBean.java > A user/src/com/google/gwt/autobean/server/ShimHandler.java > A user/src/com/google/gwt/autobean/server/SimpleBeanHandler.java > A user/src/com/google/gwt/autobean/server/impl/JsonSplittable.java > A user/src/com/google/gwt/autobean/server/impl/TypeUtils.java > A user/src/com/google/gwt/autobean/shared/AutoBean.java > A user/src/com/google/gwt/autobean/shared/AutoBeanCodex.java > A user/src/com/google/gwt/autobean/shared/AutoBeanFactory.java > A user/src/com/google/gwt/autobean/shared/AutoBeanUtils.java > A user/src/com/google/gwt/autobean/shared/AutoBeanVisitor.java > A user/src/com/google/gwt/autobean/shared/Splittable.java > A user/src/com/google/gwt/autobean/shared/ValueCodex.java > A user/src/com/google/gwt/autobean/shared/impl/AbstractAutoBean.java > A user/src/com/google/gwt/autobean/shared/impl/LazySplittable.java > A user/src/com/google/gwt/autobean/shared/impl/StringQuoter.java > M user/src/com/google/gwt/core/client/impl/WeakMapping.java > M user/src/com/google/gwt/editor/Editor.gwt.xml > D user/src/com/google/gwt/editor/client/AutoBean.java > D user/src/com/google/gwt/editor/client/AutoBeanFactory.java > D user/src/com/google/gwt/editor/client/AutoBeanUtils.java > D user/src/com/google/gwt/editor/client/AutoBeanVisitor.java > D user/src/com/google/gwt/editor/client/impl/AbstractAutoBean.java > D user/src/com/google/gwt/editor/client/impl/AbstractAutoBeanFactory.java > D user/src/com/google/gwt/editor/rebind/AutoBeanFactoryGenerator.java > D user/src/com/google/gwt/editor/rebind/model/AutoBeanFactoryMethod.java > D user/src/com/google/gwt/editor/rebind/model/AutoBeanFactoryModel.java > D user/src/com/google/gwt/editor/rebind/model/AutoBeanMethod.java > D user/src/com/google/gwt/editor/rebind/model/AutoBeanType.java > M user/src/com/google/gw
Re: [gwt-contrib] 2.1 is here -- thanks
Thank you but all I really did was complain :-) Seriously, I'm in love with this editor framework, it is fantastic and it will only get better as it matures to handle corner cases. I can only hope it gets the samples, documentation and demos it so rightly deserves in the short term so that developers adopt it. MVP has been highly publicized already thanks to Google I/O and will be immediately adopted. The editor framework is even more important due to the amount of code it eliminates especially when used in conjunction with javax validation. On Sat, Oct 30, 2010 at 12:10 AM, Ray Ryan wrote: > If you were paying careful attention, you just may have noticed that we > shipped GWT 2.1 yesterday. > > http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release-of-gwt-21.html > > I'd like to thank the GWT Contrib community for all of your interest in and > support with this release. It simply could not have happened without your > participation in design discussions, your patches, and your scrutiny of > patches. > > I'd particularly like to thank Thomas Broyer and Patrick Julien, who were > very vocal pioneering adopters of all the new stuff. You found bugs, found > design flaws, and had tremendous patience as we pulled the api rug out from > under you again and again. > > Of course it's dangerous to single people out for praise, for fear making > the many other contributors feel neglected — I hope I'm not doing that. > Many, many thanks again to everyone. > > rjrjr > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HandlerManager is going way of the dodo!
In the case of HandlerManager, you just need to replace it with
EventBus/SimpleEventBus. The interface is nice if you're working with
gin and it's also nice for unit testing. If you don't want to be
bothered too much, just substitute all instances of HandlerManager
with SimpleEventBus and you're done.
On Sun, Oct 17, 2010 at 1:47 PM, dmen wrote:
> I love how you deprecate core stuff, just like that. It shows how much
> thought you put before introducing APIs. By now, it seems like half of
> GWT API must be at deprecated state. No problem, simply slap
> @Deprecated, @SuppressWarnings("deprecation") all over the place and
> you 're done.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] JsonRequestProcessor can't execute validation groups
Namely this: violations = validator.validate(entityInstance); we can't do violations = validator.validate(entityInstance, SomeGroup.class); I'm bringing it up, I don't have a solution for this right now but I feel we should have at least have a way to disable the validator inside the processor so we can do our own -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
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 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 wrote: >> On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien 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
Re: [gwt-contrib] Re: Not using dvsDataMap on child entities
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 wrote: > On Thu, Oct 14, 2010 at 8:17 PM, Patrick Julien 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
[gwt-contrib] Re: Not using dvsDataMap on child entities
As a follow up this, the internal persist() method isn't called on
these modified entities either.
On Thu, Oct 14, 2010 at 2:40 PM, Patrick Julien wrote:
> and forgot to mention, adding is fine. So if I add a new office hour
> to an existing user, I get a new entity as a child of the user.
>
> Also somewhat related and that I forgot to mention, the user itself,
> if modified, is also the right value, and is coming in from dvsDataMap
>
>
> On Thu, Oct 14, 2010 at 2:15 PM, Patrick Julien wrote:
>> Simple test case:
>>
>> User
>> Office hours
>>
>> I will get back entity proxies that are represent this information on
>> the client. If I call edit. The entire tree is now mutable thanks to
>> the latest fixes.
>>
>> However, if I update a sub-entity, when I fire this request back to
>> the server, I have the following:
>>
>> 1. Client side, office hours has the right value
>> 2. The json request has the right value in JsonRequestProcessor
>> 3. OfficeHours.findOfficeHours is called with the right id
>> 4. The right setter method is called with the right value on the
>> object, again all good.
>> 5. The newly modified entity is stored in dvsDataMap. Since this is a
>> delta, this is again good.
>> 6. The user object that is passed to the service method is the right
>> one, again all good
>>
>> However,
>>
>> 7. The office hours object passed in with the user object in step #6
>> is a pristine db copy. It's not the one from dvsDataMap, it's the one
>> that was collected when the user was first grabbed. So when I commit
>> the object graph, I commit without any modifications
>>
>> so we have
>> public static void persist(sessionId, userAccount) {
>> userAccount is the right one, modifications and all
>> but userAccount.List and its contents are the one from
>> returned from UserAccount.findUserAccount instead of what's in
>> dvsDataMap
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Not using dvsDataMap on child entities
and forgot to mention, adding is fine. So if I add a new office hour
to an existing user, I get a new entity as a child of the user.
Also somewhat related and that I forgot to mention, the user itself,
if modified, is also the right value, and is coming in from dvsDataMap
On Thu, Oct 14, 2010 at 2:15 PM, Patrick Julien wrote:
> Simple test case:
>
> User
> Office hours
>
> I will get back entity proxies that are represent this information on
> the client. If I call edit. The entire tree is now mutable thanks to
> the latest fixes.
>
> However, if I update a sub-entity, when I fire this request back to
> the server, I have the following:
>
> 1. Client side, office hours has the right value
> 2. The json request has the right value in JsonRequestProcessor
> 3. OfficeHours.findOfficeHours is called with the right id
> 4. The right setter method is called with the right value on the
> object, again all good.
> 5. The newly modified entity is stored in dvsDataMap. Since this is a
> delta, this is again good.
> 6. The user object that is passed to the service method is the right
> one, again all good
>
> However,
>
> 7. The office hours object passed in with the user object in step #6
> is a pristine db copy. It's not the one from dvsDataMap, it's the one
> that was collected when the user was first grabbed. So when I commit
> the object graph, I commit without any modifications
>
> so we have
> public static void persist(sessionId, userAccount) {
> userAccount is the right one, modifications and all
> but userAccount.List and its contents are the one from
> returned from UserAccount.findUserAccount instead of what's in
> dvsDataMap
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Not using dvsDataMap on child entities
Simple test case:
User
Office hours
I will get back entity proxies that are represent this information on
the client. If I call edit. The entire tree is now mutable thanks to
the latest fixes.
However, if I update a sub-entity, when I fire this request back to
the server, I have the following:
1. Client side, office hours has the right value
2. The json request has the right value in JsonRequestProcessor
3. OfficeHours.findOfficeHours is called with the right id
4. The right setter method is called with the right value on the
object, again all good.
5. The newly modified entity is stored in dvsDataMap. Since this is a
delta, this is again good.
6. The user object that is passed to the service method is the right
one, again all good
However,
7. The office hours object passed in with the user object in step #6
is a pristine db copy. It's not the one from dvsDataMap, it's the one
that was collected when the user was first grabbed. So when I commit
the object graph, I commit without any modifications
so we have
public static void persist(sessionId, userAccount) {
userAccount is the right one, modifications and all
but userAccount.List and its contents are the one from
returned from UserAccount.findUserAccount instead of what's in
dvsDataMap
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Editors - wiki documentation review requested
EditorComposite, it's not clear if you make your own when, or if, you should add sub-editor values to the collection that backs the EditorComposite. This burned us big time. driver.getPath() needs to be exposed somehow, I understand it isn't exposed here since entities are not mentioned Should explicitly state editors can be read-only, would be worthwhile I think. Not everyone is going to assume that editors can be used for "details". The document uses Label but why not make it a bullet point? I also sent in a use case a while back, you might want to give it a look. It asks how you should do layout of editors when you don't have a 1:1 object hierarchy to match the editors. On Mon, Oct 11, 2010 at 2:54 PM, BobV wrote: > http://code.google.com/p/google-web-toolkit/wiki/Editors > > What's missing? What's unclear? If you have been using the Editor > framework, what gotchas have you run into? > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] AutoBean frozen bug repeat
thanks, I've got the patch already On Sat, Oct 9, 2010 at 11:42 AM, BobV wrote: > On Fri, Oct 8, 2010 at 8:01 PM, Patrick Julien wrote: >> Proxies reached from getters from a mutable proxy aren't mutable > > In the meantime, you can can edit() for the entity that should be > mutable, but isn't. > > http://gwt-code-reviews.appspot.com/976801 > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Ensure that EntityProxy instances returned from Collections returned from an editable EntityProx... (issue976801)
thanks, I've got the patch already
On Sat, Oct 9, 2010 at 11:42 AM, Patrick Julien wrote:
> thank you
>
>
> On Sat, Oct 9, 2010 at 11:28 AM, wrote:
>> Reviewers: rjrjr,
>>
>> Description:
>> Ensure that EntityProxy instances returned from Collections returned
>> from an editable EntityProxy are editable.
>> Patch by: bobv
>> Review by: rjrjr
>> Found by: pjulien
>>
>>
>> Please review this at http://gwt-code-reviews.appspot.com/976801/show
>>
>> Affected files:
>> M
>> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
>> M user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
>>
>>
>> Index:
>> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
>> ===
>> ---
>> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
>> (revision 8983)
>> +++
>> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
>> (working copy)
>> @@ -49,8 +49,7 @@
>> return stableId(bean).hashCode();
>> }
>>
>> - public static AbstractRequestContext requestContext(
>> - AutoBean bean) {
>> + public static AbstractRequestContext requestContext(AutoBean bean) {
>> return (AbstractRequestContext) bean.getTag(REQUEST_CONTEXT);
>> }
>>
>> @@ -70,13 +69,11 @@
>> * EntityProxy, that its return values are mutable.
>> */
>> // CHECKSTYLE_OFF
>> - public static T __intercept(AutoBean bean,
>> - T returnValue) {
>> + public static T __intercept(AutoBean bean, T returnValue) {
>> // CHECKSTYLE_ON
>> - if (!(returnValue instanceof EntityProxy)) {
>> - return returnValue;
>> - }
>> +
>> AbstractRequestContext context = requestContext(bean);
>> +
>> /*
>> * The context will be null if the bean is immutable. If the context is
>> * locked, don't try to edit.
>> @@ -85,8 +82,26 @@
>> return returnValue;
>> }
>>
>> - �...@suppresswarnings("unchecked")
>> - T toReturn = (T) context.edit((EntityProxy) returnValue);
>> - return toReturn;
>> + /*
>> + * EntityProxies need to be recorded specially by the RequestContext,
>> so
>> + * delegate to the edit() method for wiring up the context.
>> + */
>> + if (returnValue instanceof EntityProxy) {
>> + �...@suppresswarnings("unchecked")
>> + T toReturn = (T) context.edit((EntityProxy) returnValue);
>> + return toReturn;
>> + }
>> +
>> + /*
>> + * We're returning some object that's not an EntityProxy, most likely a
>> + * Collection type. At the very least, propagate the current
>> RequestContext
>> + * so that editable chains can be constructed.
>> + */
>> + AutoBean otherBean = AutoBeanUtils.getAutoBean(returnValue);
>> + if (otherBean != null) {
>> + otherBean.setTag(EntityProxyCategory.REQUEST_CONTEXT,
>> + bean.getTag(EntityProxyCategory.REQUEST_CONTEXT));
>> + }
>> + return returnValue;
>> }
>> }
>> Index:
>> user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
>> ===
>> --- user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
>> (revision 8983)
>> +++ user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
>> (working copy)
>> @@ -1762,6 +1762,10 @@
>> @Override
>> public void onSuccess(SimpleFooProxy response) {
>> assertEquals(2, response.getOneToManyField().size());
>> +
>> + // Check lists of proxies returned from an mutable object are
>> mutable
>> + response = simpleFooRequest().edit(response);
>> + response.getOneToManyField().get(0).setUserName("canMutate");
>> finishTestAndReset();
>> }
>> });
>>
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Ensure that EntityProxy instances returned from Collections returned from an editable EntityProx... (issue976801)
thank you
On Sat, Oct 9, 2010 at 11:28 AM, wrote:
> Reviewers: rjrjr,
>
> Description:
> Ensure that EntityProxy instances returned from Collections returned
> from an editable EntityProxy are editable.
> Patch by: bobv
> Review by: rjrjr
> Found by: pjulien
>
>
> Please review this at http://gwt-code-reviews.appspot.com/976801/show
>
> Affected files:
> M
> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
> M user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
>
>
> Index:
> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
> ===
> ---
> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
> (revision 8983)
> +++
> user/src/com/google/gwt/requestfactory/client/impl/EntityProxyCategory.java
> (working copy)
> @@ -49,8 +49,7 @@
> return stableId(bean).hashCode();
> }
>
> - public static AbstractRequestContext requestContext(
> - AutoBean bean) {
> + public static AbstractRequestContext requestContext(AutoBean bean) {
> return (AbstractRequestContext) bean.getTag(REQUEST_CONTEXT);
> }
>
> @@ -70,13 +69,11 @@
> * EntityProxy, that its return values are mutable.
> */
> // CHECKSTYLE_OFF
> - public static T __intercept(AutoBean bean,
> - T returnValue) {
> + public static T __intercept(AutoBean bean, T returnValue) {
> // CHECKSTYLE_ON
> - if (!(returnValue instanceof EntityProxy)) {
> - return returnValue;
> - }
> +
> AbstractRequestContext context = requestContext(bean);
> +
> /*
> * The context will be null if the bean is immutable. If the context is
> * locked, don't try to edit.
> @@ -85,8 +82,26 @@
> return returnValue;
> }
>
> - �...@suppresswarnings("unchecked")
> - T toReturn = (T) context.edit((EntityProxy) returnValue);
> - return toReturn;
> + /*
> + * EntityProxies need to be recorded specially by the RequestContext,
> so
> + * delegate to the edit() method for wiring up the context.
> + */
> + if (returnValue instanceof EntityProxy) {
> + �...@suppresswarnings("unchecked")
> + T toReturn = (T) context.edit((EntityProxy) returnValue);
> + return toReturn;
> + }
> +
> + /*
> + * We're returning some object that's not an EntityProxy, most likely a
> + * Collection type. At the very least, propagate the current
> RequestContext
> + * so that editable chains can be constructed.
> + */
> + AutoBean otherBean = AutoBeanUtils.getAutoBean(returnValue);
> + if (otherBean != null) {
> + otherBean.setTag(EntityProxyCategory.REQUEST_CONTEXT,
> + bean.getTag(EntityProxyCategory.REQUEST_CONTEXT));
> + }
> + return returnValue;
> }
> }
> Index:
> user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
> ===
> --- user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
> (revision 8983)
> +++ user/test/com/google/gwt/requestfactory/client/RequestFactoryTest.java
> (working copy)
> @@ -1762,6 +1762,10 @@
> @Override
> public void onSuccess(SimpleFooProxy response) {
> assertEquals(2, response.getOneToManyField().size());
> +
> + // Check lists of proxies returned from an mutable object are
> mutable
> + response = simpleFooRequest().edit(response);
> + response.getOneToManyField().get(0).setUserName("canMutate");
> finishTestAndReset();
> }
> });
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] AutoBean frozen bug repeat
Proxies reached from getters from a mutable proxy aren't mutable
doc for edit:
/**
* Returns a mutable version of the proxy, whose mutations will accumulate in
* this context. Proxies reached via getters on this mutable proxy will also
* be mutable.
*/
T edit(T object);
reduced code showing problem:
final Driver driver = GWT.create(Driver.class);
driver.initialize(requests, view);
requests.domainRequest().get(getSessionId(),
getId()).with(driver.getPaths()).fire(chain.add(new
Receiver() {
@Override
public void onSuccess(final DomainHandle response) {
final PracticeRequest rc =
requests.practiceRequest();
final PracticeHandle practiceHandle =
rc.edit(response);
final Request r =
rc.persist(getSessionId(), practiceHandle);
// for loop added to show problem
for (final PatientNotificationHandle handle :
practiceHandle.getPatientNotifications()) {
handle.setNotificationScheme(PatientNotificationScheme.Daily);
}
// rest removed
}
}));
handle.setNotificationScheme throws here with "AutoBean is frozen"
sub-editors aren't able to set values either unlike my phantom problem
I reported earlier
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] AutoBean frozen bug
never mind,
rc.edit(response); returns a value, and that one is not frozen
On Thu, Oct 7, 2010 at 5:35 PM, Patrick Julien wrote:
> FYI, if I modify to:
>
> �...@override
> public String saveTriggered() {
> getRequestContext().edit(getValue());
> getValue().setActive(!view.isPracticeDeactivated());
> save();
> return null;
> }
>
> still throws
>
> Reduced test case:
>
> final Driver driver = GWT.create(Driver.class);
>
> driver.initialize(requests, view);
>
> requests.find(handle.stableId()).with(driver.getPaths()).fire(chain.add(new
> Receiver() {
> �...@override
> public void onSuccess(final PracticeHandle response) {
> final PracticeRequest rc =
> requests.practiceRequest();
>
> rc.edit(response);
> response.setActive(false); // Throws
> IllegalStateException
> }
> }));
>
>
> On Thu, Oct 7, 2010 at 5:27 PM, Patrick Julien wrote:
>> And I might add, otherwise the flush would fail, values coming from
>> the editors directly are fine
>>
>> On Thu, Oct 7, 2010 at 5:25 PM, Patrick Julien wrote:
>>> Yes, I know, rc.edit() is called, this is just before the flush,
>>> rc.edit has been called well before this.
>>>
>>> On Thu, Oct 7, 2010 at 5:23 PM, BobV wrote:
>>>> On Thu, Oct 7, 2010 at 1:55 PM, Patrick Julien wrote:
>>>>> They stay frozen, and finally, when flushing the driver, there is yet
>>>>> another loop to freeze all the AutoBeans. Nowhere in between were the
>>>>> beans made mutable. This is necessary because we sometimes have
>>>>> custom setters we must call. In this case, we have the following:
>>>>
>>>> This is as designed. All mutations to EntityProxy objects must be be
>>>> accumulated somewhere in order to be sent to the server. That
>>>> somewhere is the RequestContext. It's always necessary to call
>>>> RequestContext.edit() before mutating an EntityProxy.
>>>>
>>>> --
>>>> Bob Vawter
>>>> Google Web Toolkit Team
>>>>
>>>> --
>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] AutoBean frozen bug
FYI, if I modify to:
@Override
public String saveTriggered() {
getRequestContext().edit(getValue());
getValue().setActive(!view.isPracticeDeactivated());
save();
return null;
}
still throws
Reduced test case:
final Driver driver = GWT.create(Driver.class);
driver.initialize(requests, view);
requests.find(handle.stableId()).with(driver.getPaths()).fire(chain.add(new
Receiver() {
@Override
public void onSuccess(final PracticeHandle response) {
final PracticeRequest rc =
requests.practiceRequest();
rc.edit(response);
response.setActive(false); // Throws
IllegalStateException
}
}));
On Thu, Oct 7, 2010 at 5:27 PM, Patrick Julien wrote:
> And I might add, otherwise the flush would fail, values coming from
> the editors directly are fine
>
> On Thu, Oct 7, 2010 at 5:25 PM, Patrick Julien wrote:
>> Yes, I know, rc.edit() is called, this is just before the flush,
>> rc.edit has been called well before this.
>>
>> On Thu, Oct 7, 2010 at 5:23 PM, BobV wrote:
>>> On Thu, Oct 7, 2010 at 1:55 PM, Patrick Julien wrote:
>>>> They stay frozen, and finally, when flushing the driver, there is yet
>>>> another loop to freeze all the AutoBeans. Nowhere in between were the
>>>> beans made mutable. This is necessary because we sometimes have
>>>> custom setters we must call. In this case, we have the following:
>>>
>>> This is as designed. All mutations to EntityProxy objects must be be
>>> accumulated somewhere in order to be sent to the server. That
>>> somewhere is the RequestContext. It's always necessary to call
>>> RequestContext.edit() before mutating an EntityProxy.
>>>
>>> --
>>> Bob Vawter
>>> Google Web Toolkit Team
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] AutoBean frozen bug
And I might add, otherwise the flush would fail, values coming from the editors directly are fine On Thu, Oct 7, 2010 at 5:25 PM, Patrick Julien wrote: > Yes, I know, rc.edit() is called, this is just before the flush, > rc.edit has been called well before this. > > On Thu, Oct 7, 2010 at 5:23 PM, BobV wrote: >> On Thu, Oct 7, 2010 at 1:55 PM, Patrick Julien wrote: >>> They stay frozen, and finally, when flushing the driver, there is yet >>> another loop to freeze all the AutoBeans. Nowhere in between were the >>> beans made mutable. This is necessary because we sometimes have >>> custom setters we must call. In this case, we have the following: >> >> This is as designed. All mutations to EntityProxy objects must be be >> accumulated somewhere in order to be sent to the server. That >> somewhere is the RequestContext. It's always necessary to call >> RequestContext.edit() before mutating an EntityProxy. >> >> -- >> Bob Vawter >> Google Web Toolkit Team >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] AutoBean frozen bug
Yes, I know, rc.edit() is called, this is just before the flush, rc.edit has been called well before this. On Thu, Oct 7, 2010 at 5:23 PM, BobV wrote: > On Thu, Oct 7, 2010 at 1:55 PM, Patrick Julien wrote: >> They stay frozen, and finally, when flushing the driver, there is yet >> another loop to freeze all the AutoBeans. Nowhere in between were the >> beans made mutable. This is necessary because we sometimes have >> custom setters we must call. In this case, we have the following: > > This is as designed. All mutations to EntityProxy objects must be be > accumulated somewhere in order to be sent to the server. That > somewhere is the RequestContext. It's always necessary to call > RequestContext.edit() before mutating an EntityProxy. > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
r8965 fixed the remaining issue. The other issue was on the AutoBean
itself and was previously fixed. However, I believe I have found
another issue in AbstractAutoBean which I just posted.
On Thu, Oct 7, 2010 at 4:57 PM, Ray Cromwell wrote:
>
> Patrick,
> Are you using an ORM like hibernate or JDO? One of my concerns is, unless
> you wrap the entire request in an transaction, the result of any find()
> calls within JsonRequestProcessor are going to be detached objects.
> Different ORMs have different pre-fetched semantics, for example, some of
> them will by default, fetch 1-level deep references. After detachment,
> generally trying to retrieve a relational field returns null.
> JsonRequestProcessor is ORM agnostic, so it is generally up to the
> developer to ensure that objects will be completely filled out or lazily
> fillable before RequestFactory tries to serialize them.
>
> On Mon, Oct 4, 2010 at 11:15 AM, Ray Ryan wrote:
>>
>> https://jira.springsource.org/browse/ROO-1488
>>
>> On Mon, Oct 4, 2010 at 11:13 AM, Ray Ryan wrote:
>>>
>>> Bob is in transit today. We're working on a fix.
>>>
>>> On Mon, Oct 4, 2010 at 9:07 AM, Patrick Julien wrote:
>>>>
>>>> Bob,
>>>>
>>>> any suggestions for a work around for the moment?
>>>>
>>>>
>>>> On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien
>>>> wrote:
>>>> > For the editor part, I can see in the generated code for my editor
>>>> > that
>>>> >
>>>> > public static void traverseEditor(com.*.client.ui.EditorContainer
>>>> > editor, String prefix, java.util.List paths) {
>>>> > }
>>>> >
>>>> > is completely empty
>>>> >
>>>> > but in this case, EditorContainer contains OfficeEditor because it's a
>>>> > composite. OfficeEditor has one AddressEditor and a
>>>> > HasDataEditor
>>>> >
>>>> > so getPath() is currently buggy unless there's a way I can fill in my
>>>> > own traverseEditor somehow
>>>> >
>>>> > On Sun, Oct 3, 2010 at 9:47 PM, Patrick Julien
>>>> > wrote:
>>>> >> I'm still having difficulties even with this syntax, again the
>>>> >> collections seem to be the problem
>>>> >>
>>>> >> so having "offices" give me back all my offices.
>>>> >>
>>>> >> but putting "offices.address", or "offices.office.address" or
>>>> >> "office.address" still gives me null
>>>> >>
>>>> >> On Sun, Oct 3, 2010 at 9:07 PM, Ray Cromwell
>>>> >> wrote:
>>>> >>>
>>>> >>> the syntax of with() is with("property.subProperty.subSubProperty",
>>>> >>> "property2.subProperty2.subPropertyProperty2"). Bob can answer the
>>>> >>> question
>>>> >>> as to how to make deeply composited editors do the right thing.
>>>> >>>
>>>> >>> On Sun, Oct 3, 2010 at 6:02 PM, Patrick Julien
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> No, it's not just me, anything one level deep doesn't get picked
>>>> >>>> up.
>>>> >>>>
>>>> >>>> So my offices also have on address and it's not in the getPath()
>>>> >>>> array
>>>> >>>> either. Even if it was, what's the syntax for sub path elements?
>>>> >>>>
>>>> >>>> On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien
>>>> >>>> wrote:
>>>> >>>> > Getting there. So now getPaths() gets me the data for my offices
>>>> >>>> > and
>>>> >>>> > patients but not the phones inside the offices.
>>>> >>>> >
>>>> >>>> > Since offices is using my own composite editor, I'm going to
>>>> >>>> > assume
>>>> >>>> > that's where the problem is
>>>> >>>> >
>>>> >>>> > On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
>>>> >>>> >> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien
>>>> >>>> >>
>>>> >>>> >> wrote:
>>>
[gwt-contrib] AutoBean frozen bug
I believe I've encountered the bug. What I see is on reception, all
the entities proxies are made immutable.
They stay frozen, and finally, when flushing the driver, there is yet
another loop to freeze all the AutoBeans. Nowhere in between were the
beans made mutable. This is necessary because we sometimes have
custom setters we must call. In this case, we have the following:
@Override
public void saveTriggered() {
getValue().setActive(!view.isPracticeDeactivated());
save();
}
We need to invert the value of the check box, so we can't use the
checkbox directly as an editor. If I am creating a practice here
where the EntityProxy comes in from RequestContext.create() instead of
the server, everything is fine, the value is set to the proxy via this
call and save() proceeds to use the driver to flush changes. If the
entity proxy originated on the server however, calling set active
throws IllegalStateException("The AutoBean has been frozen");
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Other use case for editor framework
Hi Bob, If you're interested in more use cases for the editor framework, here's another one for you... The problem is actually pretty common, the idea is that if you want to create, or layout, an object in the hierarchy where it technically isn't, you can't. This happens quite a bit, and when it does, we have to step out of the editor framework and now that I'm using it, I never, ever want to do that again. Consider the following scenario from our application: 1. We create a practice 2. We create offices for this practice 3. We create a list of physician, nurses, etc. for the practice. These objects, the users, are now siblings of offices since they're both part of a practice Later on, say a physician, will login and assign availability for the offices. He can't create an office in the practice but he can create availability objects for each office. These new objects, his availability, are now owned by the user but obviously have a weak reference to an office. The layout on page would be practice (read only) -> list of offices (read only) -> list of availabilities per office for this (edit/create) But an "availability" object is not owned by an office, it's owned by a user. Using the editor framework, it's very easy to pull down an object graph that represents the practice and offices and lay them out. Even if it's read only, the data binding part of the editor framework is just too good to pass up. Then, however, we're kind of stuck on the list of availabilities. We have no way to tell the framework these "availability" objects need to be filled in for this office. Nor do we have the ability to receive a value, the user object, when creating it. We're using various kludges to get around this but I was thinking this scenario might be popular enough to expose. The solution could be as simple as having another EntityProxy for the entity, one that would support not having a @ProxyFor annotation, and we just fill it out before we pass data to the driver. We could make the point that we're setting data either way, we've just moved setting the values from somewhere to somewhere else but in the second case, we could do it all from one place, in a Receiver<>, that has no UI knowledge other than it needs to build a graph that makes sense for the current context. The other argument is once you've done the Editor framework, you can't come back from that, it's just too good and easy for getting things done quickly, so more data binding features are needed. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8965 committed - Resolves ROO-1508 by requiring CompositeEditors to return a canonical ...
Thank you, my editor works now, and on the first try too, I have a
very complex object graph and it just handles' it. GWT has never
been so good.
On Thu, Oct 7, 2010 at 10:52 AM, wrote:
> Revision: 8965
> Author: b...@google.com
> Date: Wed Oct 6 10:46:19 2010
> Log: Resolves ROO-1508 by requiring CompositeEditors to return a canonical
> component Editor instance for path traversal.
> Patch by: bobv
> Review by: rjrjr
>
> Review at http://gwt-code-reviews.appspot.com/965801
>
> http://code.google.com/p/google-web-toolkit/source/detail?r=8965
>
> Modified:
> /trunk/user/src/com/google/gwt/editor/client/CompositeEditor.java
> /trunk/user/src/com/google/gwt/editor/client/adapters/ListEditor.java
> /trunk/user/src/com/google/gwt/editor/client/adapters/OptionalFieldEditor.java
> /trunk/user/src/com/google/gwt/editor/rebind/AbstractEditorDriverGenerator.java
> /trunk/user/src/com/google/gwt/editor/rebind/model/EditorModel.java
> /trunk/user/test/com/google/gwt/requestfactory/client/ui/EditorTest.java
>
> ===
> --- /trunk/user/src/com/google/gwt/editor/client/CompositeEditor.java Mon
> Sep 13 09:30:34 2010
> +++ /trunk/user/src/com/google/gwt/editor/client/CompositeEditor.java Wed
> Oct 6 10:46:19 2010
> @@ -80,6 +80,12 @@
> */
> C getValue(E subEditor);
> }
> +
> + /**
> + * Returns an canonical sub-editor instance that will be used by the
> driver
> + * for computing all edited paths.
> + */
> + E createEditorForTraversal();
>
> /**
> * Used to implement {...@link EditorDelegate#getPath()}.
> ===
> --- /trunk/user/src/com/google/gwt/editor/client/adapters/ListEditor.java
> Mon Sep 13 09:30:34 2010
> +++ /trunk/user/src/com/google/gwt/editor/client/adapters/ListEditor.java
> Wed Oct 6 10:46:19 2010
> @@ -51,6 +51,12 @@
> protected ListEditor(EditorSource source) {
> this.editorSource = source;
> }
> +
> + public E createEditorForTraversal() {
> + E toReturn = editorSource.create(0);
> + editorSource.dispose(toReturn);
> + return toReturn;
> + }
>
> public void flush() {
> list.flush();
> ===
> ---
> /trunk/user/src/com/google/gwt/editor/client/adapters/OptionalFieldEditor.java
> Sun Oct 3 11:35:25 2010
> +++
> /trunk/user/src/com/google/gwt/editor/client/adapters/OptionalFieldEditor.java
> Wed Oct 6 10:46:19 2010
> @@ -62,6 +62,10 @@
> protected OptionalFieldEditor(E subEditor) {
> this.subEditor = subEditor;
> }
> +
> + public E createEditorForTraversal() {
> + return subEditor;
> + }
>
> public void flush() {
> currentValue = chain.getValue(subEditor);
> ===
> ---
> /trunk/user/src/com/google/gwt/editor/rebind/AbstractEditorDriverGenerator.java
> Wed Sep 29 11:01:14 2010
> +++
> /trunk/user/src/com/google/gwt/editor/rebind/AbstractEditorDriverGenerator.java
> Wed Oct 6 10:46:19 2010
> @@ -194,8 +194,8 @@
> for (EditorData d : data) {
> String mutableObjectExpression;
> if (d.getBeanOwnerExpression().length() > 0) {
> - mutableObjectExpression = mutableObjectExpression(d,
> String.format(
> - "(getObject()%s)", d.getBeanOwnerExpression()));
> + mutableObjectExpression = mutableObjectExpression(d,
> + String.format("(getObject()%s)",
> d.getBeanOwnerExpression()));
> } else {
> mutableObjectExpression = "getObject()";
> }
> @@ -294,7 +294,8 @@
> editor.getQualifiedSourceName(), List.class.getName());
> sw.indent();
> for (EditorData d : data) {
> - if (d.isDelegateRequired() || d.isDeclaredPathNested()) {
> + if (d.isDelegateRequired() || d.isDeclaredPathNested()
> + || d.isCompositeEditor()) {
> // if (editor.subEditor != null) {
> sw.println("if (editor.%s != null) {", d.getSimpleExpression());
> sw.indent();
> @@ -308,6 +309,15 @@
> sw.println("%s.traverseEditor(editor.%s, localPath, paths);",
> getEditorDelegate(d), d.getSimpleExpression());
> }
> + if (d.isCompositeEditor()) {
> + /*
> + * composedDelegate.traverseEditor(editor.subEditor.
> + * createEditorForTraversal(), localPath, paths);
> + */
> + sw.println(
> + "%s.traverseEditor(editor.%s.createEditorForTraversal(),
> localPath, paths);",
> + getEditorDelegate(d.getComposedData()),
> d.getSimpleExpression());
> + }
> sw.outdent();
> sw.println("}");
> }
> @@ -330,7 +340,7 @@
> * @param context
> * @param model
> * @param sw
> - *
> + *
> * @throws UnableToCompleteException
> */
> protected void writeAdditionalContent(TreeLogger logger,
> ===
> --- /trunk/user/src/com/google/gwt/editor/rebind/model/Editor
Re: [gwt-contrib] Sub entities not being filled in
OK, this also works for me, where it breaks down is more collections
So I go back to practice, offices and phones
class Practice { private List offices; }
class Office { private List phones; }
practive is unique and has a list of offices
What I get back has all the practice seeded. All the offices are
seeded and it has all its values but phones is null.
If I add "offices.phones", it works, I get a non null list of phone
handles but the values on the handles are not set.
Now I manually add, in addition to "offices.phones",
"offices.phones.number" the value of number is still null
I believe this respect the syntax you outlined here. I can confirm on
the server in json request processor on the server that the phone
entities are there and have values when processed but the
subProperties map in RequestProperty is null so it returns false when
it tests if it should include these values or not
On Mon, Oct 4, 2010 at 5:46 PM, Ray Cromwell wrote:
>
> The following test case passes:
> public void testCollectionSubProperties() {
> delayTestFinish(DELAY_TEST_FINISH);
> simpleFooRequest().getSimpleFooWithSubPropertyCollection().with(
> "selfOneToManyField.fooField").fire(new Receiver() {
> �...@override
> public void onSuccess(SimpleFooProxy response) {
> assertEquals("I'm Here",
>
> response.getSelfOneToManyField().get(0).getFooField().getUserName());
> }
> });
> }
> on the server:
> public static SimpleFoo getSimpleFooWithSubPropertyCollection() {
> SimpleFoo foo = new SimpleFoo();
> SimpleFoo subFoo = new SimpleFoo();
> SimpleFoo subSubFoo = new SimpleFoo();
> subFoo.setFooField(subSubFoo);
> subSubFoo.setUserName("I'm here");
> subSubFoo.persist();
> subFoo.persist();
> foo.persist();
> foo.setSelfOneToManyField(Arrays.asList(subFoo));
> return foo;
> }
> If you have a class that looks like this:
> public class Company {
> List offices;
> }
> public class Office {
> Employee siteManager;
> }
> Then the correct way to query for siteManager is:
> with("offices.siteManager")
> With is a nothing more than a filter on names, it doesn't care if something
> is a collection, or an entity, just whether or not the name matches.
> -Ray
> On Mon, Oct 4, 2010 at 2:32 PM, BobV wrote:
>>
>> Your feedback has been very helpful in finding out where the weak
>> points in our APIs and implementations are.
>>
>> > driver.getPath() isn't able to completely scan an editor tree when it
>> > contains CompositeEditor's that, they themselves, have more editors in
>> > their hierarchy
>>
>> I'm thinking about how to solve this one, since an uninitialized
>> CompositeEditor won't have any sub-editors to query.
>>
>> > It's not possible to request sub-properties when using collections
>> > manually. It just doesn't work. The example I gave were trying to
>> > get the name of an office inside a collection, putting
>>
>> RayC is looking at this.
>>
>> --
>> 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] Sub entities not being filled in
On Mon, Oct 4, 2010 at 5:32 PM, BobV wrote:
> Your feedback has been very helpful in finding out where the weak
> points in our APIs and implementations are.
>
>> driver.getPath() isn't able to completely scan an editor tree when it
>> contains CompositeEditor's that, they themselves, have more editors in
>> their hierarchy
>
> I'm thinking about how to solve this one, since an uninitialized
> CompositeEditor won't have any sub-editors to query.
You're using code generation for the other parts. What I mean by that
is that you generate the method
public static void traverseEditor(com.*.client.ui.EditorContainer
editor, String prefix, java.util.List paths) {
}
and that has content that was made at compile time, not run time.
Here, the editor you're looking for is right there in CompositeEditor
CompositeEditor>
So whatever E is the children. Is that not suitable here also?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
I don't know what to tell you, I'm going to have to look at this again
because it just does not work for me
On Mon, Oct 4, 2010 at 5:46 PM, Ray Cromwell wrote:
>
> The following test case passes:
> public void testCollectionSubProperties() {
> delayTestFinish(DELAY_TEST_FINISH);
> simpleFooRequest().getSimpleFooWithSubPropertyCollection().with(
> "selfOneToManyField.fooField").fire(new Receiver() {
> �...@override
> public void onSuccess(SimpleFooProxy response) {
> assertEquals("I'm Here",
>
> response.getSelfOneToManyField().get(0).getFooField().getUserName());
> }
> });
> }
> on the server:
> public static SimpleFoo getSimpleFooWithSubPropertyCollection() {
> SimpleFoo foo = new SimpleFoo();
> SimpleFoo subFoo = new SimpleFoo();
> SimpleFoo subSubFoo = new SimpleFoo();
> subFoo.setFooField(subSubFoo);
> subSubFoo.setUserName("I'm here");
> subSubFoo.persist();
> subFoo.persist();
> foo.persist();
> foo.setSelfOneToManyField(Arrays.asList(subFoo));
> return foo;
> }
> If you have a class that looks like this:
> public class Company {
> List offices;
> }
> public class Office {
> Employee siteManager;
> }
> Then the correct way to query for siteManager is:
> with("offices.siteManager")
> With is a nothing more than a filter on names, it doesn't care if something
> is a collection, or an entity, just whether or not the name matches.
> -Ray
> On Mon, Oct 4, 2010 at 2:32 PM, BobV wrote:
>>
>> Your feedback has been very helpful in finding out where the weak
>> points in our APIs and implementations are.
>>
>> > driver.getPath() isn't able to completely scan an editor tree when it
>> > contains CompositeEditor's that, they themselves, have more editors in
>> > their hierarchy
>>
>> I'm thinking about how to solve this one, since an uninitialized
>> CompositeEditor won't have any sub-editors to query.
>>
>> > It's not possible to request sub-properties when using collections
>> > manually. It just doesn't work. The example I gave were trying to
>> > get the name of an office inside a collection, putting
>>
>> RayC is looking at this.
>>
>> --
>> 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] Sub entities not being filled in
As an update to this issue, I can confirm that I have an editor
working in another scenario where the depth level doesn't go beyond,
well, 1 I guess.
So I an editor, and it has a list in it but the list doesn't contain
other EntityProxy's
The two issues still remain:
driver.getPath() isn't able to completely scan an editor tree when it
contains CompositeEditor's that, they themselves, have more editors in
their hierarchy
It's not possible to request sub-properties when using collections
manually. It just doesn't work. The example I gave were trying to
get the name of an office inside a collection, putting
offices
office
offices.name
office.name
offices.office.name
just doesn't work.
On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien wrote:
> For the editor part, I can see in the generated code for my editor that
>
> public static void traverseEditor(com.*.client.ui.EditorContainer
> editor, String prefix, java.util.List paths) {
> }
>
> is completely empty
>
> but in this case, EditorContainer contains OfficeEditor because it's a
> composite. OfficeEditor has one AddressEditor and a
> HasDataEditor
>
> so getPath() is currently buggy unless there's a way I can fill in my
> own traverseEditor somehow
>
> On Sun, Oct 3, 2010 at 9:47 PM, Patrick Julien wrote:
>> I'm still having difficulties even with this syntax, again the
>> collections seem to be the problem
>>
>> so having "offices" give me back all my offices.
>>
>> but putting "offices.address", or "offices.office.address" or
>> "office.address" still gives me null
>>
>> On Sun, Oct 3, 2010 at 9:07 PM, Ray Cromwell wrote:
>>>
>>> the syntax of with() is with("property.subProperty.subSubProperty",
>>> "property2.subProperty2.subPropertyProperty2"). Bob can answer the question
>>> as to how to make deeply composited editors do the right thing.
>>>
>>> On Sun, Oct 3, 2010 at 6:02 PM, Patrick Julien wrote:
>>>>
>>>> No, it's not just me, anything one level deep doesn't get picked up.
>>>>
>>>> So my offices also have on address and it's not in the getPath() array
>>>> either. Even if it was, what's the syntax for sub path elements?
>>>>
>>>> On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien wrote:
>>>> > Getting there. So now getPaths() gets me the data for my offices and
>>>> > patients but not the phones inside the offices.
>>>> >
>>>> > Since offices is using my own composite editor, I'm going to assume
>>>> > that's where the problem is
>>>> >
>>>> > On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
>>>> >> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien
>>>> >> wrote:
>>>> >>> Yeah, because even with using with(). The problem is the entire
>>>> >>> object graph isn't there
>>>> >>>
>>>> >>> So I have a practice that has offices and each office has phones.
>>>> >>>
>>>> >>> So if I ask for offices. It fills in the offices but the phones
>>>> >>> inside it are not. This could get laborious if I need to do this
>>>> >>> manually for each editing activity
>>>> >>
>>>> >> Use RequestFactoryEditorDriver.getPaths();
>>>> >>
>>>> >>
>>>> >> interface MyOfficeDriver extends
>>>> >> RequesFactoryEditorDriver {}
>>>> >>
>>>> >> MyOfficeDriver driver = GWT.create(MyOfficeDriver.class);
>>>> >> driver.initialize(requestFactory, editor);
>>>> >>
>>>> >> requestFactory.officeService().fetchOffice(1234).with(driver.getPaths()).to(receiver).fire();
>>>> >>
>>>> >>
>>>> >> --
>>>> >> 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
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
Bob,
any suggestions for a work around for the moment?
On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien wrote:
> For the editor part, I can see in the generated code for my editor that
>
> public static void traverseEditor(com.*.client.ui.EditorContainer
> editor, String prefix, java.util.List paths) {
> }
>
> is completely empty
>
> but in this case, EditorContainer contains OfficeEditor because it's a
> composite. OfficeEditor has one AddressEditor and a
> HasDataEditor
>
> so getPath() is currently buggy unless there's a way I can fill in my
> own traverseEditor somehow
>
> On Sun, Oct 3, 2010 at 9:47 PM, Patrick Julien wrote:
>> I'm still having difficulties even with this syntax, again the
>> collections seem to be the problem
>>
>> so having "offices" give me back all my offices.
>>
>> but putting "offices.address", or "offices.office.address" or
>> "office.address" still gives me null
>>
>> On Sun, Oct 3, 2010 at 9:07 PM, Ray Cromwell wrote:
>>>
>>> the syntax of with() is with("property.subProperty.subSubProperty",
>>> "property2.subProperty2.subPropertyProperty2"). Bob can answer the question
>>> as to how to make deeply composited editors do the right thing.
>>>
>>> On Sun, Oct 3, 2010 at 6:02 PM, Patrick Julien wrote:
>>>>
>>>> No, it's not just me, anything one level deep doesn't get picked up.
>>>>
>>>> So my offices also have on address and it's not in the getPath() array
>>>> either. Even if it was, what's the syntax for sub path elements?
>>>>
>>>> On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien wrote:
>>>> > Getting there. So now getPaths() gets me the data for my offices and
>>>> > patients but not the phones inside the offices.
>>>> >
>>>> > Since offices is using my own composite editor, I'm going to assume
>>>> > that's where the problem is
>>>> >
>>>> > On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
>>>> >> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien
>>>> >> wrote:
>>>> >>> Yeah, because even with using with(). The problem is the entire
>>>> >>> object graph isn't there
>>>> >>>
>>>> >>> So I have a practice that has offices and each office has phones.
>>>> >>>
>>>> >>> So if I ask for offices. It fills in the offices but the phones
>>>> >>> inside it are not. This could get laborious if I need to do this
>>>> >>> manually for each editing activity
>>>> >>
>>>> >> Use RequestFactoryEditorDriver.getPaths();
>>>> >>
>>>> >>
>>>> >> interface MyOfficeDriver extends
>>>> >> RequesFactoryEditorDriver {}
>>>> >>
>>>> >> MyOfficeDriver driver = GWT.create(MyOfficeDriver.class);
>>>> >> driver.initialize(requestFactory, editor);
>>>> >>
>>>> >> requestFactory.officeService().fetchOffice(1234).with(driver.getPaths()).to(receiver).fire();
>>>> >>
>>>> >>
>>>> >> --
>>>> >> 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
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
For the editor part, I can see in the generated code for my editor that
public static void traverseEditor(com.*.client.ui.EditorContainer
editor, String prefix, java.util.List paths) {
}
is completely empty
but in this case, EditorContainer contains OfficeEditor because it's a
composite. OfficeEditor has one AddressEditor and a
HasDataEditor
so getPath() is currently buggy unless there's a way I can fill in my
own traverseEditor somehow
On Sun, Oct 3, 2010 at 9:47 PM, Patrick Julien wrote:
> I'm still having difficulties even with this syntax, again the
> collections seem to be the problem
>
> so having "offices" give me back all my offices.
>
> but putting "offices.address", or "offices.office.address" or
> "office.address" still gives me null
>
> On Sun, Oct 3, 2010 at 9:07 PM, Ray Cromwell wrote:
>>
>> the syntax of with() is with("property.subProperty.subSubProperty",
>> "property2.subProperty2.subPropertyProperty2"). Bob can answer the question
>> as to how to make deeply composited editors do the right thing.
>>
>> On Sun, Oct 3, 2010 at 6:02 PM, Patrick Julien wrote:
>>>
>>> No, it's not just me, anything one level deep doesn't get picked up.
>>>
>>> So my offices also have on address and it's not in the getPath() array
>>> either. Even if it was, what's the syntax for sub path elements?
>>>
>>> On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien wrote:
>>> > Getting there. So now getPaths() gets me the data for my offices and
>>> > patients but not the phones inside the offices.
>>> >
>>> > Since offices is using my own composite editor, I'm going to assume
>>> > that's where the problem is
>>> >
>>> > On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
>>> >> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien
>>> >> wrote:
>>> >>> Yeah, because even with using with(). The problem is the entire
>>> >>> object graph isn't there
>>> >>>
>>> >>> So I have a practice that has offices and each office has phones.
>>> >>>
>>> >>> So if I ask for offices. It fills in the offices but the phones
>>> >>> inside it are not. This could get laborious if I need to do this
>>> >>> manually for each editing activity
>>> >>
>>> >> Use RequestFactoryEditorDriver.getPaths();
>>> >>
>>> >>
>>> >> interface MyOfficeDriver extends
>>> >> RequesFactoryEditorDriver {}
>>> >>
>>> >> MyOfficeDriver driver = GWT.create(MyOfficeDriver.class);
>>> >> driver.initialize(requestFactory, editor);
>>> >>
>>> >> requestFactory.officeService().fetchOffice(1234).with(driver.getPaths()).to(receiver).fire();
>>> >>
>>> >>
>>> >> --
>>> >> 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
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
I'm still having difficulties even with this syntax, again the
collections seem to be the problem
so having "offices" give me back all my offices.
but putting "offices.address", or "offices.office.address" or
"office.address" still gives me null
On Sun, Oct 3, 2010 at 9:07 PM, Ray Cromwell wrote:
>
> the syntax of with() is with("property.subProperty.subSubProperty",
> "property2.subProperty2.subPropertyProperty2"). Bob can answer the question
> as to how to make deeply composited editors do the right thing.
>
> On Sun, Oct 3, 2010 at 6:02 PM, Patrick Julien wrote:
>>
>> No, it's not just me, anything one level deep doesn't get picked up.
>>
>> So my offices also have on address and it's not in the getPath() array
>> either. Even if it was, what's the syntax for sub path elements?
>>
>> On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien wrote:
>> > Getting there. So now getPaths() gets me the data for my offices and
>> > patients but not the phones inside the offices.
>> >
>> > Since offices is using my own composite editor, I'm going to assume
>> > that's where the problem is
>> >
>> > On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
>> >> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien
>> >> wrote:
>> >>> Yeah, because even with using with(). The problem is the entire
>> >>> object graph isn't there
>> >>>
>> >>> So I have a practice that has offices and each office has phones.
>> >>>
>> >>> So if I ask for offices. It fills in the offices but the phones
>> >>> inside it are not. This could get laborious if I need to do this
>> >>> manually for each editing activity
>> >>
>> >> Use RequestFactoryEditorDriver.getPaths();
>> >>
>> >>
>> >> interface MyOfficeDriver extends
>> >> RequesFactoryEditorDriver {}
>> >>
>> >> MyOfficeDriver driver = GWT.create(MyOfficeDriver.class);
>> >> driver.initialize(requestFactory, editor);
>> >>
>> >> requestFactory.officeService().fetchOffice(1234).with(driver.getPaths()).to(receiver).fire();
>> >>
>> >>
>> >> --
>> >> 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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
No, it's not just me, anything one level deep doesn't get picked up.
So my offices also have on address and it's not in the getPath() array
either. Even if it was, what's the syntax for sub path elements?
On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien wrote:
> Getting there. So now getPaths() gets me the data for my offices and
> patients but not the phones inside the offices.
>
> Since offices is using my own composite editor, I'm going to assume
> that's where the problem is
>
> On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
>> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien wrote:
>>> Yeah, because even with using with(). The problem is the entire
>>> object graph isn't there
>>>
>>> So I have a practice that has offices and each office has phones.
>>>
>>> So if I ask for offices. It fills in the offices but the phones
>>> inside it are not. This could get laborious if I need to do this
>>> manually for each editing activity
>>
>> Use RequestFactoryEditorDriver.getPaths();
>>
>>
>> interface MyOfficeDriver extends
>> RequesFactoryEditorDriver {}
>>
>> MyOfficeDriver driver = GWT.create(MyOfficeDriver.class);
>> driver.initialize(requestFactory, editor);
>> requestFactory.officeService().fetchOffice(1234).with(driver.getPaths()).to(receiver).fire();
>>
>>
>> --
>> Bob Vawter
>> Google Web Toolkit Team
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
Getting there. So now getPaths() gets me the data for my offices and
patients but not the phones inside the offices.
Since offices is using my own composite editor, I'm going to assume
that's where the problem is
On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
> On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien wrote:
>> Yeah, because even with using with(). The problem is the entire
>> object graph isn't there
>>
>> So I have a practice that has offices and each office has phones.
>>
>> So if I ask for offices. It fills in the offices but the phones
>> inside it are not. This could get laborious if I need to do this
>> manually for each editing activity
>
> Use RequestFactoryEditorDriver.getPaths();
>
>
> interface MyOfficeDriver extends
> RequesFactoryEditorDriver {}
>
> MyOfficeDriver driver = GWT.create(MyOfficeDriver.class);
> driver.initialize(requestFactory, editor);
> requestFactory.officeService().fetchOffice(1234).with(driver.getPaths()).to(receiver).fire();
>
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Sub entities not being filled in
Yeah, because even with using with(). The problem is the entire
object graph isn't there
So I have a practice that has offices and each office has phones.
So if I ask for offices. It fills in the offices but the phones
inside it are not. This could get laborious if I need to do this
manually for each editing activity
On Sun, Oct 3, 2010 at 7:17 PM, Patrick Julien wrote:
> Is there a wildcard value? I don't want the all the fields when
> listing but when I go in edit details, I do
>
> On Sun, Oct 3, 2010 at 7:10 PM, Ray Cromwell wrote:
>>
>> Any relational (non-value fields) are by default not sent back with a
>> request, you must request them with the with() method, e.g.
>> with("superVisor"). Just because you sent some object over with that field,
>> doesn't mean that the field will also be returned to you, because a method
>> could potentially return a very large set of objects, e.g.
>> Request> getEmployeesFrom(EmployeeProxy boss);
>>
>> Here I am passing the manager's proxy, and it might have a
>> Collection managedEmployees on it, but if I'm only interested
>> in the names of the people that 'boss' manages, I don't want to
>> automatically return the 'managedEmployees' field of each returned object,
>> even if it was present on boss, so instead, you write
>> getEmployeesFrom(boss).with("managedEmployees").fire(...) if you want that
>> field.
>> Perhaps the editor framework is not setting up these with() calls as it
>> should be?
>> On Sun, Oct 3, 2010 at 3:11 PM, Patrick Julien wrote:
>>>
>>> I'm getting used to this editor framework and I like it a lot,
>>> unfortunately, I think I've stumble upon a blocker for me.
>>>
>>> EntityProxy's that contain collections are not being filled in. So
>>> you can send up an object graph in one shot in order to save it.
>>> Which is great.
>>>
>>> Unfortunately, on return, the object graph only contains the root.
>>> This is because in JsoRequestProcessor.requestedProperty, it does:
>>>
>>> if (EntityProxy.class.isAssignableFrom(leafType)) {
>>> return propertyContext.hasProperty(p.getName());
>>> }
>>>
>>> to check if child entities should be included but that's an empty set
>>> so it always returns false
>>>
>>> If it wasn't, we have TODO here TODO: use the properties
>>> * that should be coming with the request.
>>>
>>> that says this thing should eventually be able to do this but wouldn't
>>> the safest behavior for now to include all the contents of the Entity
>>> that are featured in EntityProxyId? I'm stuck at this point.
>>>
>>> --
>>> 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] Sub entities not being filled in
Is there a wildcard value? I don't want the all the fields when
listing but when I go in edit details, I do
On Sun, Oct 3, 2010 at 7:10 PM, Ray Cromwell wrote:
>
> Any relational (non-value fields) are by default not sent back with a
> request, you must request them with the with() method, e.g.
> with("superVisor"). Just because you sent some object over with that field,
> doesn't mean that the field will also be returned to you, because a method
> could potentially return a very large set of objects, e.g.
> Request> getEmployeesFrom(EmployeeProxy boss);
>
> Here I am passing the manager's proxy, and it might have a
> Collection managedEmployees on it, but if I'm only interested
> in the names of the people that 'boss' manages, I don't want to
> automatically return the 'managedEmployees' field of each returned object,
> even if it was present on boss, so instead, you write
> getEmployeesFrom(boss).with("managedEmployees").fire(...) if you want that
> field.
> Perhaps the editor framework is not setting up these with() calls as it
> should be?
> On Sun, Oct 3, 2010 at 3:11 PM, Patrick Julien wrote:
>>
>> I'm getting used to this editor framework and I like it a lot,
>> unfortunately, I think I've stumble upon a blocker for me.
>>
>> EntityProxy's that contain collections are not being filled in. So
>> you can send up an object graph in one shot in order to save it.
>> Which is great.
>>
>> Unfortunately, on return, the object graph only contains the root.
>> This is because in JsoRequestProcessor.requestedProperty, it does:
>>
>> if (EntityProxy.class.isAssignableFrom(leafType)) {
>> return propertyContext.hasProperty(p.getName());
>> }
>>
>> to check if child entities should be included but that's an empty set
>> so it always returns false
>>
>> If it wasn't, we have TODO here TODO: use the properties
>> * that should be coming with the request.
>>
>> that says this thing should eventually be able to do this but wouldn't
>> the safest behavior for now to include all the contents of the Entity
>> that are featured in EntityProxyId? I'm stuck at this point.
>>
>> --
>> 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
[gwt-contrib] Sub entities not being filled in
I'm getting used to this editor framework and I like it a lot,
unfortunately, I think I've stumble upon a blocker for me.
EntityProxy's that contain collections are not being filled in. So
you can send up an object graph in one shot in order to save it.
Which is great.
Unfortunately, on return, the object graph only contains the root.
This is because in JsoRequestProcessor.requestedProperty, it does:
if (EntityProxy.class.isAssignableFrom(leafType)) {
return propertyContext.hasProperty(p.getName());
}
to check if child entities should be included but that's an empty set
so it always returns false
If it wasn't, we have TODO here TODO: use the properties
* that should be coming with the request.
that says this thing should eventually be able to do this but wouldn't
the safest behavior for now to include all the contents of the Entity
that are featured in EntityProxyId? I'm stuck at this point.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Update DynaTableRf sample to demonstrate Leaf+CompositeEditor that shows how to work with option... (issue948801)
If you allow me another comment now that I've done this. HasDataEditor works pretty well but is stuck using List. Set isn't supported at all and is just as common On Sat, Oct 2, 2010 at 8:19 PM, wrote: > Reviewers: rjrjr, > > Description: > Update DynaTableRf sample to demonstrate Leaf+CompositeEditor that shows > how to work with optional fields. > Patch by: bobv > Review by: rjrjr > Suggested by: pjulien > > > Please review this at http://gwt-code-reviews.appspot.com/948801/show > > Affected files: > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/PersonEditorWorkflow.java > A > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/widgets/MentorSelector.java > A > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/widgets/MentorSelector.ui.xml > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/widgets/NameLabel.java > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/widgets/PersonEditor.java > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/widgets/PersonEditor.ui.xml > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/client/widgets/SummaryWidget.java > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/domain/Person.java > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/server/SchoolCalendarService.java > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/shared/DynaTableRequestFactory.java > M > samples/dynatablerf/src/com/google/gwt/sample/dynatablerf/shared/PersonProxy.java > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Fix NullPointerException in SimpleEntityProxyId. (issue949801)
Thank you very much On Sun, Oct 3, 2010 at 1:51 PM, wrote: > Reviewers: rjrjr, > > Description: > Fix NullPointerException in SimpleEntityProxyId. > Patch by: bobv > Review by: rjrjr > Suggested by: pjulien > > > Please review this at http://gwt-code-reviews.appspot.com/949801/show > > Affected files: > M > user/src/com/google/gwt/requestfactory/client/impl/SimpleEntityProxyId.java > M user/test/com/google/gwt/requestfactory/RequestFactoryJreSuite.java > A > user/test/com/google/gwt/requestfactory/client/impl/SimpleEntityProxyIdTest.java > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
Reduced test case:
PhoneHandle handle1 = rc.create(PhoneHandle.class);
PhoneHandle handle2 = rc.create(PhoneHandle.class);
assert !handle1.equals(handle2);
throws because serverId is null in SimpleEntityProxyId
On Sun, Oct 3, 2010 at 12:28 PM, Patrick Julien wrote:
> I have this almost going.
>
> I hit a bug in public
>
> SimpleEntityProxyId.equals
>
> boolean equals(Object o) {
> if (!(o instanceof SimpleEntityProxyId)) {
> return false;
> }
> SimpleEntityProxyId other = (SimpleEntityProxyId) o;
> if (!proxyClass.equals(other.proxyClass)) {
> return false;
> }
> return (clientId != NEVER_EPHEMERAL && clientId == other.clientId)
> || serverId.equals(other.serverId);
> }
>
> both entities here were created locally.
>
> So here I'll have clientId == 12 and other.clientId == 13 for example.
>
> So that part is OK but then it goes into the ||
>
> serverId here is null because it never got into the server, so it throws an
> NPE.
>
>
>
>
>
> On Sun, Oct 3, 2010 at 11:43 AM, Patrick Julien wrote:
>> On Sun, Oct 3, 2010 at 11:21 AM, BobV wrote:
>>> On Sun, Oct 3, 2010 at 10:57 AM, Patrick Julien wrote:
>>>> Any sample somewhere then because I am not getting how to use this
>>>> class properly
>>>
>>> The FavoritesWidget in the DynaTableRf sample uses ListEditor. See
>>> the uses of the displayedList field. It works this way so that
>>> re-ordering operations on the list (like calling Collections.sort())
>>> will keep both the backing data and the displayed list of editors in
>>> sync.
>>
>> I'm aware of this widget but I'm trying to use HasDataEditor with a
>> CellTable so it doesn't exactly translate 1:1
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
I have this almost going.
I hit a bug in public
SimpleEntityProxyId.equals
boolean equals(Object o) {
if (!(o instanceof SimpleEntityProxyId)) {
return false;
}
SimpleEntityProxyId other = (SimpleEntityProxyId) o;
if (!proxyClass.equals(other.proxyClass)) {
return false;
}
return (clientId != NEVER_EPHEMERAL && clientId == other.clientId)
|| serverId.equals(other.serverId);
}
both entities here were created locally.
So here I'll have clientId == 12 and other.clientId == 13 for example.
So that part is OK but then it goes into the ||
serverId here is null because it never got into the server, so it throws an NPE.
On Sun, Oct 3, 2010 at 11:43 AM, Patrick Julien wrote:
> On Sun, Oct 3, 2010 at 11:21 AM, BobV wrote:
>> On Sun, Oct 3, 2010 at 10:57 AM, Patrick Julien wrote:
>>> Any sample somewhere then because I am not getting how to use this
>>> class properly
>>
>> The FavoritesWidget in the DynaTableRf sample uses ListEditor. See
>> the uses of the displayedList field. It works this way so that
>> re-ordering operations on the list (like calling Collections.sort())
>> will keep both the backing data and the displayed list of editors in
>> sync.
>
> I'm aware of this widget but I'm trying to use HasDataEditor with a
> CellTable so it doesn't exactly translate 1:1
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
On Sun, Oct 3, 2010 at 11:21 AM, BobV wrote: > On Sun, Oct 3, 2010 at 10:57 AM, Patrick Julien wrote: >> Any sample somewhere then because I am not getting how to use this >> class properly > > The FavoritesWidget in the DynaTableRf sample uses ListEditor. See > the uses of the displayedList field. It works this way so that > re-ordering operations on the list (like calling Collections.sort()) > will keep both the backing data and the displayed list of editors in > sync. I'm aware of this widget but I'm trying to use HasDataEditor with a CellTable so it doesn't exactly translate 1:1 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
Any sample somewhere then because I am not getting how to use this class properly On Sun, Oct 3, 2010 at 10:54 AM, BobV wrote: > On Sun, Oct 3, 2010 at 10:24 AM, Patrick Julien wrote: >> The biggest problem I have so far with HasDataEditor is that it >> completely ignores HasDataEditor mutation of the data source. > > This is intentional. HasDataEditor and its superclass, ListEditor > require that mutations of the structure of the list occur through the > wrapper retrieved from ListEditor.getList(). > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
The biggest problem I have so far with HasDataEditor is that it completely ignores HasDataEditor mutation of the data source. so HandlerRegistration addRangeChangeHandler(RangeChangeEvent.Handler handler); HandlerRegistration addRowCountChangeHandler( RowCountChangeEvent.Handler handler); aren't used. Because of that, it's not able to handle the scenarios of the inline list that adds or remove items. In this case, a simple list of phones. This list changes if we create a row and it also changes if we hit the remove button on a row On Sat, Oct 2, 2010 at 9:20 PM, Patrick Julien wrote: > On Sat, Oct 2, 2010 at 9:07 PM, BobV wrote: >> On Sat, Oct 2, 2010 at 8:45 PM, Patrick Julien wrote: >>> thank you for the clarification, I get it >> >> I'm adding a new adapter class to handle this case, since optional >> fields seems like a common thing to see and implementing it manually >> requires a lot of boilerplate. > > I think it will see a lot of use. > >> >>> I don't suppose you have advice for using a mutable CellTable in the >>> editor framework? >> >> Does the HasDataEditor adapter work for you? >> > > It doesn't, because each row can be edited... but cell table doesn't > give you access to its rows, only a column format. Here, the editor > are actually the cells. So a button cell is a remove button. A edit > text cell is the number and a selection cell is the phone type. > > I can just make a table but cell table added all this work to with > keyboard, mouse, blur, etc., events. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
On Sat, Oct 2, 2010 at 9:07 PM, BobV wrote: > On Sat, Oct 2, 2010 at 8:45 PM, Patrick Julien wrote: >> thank you for the clarification, I get it > > I'm adding a new adapter class to handle this case, since optional > fields seems like a common thing to see and implementing it manually > requires a lot of boilerplate. I think it will see a lot of use. > >> I don't suppose you have advice for using a mutable CellTable in the >> editor framework? > > Does the HasDataEditor adapter work for you? > It doesn't, because each row can be edited... but cell table doesn't give you access to its rows, only a column format. Here, the editor are actually the cells. So a button cell is a remove button. A edit text cell is the number and a selection cell is the phone type. I can just make a table but cell table added all this work to with keyboard, mouse, blur, etc., events. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8918 committed - Overhaul the client-side portions of RequestFactory....
Works for me, and have to say, this is pretty sweet. Also, very nice
touch throwing an exception if an entity crosses request context.
On Sat, Oct 2, 2010 at 5:25 PM, Patrick Julien wrote:
> Ah sorry, it's the request members of RequestFactory can now inherit
> from RequestContext. Will give that a go
>
> If that works, would be pretty sweet
>
>
>
> On Sat, Oct 2, 2010 at 4:53 PM, Patrick Julien wrote:
>> sorry, s/rc/rf/
>>
>> RequestFactory doesn't have create anymore, neither does Request,
>> which is the problem.
>>
>> I'm more than fine with RequestFactory not having it because it gives
>> the impression your objects are application scope instead of request
>> scope. But without create on Request, we don't have a good way of
>> doing this
>>
>> On Sat, Oct 2, 2010 at 4:52 PM, Patrick Julien wrote:
>>> On Sat, Oct 2, 2010 at 4:41 PM, BobV wrote:
>>>> On Sat, Oct 2, 2010 at 1:56 PM, Patrick Julien wrote:
>>>>> This assumes that the built in persist method works for everyone and
>>>>> it really, really doesn't. Now we have a serious chicken and egg
>>>>> problem because our persist methods take the form:
>>>>>
>>>>> record persist(credentials, record);
>>>>>
>>>>> but now we can't create a record until after we've called persist from
>>>>> the RequestContext interface
>>>>
>>>> I'm assuming from your message that the persist method above is an
>>>> instance method on your Record domain type. If it's not, just change
>>>> InstanceRequest to Request and drop the using() call.
>>>
>>> It's not, it's a method, non-static, of service object.
>>>
>>>
>>>>
>>>> interface RecordService extends RequestContext {
>>>> // < instance type, return type >
>>>> InstanceRequest persist(CredentialsProxy
>>>> credentials, RecordProxy record);
>>>> }
>>>>
>>>> interface MyFactory extends RequestFactory {
>>>> RecordService recordService();
>>>> }
>>>>
>>>> RecordService svc = rf.recordService();
>>>> RecordProxy record = rf.create(RecordProxy.class);
>>>> CredentialsProxy cred = rf.create(CredentialsProxy.class);
>>>> svc.persist(cred, record).using(record).to(new Receiver()).fire();
>>>>
>>>>
>>>
>>> That doesn't work because rc.create() is gone. Otherwise, yeah, it's great
>>>
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
thank you for the clarification, I get it I don't suppose you have advice for using a mutable CellTable in the editor framework? On Sat, Oct 2, 2010 at 8:34 PM, BobV wrote: >> But if the generic parameter was a collection, wouldn't the fact that >> it's a leaf editor prevent the framework from entering sub-editors? > > Hence the explicit chain.attach() call. If you wanted to edit an > optional list, you could replace the nameLabel with the ListEditor > adaptor class. Assuming that a PersonMight have a list of mentors: > > // That's editor.client.adapters.ListEditor > MentorSelector implements LeafValueEditor>, > CompositeEditor, List, ListEditor NameLabel>> > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
This actually makes sense to me but if the composite editor is set or
a list, the framework will still be able to construct those types?
You have
> CompositeEditor,
> LeafValueEditor {
But if the generic parameter was a collection, wouldn't the fact that
it's a leaf editor prevent the framework from entering sub-editors?
On Sat, Oct 2, 2010 at 7:31 PM, BobV wrote:
> It's possible to set a null field to a non-null value by making a Leaf
> CompositeEditor. I'll update the DynaTableRf sample with something
> better than this, but I think it demonstrates the point. The
> assumption is that PersonProxy.getManager() returns null in the
> default dataset.
>
>
> public class ManagerSelector extends Composite implements
> CompositeEditor,
> LeafValueEditor {
>
> private EditorChain chain;
> private NameLabel nameLabel = new NameLabel(new SimpleEventBus());
> private PersonProxy manager;
>
> public ManagerSelector() {
> FlowPanel fp = new FlowPanel();
> Button b = new Button("Choose randomly");
>
> b.addClickHandler(new ClickHandler() {
> public void onClick(ClickEvent event) {
> DynaTableRequestFactory rf = DynaTableRf.getRequestFactory();
>
> int i = new Random().nextInt(100);
> rf.schoolCalendarRequest().getPeople(i, 1).to(
> new Receiver>() {
> �...@override
> public void onSuccess(List response) {
> assert response.size() == 1;
> setValue(response.get(0));
> }
> }).fire();
> }
> });
>
> fp.add(b);
> fp.add(nameLabel);
> initWidget(fp);
> }
>
> public void flush() {
> }
>
> public String getPathElement(NameLabel subEditor) {
> return "";
> }
>
> public PersonProxy getValue() {
> return manager;
> }
>
> public void onPropertyChange(String... paths) {
> }
>
> public void setDelegate(EditorDelegate delegate) {
> }
>
> public void setEditorChain(EditorChain chain) {
> this.chain = chain;
> }
>
> public void setValue(PersonProxy value) {
> this.manager = value;
>
> if (manager != null) {
> chain.attach(manager, nameLabel);
> }
> }
>
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8918 committed - Overhaul the client-side portions of RequestFactory....
Ah sorry, it's the request members of RequestFactory can now inherit
from RequestContext. Will give that a go
If that works, would be pretty sweet
On Sat, Oct 2, 2010 at 4:53 PM, Patrick Julien wrote:
> sorry, s/rc/rf/
>
> RequestFactory doesn't have create anymore, neither does Request,
> which is the problem.
>
> I'm more than fine with RequestFactory not having it because it gives
> the impression your objects are application scope instead of request
> scope. But without create on Request, we don't have a good way of
> doing this
>
> On Sat, Oct 2, 2010 at 4:52 PM, Patrick Julien wrote:
>> On Sat, Oct 2, 2010 at 4:41 PM, BobV wrote:
>>> On Sat, Oct 2, 2010 at 1:56 PM, Patrick Julien wrote:
>>>> This assumes that the built in persist method works for everyone and
>>>> it really, really doesn't. Now we have a serious chicken and egg
>>>> problem because our persist methods take the form:
>>>>
>>>> record persist(credentials, record);
>>>>
>>>> but now we can't create a record until after we've called persist from
>>>> the RequestContext interface
>>>
>>> I'm assuming from your message that the persist method above is an
>>> instance method on your Record domain type. If it's not, just change
>>> InstanceRequest to Request and drop the using() call.
>>
>> It's not, it's a method, non-static, of service object.
>>
>>
>>>
>>> interface RecordService extends RequestContext {
>>> // < instance type, return type >
>>> InstanceRequest persist(CredentialsProxy
>>> credentials, RecordProxy record);
>>> }
>>>
>>> interface MyFactory extends RequestFactory {
>>> RecordService recordService();
>>> }
>>>
>>> RecordService svc = rf.recordService();
>>> RecordProxy record = rf.create(RecordProxy.class);
>>> CredentialsProxy cred = rf.create(CredentialsProxy.class);
>>> svc.persist(cred, record).using(record).to(new Receiver()).fire();
>>>
>>>
>>
>> That doesn't work because rc.create() is gone. Otherwise, yeah, it's great
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8918 committed - Overhaul the client-side portions of RequestFactory....
sorry, s/rc/rf/
RequestFactory doesn't have create anymore, neither does Request,
which is the problem.
I'm more than fine with RequestFactory not having it because it gives
the impression your objects are application scope instead of request
scope. But without create on Request, we don't have a good way of
doing this
On Sat, Oct 2, 2010 at 4:52 PM, Patrick Julien wrote:
> On Sat, Oct 2, 2010 at 4:41 PM, BobV wrote:
>> On Sat, Oct 2, 2010 at 1:56 PM, Patrick Julien wrote:
>>> This assumes that the built in persist method works for everyone and
>>> it really, really doesn't. Now we have a serious chicken and egg
>>> problem because our persist methods take the form:
>>>
>>> record persist(credentials, record);
>>>
>>> but now we can't create a record until after we've called persist from
>>> the RequestContext interface
>>
>> I'm assuming from your message that the persist method above is an
>> instance method on your Record domain type. If it's not, just change
>> InstanceRequest to Request and drop the using() call.
>
> It's not, it's a method, non-static, of service object.
>
>
>>
>> interface RecordService extends RequestContext {
>> // < instance type, return type >
>> InstanceRequest persist(CredentialsProxy
>> credentials, RecordProxy record);
>> }
>>
>> interface MyFactory extends RequestFactory {
>> RecordService recordService();
>> }
>>
>> RecordService svc = rf.recordService();
>> RecordProxy record = rf.create(RecordProxy.class);
>> CredentialsProxy cred = rf.create(CredentialsProxy.class);
>> svc.persist(cred, record).using(record).to(new Receiver()).fire();
>>
>>
>
> That doesn't work because rc.create() is gone. Otherwise, yeah, it's great
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8918 committed - Overhaul the client-side portions of RequestFactory....
On Sat, Oct 2, 2010 at 4:41 PM, BobV wrote:
> On Sat, Oct 2, 2010 at 1:56 PM, Patrick Julien wrote:
>> This assumes that the built in persist method works for everyone and
>> it really, really doesn't. Now we have a serious chicken and egg
>> problem because our persist methods take the form:
>>
>> record persist(credentials, record);
>>
>> but now we can't create a record until after we've called persist from
>> the RequestContext interface
>
> I'm assuming from your message that the persist method above is an
> instance method on your Record domain type. If it's not, just change
> InstanceRequest to Request and drop the using() call.
It's not, it's a method, non-static, of service object.
>
> interface RecordService extends RequestContext {
> // < instance type, return type >
> InstanceRequest persist(CredentialsProxy
> credentials, RecordProxy record);
> }
>
> interface MyFactory extends RequestFactory {
> RecordService recordService();
> }
>
> RecordService svc = rf.recordService();
> RecordProxy record = rf.create(RecordProxy.class);
> CredentialsProxy cred = rf.create(CredentialsProxy.class);
> svc.persist(cred, record).using(record).to(new Receiver()).fire();
>
>
That doesn't work because rc.create() is gone. Otherwise, yeah, it's great
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
If anyone is hurting with this, it's because all values need to be set
to non null before they can be part of the editor framework, unless
you're using a composite
If you're using a composite, the idea is to set a non null container
value like so:
domainHandle = requests.create(DomainHandle.class);
r = requests.domainRequest().persist(getSessionId(),
domainHandle);
driver = GWT.create(Driver.class);
driver.initialize(requests, view);
domainHandle = r.edit(domainHandle);
domainHandle.setOffices(new HashSet()); // This
creates the empty set
domainHandle.setSecuritySettings(requests.create(SecuritySettingsHandle.class));
Then your composite will get called via the setValue method, this is
the set or list you newed up in your handle if you setup is OK
@Override
public void setValue(final C value) {
this.collection = value;
}
Then, when you're ready to flush, flush gets called, you just insert
whatever value you need in your collection
@Override
public void flush() {
for (int i = 0, j = editors.size(); i < j; i++) {
E subEditor = editors.get(i);
T value = chain.getValue(subEditor);
if (backing.get(i) != value)
backing.set(i, value);
collection.add(value);
}
}
On Sat, Oct 2, 2010 at 12:02 PM, Patrick Julien wrote:
> Even if I put in things manually, let's say
>
> EditorContainer, OfficeEditor> offices;
>
> which is a CompositeEditor
>
> public class EditorContainer, E extends
> Editor> extends FlowPanel implements CompositeEditor
>
> I can set new up and place the HashSet<> manually inside the parent of
> the office because it will get squashed the next time the editor is
> flushed since EditorContainer gets setValue called with null
>
>
>
> On Sat, Oct 2, 2010 at 11:00 AM, Patrick Julien wrote:
>> But I am getting null for my child objects, that is the question, must
>> I make sure all child entities are created before given them to the
>> root editor? That doesn't make much sense to me
>>
>>
>> On Sat, Oct 2, 2010 at 10:38 AM, Thomas Broyer wrote:
>>>
>>> On Oct 2, 4:15 pm, Patrick Julien wrote:
>>>> What does it take exactly?
>>>>
>>>> If I look at dynatblerf sample, there is an AddressEditor in a
>>>> PersonEditor and it just seems to work.
>>>>
>>>> I have the same thing, I have a SecuritySettingsEditor inside another
>>>> Editor and when I get the EntityProxy back, the security settings
>>>> field is always null. What does it take for the editor to generate
>>>> the value?
>>>
>>> The DynatableRF sample's Person never has a 'null' Address; it might
>>> be an "empty" Address instance, but never the null value. It might be
>>> the reason.
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
Even if I put in things manually, let's say EditorContainer, OfficeEditor> offices; which is a CompositeEditor public class EditorContainer, E extends Editor> extends FlowPanel implements CompositeEditor I can set new up and place the HashSet<> manually inside the parent of the office because it will get squashed the next time the editor is flushed since EditorContainer gets setValue called with null On Sat, Oct 2, 2010 at 11:00 AM, Patrick Julien wrote: > But I am getting null for my child objects, that is the question, must > I make sure all child entities are created before given them to the > root editor? That doesn't make much sense to me > > > On Sat, Oct 2, 2010 at 10:38 AM, Thomas Broyer wrote: >> >> On Oct 2, 4:15 pm, Patrick Julien wrote: >>> What does it take exactly? >>> >>> If I look at dynatblerf sample, there is an AddressEditor in a >>> PersonEditor and it just seems to work. >>> >>> I have the same thing, I have a SecuritySettingsEditor inside another >>> Editor and when I get the EntityProxy back, the security settings >>> field is always null. What does it take for the editor to generate >>> the value? >> >> The DynatableRF sample's Person never has a 'null' Address; it might >> be an "empty" Address instance, but never the null value. It might be >> the reason. >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: creating resource automatically from editors
But I am getting null for my child objects, that is the question, must I make sure all child entities are created before given them to the root editor? That doesn't make much sense to me On Sat, Oct 2, 2010 at 10:38 AM, Thomas Broyer wrote: > > On Oct 2, 4:15 pm, Patrick Julien wrote: >> What does it take exactly? >> >> If I look at dynatblerf sample, there is an AddressEditor in a >> PersonEditor and it just seems to work. >> >> I have the same thing, I have a SecuritySettingsEditor inside another >> Editor and when I get the EntityProxy back, the security settings >> field is always null. What does it take for the editor to generate >> the value? > > The DynatableRF sample's Person never has a 'null' Address; it might > be an "empty" Address instance, but never the null value. It might be > the reason. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] creating resource automatically from editors
What does it take exactly? If I look at dynatblerf sample, there is an AddressEditor in a PersonEditor and it just seems to work. I have the same thing, I have a SecuritySettingsEditor inside another Editor and when I get the EntityProxy back, the security settings field is always null. What does it take for the editor to generate the value? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: editor framework and radio buttons
Is there a wave or doc somewhere about the editor framework? I'm looking to see if this can be used to create child un-owned relationships too On Fri, Oct 1, 2010 at 7:32 PM, Patrick Julien wrote: > On Fri, Oct 1, 2010 at 7:28 PM, Thomas Broyer wrote: >> >> >> On 2 oct, 01:17, Patrick Julien wrote: >>> Ah, now I know what you're saying, I was trying to wrap this thing in >>> a decorator, you just need to use it directly since it's an editor >> >> AFAICT, the only thing you won't have is the display of validation >> errors (which ValueBoxEditorDecorator takes care of; in other words, >> ValueBoxEditorDecorator has no other use than adding this feature to >> any ValueBoxBase, by implementing both HasEditorErrors and IsEditor) > > > True, but at the same time, it's a check box, validation shouldn't be > an issue anyway > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: editor framework and radio buttons
On Fri, Oct 1, 2010 at 7:28 PM, Thomas Broyer wrote: > > > On 2 oct, 01:17, Patrick Julien wrote: >> Ah, now I know what you're saying, I was trying to wrap this thing in >> a decorator, you just need to use it directly since it's an editor > > AFAICT, the only thing you won't have is the display of validation > errors (which ValueBoxEditorDecorator takes care of; in other words, > ValueBoxEditorDecorator has no other use than adding this feature to > any ValueBoxBase, by implementing both HasEditorErrors and IsEditor) True, but at the same time, it's a check box, validation shouldn't be an issue anyway -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] JsonRequestProcessor.validateKeys
The problem is inside in JsonRequestProcessor in the method updatePropertyTypes It's using entity.getDeclaredFields() which will omit all inherited fields. On Fri, Oct 1, 2010 at 5:24 PM, Pascal Patry wrote: > I'm currently having 2 issues with "JsonRequestProcessor.validateKeys()". > These requests are coming from updates that we want to perform on entities > that are driven by EntityProxy. > > The first issue is with inheritance. We have a base class for all our > entities on the server side in order to not have to replicate common > fields like the last update timestamp, the creation timestamp or even > the container id. So, on the concrete Entity, there are no containerId > field, but the client can send this data to the server in the update > request. When this happens, we encounter an exception on the server. > > "Error: key containerId is not permitted to be set" > > It seems that the validator is not picking up properties coming from the > inherited base entity class. getContainerId() and setContainerId() with > proper signature are present on the concrete entity. > > > The second issue we are getting is related to the same validation and > is producing the same exception. We have transient functions in some > entities to fill our needs. Let's take an example where the UserAccount > has a birth date set on the entity, but we only want to expose the age > of it when a client list these entities. We then have the proper getAge() > function on UserAccount that is a transient property that we compute on > the fly. When some changes are applied to a UserAccountEntityProxy from > an Editor, we use RequestFactoryEditorDriver to drive the update which > will carry this transient property back to the server. So, when > validation occurs on this field, it will be rejected because "the key > is not permitted to be set", which is true, but which we really don't care > about. I can create a dummy setter and field to get passed the issue, > but this is really annoying and misleading. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: editor framework and radio buttons
Ah, now I know what you're saying, I was trying to wrap this thing in a decorator, you just need to use it directly since it's an editor On Fri, Oct 1, 2010 at 7:03 PM, Patrick Julien wrote: > On Fri, Oct 1, 2010 at 6:51 PM, Thomas Broyer wrote: >> >> >> On 1 oct, 18:14, Patrick Julien wrote: >>> yeah, CheckBox doesn't work out of the box either because it needs to >>> implement ValueBase >> >> Because you try to wrap it in a ValueBoxEditorDecorator? > > Yep, I have, you need ValueBase in order to use a ValueBox > >> Judging from the code (i.e. I haven't tested to confirm what I'm >> saying here), CheckBox should work as a "simple" IsEditor (i.e. >> @UiField CheckBox myBooleanPropertyEditor) > > That works but the driver can't find this editor, so you don't get > binding from your backing type to the UI type > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: editor framework and radio buttons
On Fri, Oct 1, 2010 at 6:51 PM, Thomas Broyer wrote: > > > On 1 oct, 18:14, Patrick Julien wrote: >> yeah, CheckBox doesn't work out of the box either because it needs to >> implement ValueBase > > Because you try to wrap it in a ValueBoxEditorDecorator? Yep, I have, you need ValueBase in order to use a ValueBox > Judging from the code (i.e. I haven't tested to confirm what I'm > saying here), CheckBox should work as a "simple" IsEditor (i.e. > @UiField CheckBox myBooleanPropertyEditor) That works but the driver can't find this editor, so you don't get binding from your backing type to the UI type -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: editor framework and radio buttons
yeah, CheckBox doesn't work out of the box either because it needs to implement ValueBase On Fri, Oct 1, 2010 at 8:36 AM, Patrick Julien wrote: > thanks for the info > > On Fri, Oct 1, 2010 at 5:27 AM, Thomas Broyer wrote: >> >> On Sep 30, 6:56 pm, Patrick Julien wrote: >>> Is there a class that integrates the two? same for check boxes? >> >> Hmm, CheckBox implements IsEditor> so it >> should work OK for a boolean value. >> >> RadioButton extends CheckBox so it's a "boolean editor", but radio >> buttons are not about boolean things... :-/ >> >> I think for checkbox lists (multi-valued selection) and radio button >> lists (and even a Cell-widget-based selector), you'd (currently) have >> to make your own Editor class. >> It seems hard to provide such editors out-of-the-box because there are >> many use cases, depending on whether you want the value be the "index" >> in a list of acceptable values, the "form value" of the checkbox/ >> radiobutton, or an object in a list of acceptable values (this is >> similar to why ListBox does not implement HasValue); not to mention >> how you'd like your checkboxes/radiobuttons be laid out! >> >> (Also noteworthy: SimpleCheckBox implements neither IsEditor or even >> HasValue; and for single selection within a dropdown list, there's >> ValueListBox) >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: editor framework and radio buttons
thanks for the info On Fri, Oct 1, 2010 at 5:27 AM, Thomas Broyer wrote: > > On Sep 30, 6:56 pm, Patrick Julien wrote: >> Is there a class that integrates the two? same for check boxes? > > Hmm, CheckBox implements IsEditor> so it > should work OK for a boolean value. > > RadioButton extends CheckBox so it's a "boolean editor", but radio > buttons are not about boolean things... :-/ > > I think for checkbox lists (multi-valued selection) and radio button > lists (and even a Cell-widget-based selector), you'd (currently) have > to make your own Editor class. > It seems hard to provide such editors out-of-the-box because there are > many use cases, depending on whether you want the value be the "index" > in a list of acceptable values, the "form value" of the checkbox/ > radiobutton, or an object in a list of acceptable values (this is > similar to why ListBox does not implement HasValue); not to mention > how you'd like your checkboxes/radiobuttons be laid out! > > (Also noteworthy: SimpleCheckBox implements neither IsEditor or even > HasValue; and for single selection within a dropdown list, there's > ValueListBox) > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] editor framework and radio buttons
Is there a class that integrates the two? same for check boxes? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: moving to EntityProxyId
8897 fixes it, thank you On Wed, Sep 29, 2010 at 5:18 PM, Patrick Julien wrote: > I am trying to migrate to EntityProxyId and all I can get is > > java.lang.AssertionError: encodedId required > > I can my response from from AbstractRequest.handleResponseText, I do > get the response I expect out of the server, but obviously without any > kind of encoded id in the payload. > > I added > > EntityProxyId stableId(); > > to Type > > Anything else I need to do to enable this functionality? > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] moving to EntityProxyId
I am trying to migrate to EntityProxyId and all I can get is java.lang.AssertionError: encodedId required I can my response from from AbstractRequest.handleResponseText, I do get the response I expect out of the server, but obviously without any kind of encoded id in the payload. I added EntityProxyId stableId(); to Type Anything else I need to do to enable this functionality? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] EntityProxyId
It's not very clear to me how EntityProxyId helps us achieve very simple scenarios. How do you use this thing when you have pre and post operations to do in an activity? If I have an edit scenario, let's say a user with a list of phones, normally, I would follow something like this: 1. Set the record in the activity 2. Start the activity 3. In start, get the id of the user and list the phones 4. When I receive the phone, I show the display of the edit activity I don't see how this is done anymore with EntityProxyId. How do I get my phone numbers? On the client side, the only member EntityProxyId has is getClass(), what I'm a suppose to give to the server to find my phone numbers? It's the same problem if you want to do something post save. If I want to save the phones of a newly created user, I would do: 1. Exit is called from AbstractProxyEditActivity 2. Save the user 3. Get the id of the newly created user 4. Attach the phone numbers to the newly created user Again, here, with EntityProxyId, I have no idea how you do this anymore. I don't mean to complain here but seriously how do you use this thing? It's so opaque that I can't do anything with it -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8838 committed - Placeholder for RC1 Maven and GPE artifacts.
Using RequestFactory, we can only call static methods on the server now correct? On Wed, Sep 22, 2010 at 3:09 PM, Rajeev Dayal wrote: > Sorry, I'm not sure what you're referring to here. > > On Wed, Sep 22, 2010 at 1:58 PM, Patrick Julien wrote: >> >> Hmm, does that mean we would still be stuck using only static methods? >> I mean, it's not that far out to introduce a helper class to find >> types. >> >> >> On Wed, Sep 22, 2010 at 1:35 PM, wrote: >> > Revision: 8838 >> > Author: rda...@google.com >> > Date: Wed Sep 22 10:34:59 2010 >> > Log: Placeholder for RC1 Maven and GPE artifacts. >> > >> > http://code.google.com/p/google-web-toolkit/source/detail?r=8838 >> > >> > Added: >> > /2.1.0.RC1 >> > >> > -- >> > 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [google-web-toolkit] r8838 committed - Placeholder for RC1 Maven and GPE artifacts.
Hmm, does that mean we would still be stuck using only static methods? I mean, it's not that far out to introduce a helper class to find types. On Wed, Sep 22, 2010 at 1:35 PM, wrote: > Revision: 8838 > Author: rda...@google.com > Date: Wed Sep 22 10:34:59 2010 > Log: Placeholder for RC1 Maven and GPE artifacts. > > http://code.google.com/p/google-web-toolkit/source/detail?r=8838 > > Added: > /2.1.0.RC1 > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] stableId
I see how to use find now, it automatically calls a static method
called "find" on the entity object. This is kind of
bizarre to me and I actually liked the old manual, find request better
because it at least allowed us to keep the method, even if it's static
for now, on the service class instead of the entity class.
With this new mechanism, it can't go to the service class because the
service is FindService already, so it goes to the entity.
On Mon, Sep 20, 2010 at 3:37 PM, Patrick Julien wrote:
> OK, for me, this has nothing to do with find, at least not yet, I
> don't even get that far. What's tripping me up is that up until now,
> we could always get back the id of the entity in
> AbstractProxyEditActivity before the find request had completed but
> now, getRecord() returns null, this is expected considering find
> hasn't completed.
>
> So in start(AcceptsOneWidget display, EventBus eventBus) {
> // delay
> // getId to get some child owned resources, now getRecord() returns
> null so getRecord().getId() throws NPE
> }
>
> and then later really start the display by calling super.start where
> super is AbstractProxyEditActivity
>
> we can work around this but I'm still taking the time to expose the
> issue here.
>
> That and I'm still not sure how we implement find on our end in the
> server with this new mechanism
>
>
>
>
> On Mon, Sep 20, 2010 at 3:05 PM, Patrick Julien wrote:
>> On Mon, Sep 20, 2010 at 3:03 PM, Ray Ryan wrote:
>>> Ah, I noticed that exception in the find method too. I thought I had
>>> introduced the problem, but I think instead I just started using the feature
>>> for the first time.
>>> Patrick, is the exception reliable? Do you have a recipe?
>>
>>
>> I'm just started on this but yes, it is definitely reliable, it always fires
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] stableId
OK, for me, this has nothing to do with find, at least not yet, I
don't even get that far. What's tripping me up is that up until now,
we could always get back the id of the entity in
AbstractProxyEditActivity before the find request had completed but
now, getRecord() returns null, this is expected considering find
hasn't completed.
So in start(AcceptsOneWidget display, EventBus eventBus) {
// delay
// getId to get some child owned resources, now getRecord() returns
null so getRecord().getId() throws NPE
}
and then later really start the display by calling super.start where
super is AbstractProxyEditActivity
we can work around this but I'm still taking the time to expose the
issue here.
That and I'm still not sure how we implement find on our end in the
server with this new mechanism
On Mon, Sep 20, 2010 at 3:05 PM, Patrick Julien wrote:
> On Mon, Sep 20, 2010 at 3:03 PM, Ray Ryan wrote:
>> Ah, I noticed that exception in the find method too. I thought I had
>> introduced the problem, but I think instead I just started using the feature
>> for the first time.
>> Patrick, is the exception reliable? Do you have a recipe?
>
>
> I'm just started on this but yes, it is definitely reliable, it always fires
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] stableId
On Mon, Sep 20, 2010 at 3:03 PM, Ray Ryan wrote: > Ah, I noticed that exception in the find method too. I thought I had > introduced the problem, but I think instead I just started using the feature > for the first time. > Patrick, is the exception reliable? Do you have a recipe? I'm just started on this but yes, it is definitely reliable, it always fires -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] stableId
After tracing this, it's throwing an exception on this new generic
find() stuff from the abstract editor so it has nothing to do with
stableId. StableId is returning a value correctly.
About the comment, I was just confused because of the word "persisted"
which to me means JPA or something. We have the UI almost done and
the server part is currently just a mock that news up objects
currently so this comment and the fact that we don't have persistence
of anything is what led me to believe this was the problem.
On Mon, Sep 20, 2010 at 2:16 PM, Amit Manjhi wrote:
> The javadoc wording can probably be improved. Comments welcome.
> Essentially, what the javadoc wants to capture is specified in the test:
> com.google.gwt.requestfactory.client.RequestFactoryTest::testStableId()
> Btw, stableId() call on an EntityProxy should never return null. Can you
> post a reproducible test case?
>
> On Mon, Sep 20, 2010 at 10:57 AM, Patrick Julien wrote:
>>
>> On Mon, Sep 20, 2010 at 1:48 PM, Amit Manjhi
>> wrote:
>> > stableId is not a field in the EntityProxy. It is computed when
>> > stableId()
>> > is called on an EntityProxy. Does that help?
>>
>> not yet no, I understand what you're saying but I don't understand the
>> comments in EntityProxyId that says:
>>
>> "In particular, an {...@link EntityProxy} foo that is yet to be persisted and
>> a
>> * copy of foo after being persisted have equal {...@link EntityProxyId}."
>>
>> Based on what you're saying, persistence shouldn't matter here at all.
>>
>> The other thing that I have to figure out is why is stableId returning
>> null if it's computed when called
>>
>> --
>> 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] stableId
On Mon, Sep 20, 2010 at 2:16 PM, Amit Manjhi wrote: > The javadoc wording can probably be improved. Comments welcome. > Essentially, what the javadoc wants to capture is specified in the test: > com.google.gwt.requestfactory.client.RequestFactoryTest::testStableId() > Btw, stableId() call on an EntityProxy should never return null. Can you > post a reproducible test case? Yeah, I'm still digesting this, expect a follow up -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] stableId
On Mon, Sep 20, 2010 at 1:48 PM, Amit Manjhi wrote:
> stableId is not a field in the EntityProxy. It is computed when stableId()
> is called on an EntityProxy. Does that help?
not yet no, I understand what you're saying but I don't understand the
comments in EntityProxyId that says:
"In particular, an {...@link EntityProxy} foo that is yet to be persisted and a
* copy of foo after being persisted have equal {...@link EntityProxyId}."
Based on what you're saying, persistence shouldn't matter here at all.
The other thing that I have to figure out is why is stableId returning
null if it's computed when called
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] stableId
What exactly fills in this field currently? This field is always null for me on the client -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
