Well needless to say, I'm looking forward to it. :-) On Jul 26, 2010, at 12:29 PM, Ray Ryan <[email protected]> wrote:
> 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 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
