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: "b...@jones.com"
}
}
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 <rj...@google.com> 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 <t.bro...@gmail.com> wrote:
>
>>
>>
>> On 20 juil, 03:15, jarrod <jarrod.carl...@gmail.com> 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
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
