Cell Tables are already all set for you, they're completely independent of RequestFactory et al.
We're in the midst of a rewrite of EditorSupport that will make it independent of ValueStore et al, or at least easily severable. In parallel, we're working to pull ValueStore and Record out of the public api. Thanks for the $0.02, I couldn't agree more. rjrjr On Sat, Jul 24, 2010 at 7:28 PM, Jarrod Carlson <[email protected]>wrote: > 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 > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
