Maybe I should rephrase my question. I have a REST service in place that serves JSON... you know, GET, PUT, POST... the lot. So I am not currently using any GWT RPC or RequestFactoryServlet mechanisms, nor do I have JPA-annotated beans in my project. The only thing I do have is a suite of JavaScriptObjects that model the responses from the server.
I would like my UI views to be able to take advantage of new features like CellTables and EditorSupport - the goal being a reduction of boilerplate code in list-style views and better validation and form-checking in edit views. At a high level, how much work do I have cut out for myself to use these features? Since my server isn't using RequestFactoryServlet, it looks like I get no benefit from the RequestFactoryGenerator. So in addition to writing my own DeltaValueStore and Record implementations (since I can't use the provided or generated ones) I would also have to write my own RequestFactory implementation to take advantage of the AbstractRecordEditActivity. That seems like an awfully long way to go if my server isn't GWT-friendly. Just my $0.02. On Sat, Jul 24, 2010 at 2:55 PM, Jarrod Carlson <[email protected]>wrote: > I think it goes a bit deeper then that. > > EditorSupport depends on DeltaValueStore, which depends on Record. While > Record is merely an interface, its provided implementation, RecordImpl, > depends on RecordJsoImpl, all three of which imply that my Record (however > it is implemented) has both "id" and "version" properties. I am pulling JSON > data from an existing REST service, and neither of those properties exist. > (my service uses "uri" as the identifier and does not currently support a > "version") > > So what I'm seeing is a potentially long, uphill battle to get any use out > of EditorSupport. Meaning I will need to write my own DeltaValueStore and > Record implementations. Am I wrong? > > Also, on the topic of Records, the provided implementation doesn't support > nested properties on the native JSO. Take the following JSON from the server > as an example: > > { > uri: "/users/bobjones", > details: { > firstName: "Bob", > lastName: "Jones", > email: "[email protected]" > } > } > > Since RecordJsoImpl uses the Property.name as a key on the underlying > JavaScriptObject, there's no way to have a property on the UserRecord here > that refers to the firstName property. I could create a UserDetailsRecord > and model that as a Property of the UserRecord, but the details are not an > independent object - they don't have an "id" or a "version" either. > > Is my use case something that's intended to be supported? > > > On Wed, Jul 21, 2010 at 12:34 PM, Ray Ryan <[email protected]> wrote: > >> It is definitely intended that the Editors (data bound widgets) will not >> require the RequestFactory. >> >> >> On Wed, Jul 21, 2010 at 6:38 AM, Thomas Broyer <[email protected]>wrote: >> >>> >>> >>> On 20 juil, 03:15, jarrod <[email protected]> wrote: >>> > I've spent some time looking through the new RequestFactory and >>> > ValueStore packages in GWT 2.1-M2. I am excited to see data binding >>> > and validation creeping into the core GWT code. However, I have a bit >>> > of a concern that the current implementation is too specific to JPA- >>> > based applications. >>> > >>> > Will it be possible to take advantage of the upcoming data-aware >>> > widgets without using RequestFactory? >>> >>> Which data-aware widgets are you thinking about? >>> >>> If it's the Cell-based widgets, then yes, absolutely; and without >>> ValueStore either. >>> >>> If you're talking about EditorSupport, then it looks to me there's no >>> dependency over RequestFactory either, only on DeltaValueStore, which >>> is an interface so you're not bound to a specific implementation. >>> AbstractRecordEditActivity has a dependency on RequestFactory, but >>> it's just a "helper base class"; you can use EditorSupport within any >>> view that implements RecordEditView, independently of >>> AbstractRecordEditActivity. >>> Last, but not least, AbstractRecordEditActivity has a dependency on >>> RequestFactory only to retrieve a ValueStore/DeltaValueStore and make >>> a syncRequest in the end in saveClicked; and again, RequestFactory is >>> "just an interface", so you could provide your own implementation and >>> you could then use AbstractRecordEditFactory if you liked. >>> Sure it'd be a bit of work, but it seems to me it's possible. >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > > > -- > ~jj > -- ~jj -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
