Thera are another project that implement data binding using
reflection.
http://code.google.com/p/gwt-model/
I think that the reflection way is the more clean solution.
Regards.
On Nov 18, 1:53 am, Rogerio <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I have a few ideas/requirements for a GWT data binding API. Such a
> solution would hopefully allow for a reduction of literally tens of
> thousands of lines of Java code that we currently have to write and
> maintain for manual data management, in the large web app I currently
> help develop and maintain (it contains about 200 GWT modules, and
> keeps growing).
>
> Ok, so here are the requirements:
>
> R1) Allow the binding from GWT widgets to an arbitrary server-side
> domain model (usually POJOs persisted through Hibernate/JPA), and vice-
> versa, from such objects to GWT widgets. An important part of this is
> that the domain classes should not need to be translatable to
> JavaScript through the GWT compiler.
> R2) All of the standard GWT widgets should be supported, while custom
> widgets could be supported by implementing some new interface.
> R3) The data binding meta-data should be provided declaratively,
> preferentially through Java 5 annotations.
> R4) There should be a way to have arbitrary methods in server-side
> business service classes (usually not translatable to JavaScript) be
> automatically called in response to a GWT RPC call. The arguments to
> such a method call would be obtained from bound widgets. The return
> value should be automatically encoded for transmission to the client
> side, and applied to the relevant bound widgets.
>
> Some ideas for the solution/implementation:
>
> S1) Define a set of Java 5 annotations for data binding, to be applied
> to fields of GWT widget types. For example, an annotation like @BoundTo
> ("Person#name").
> S2) A GWT Generator would read (using Reflection) the annotations from
> a client side class (usually a subclass of Panel containing several
> fields of various widget types, and annotated with the data binding
> annotations). It would then generate a class implementing the
> interface specified in the call to <code>GWT.create</code>. This call
> would be responsible for extracting current values from bound widgets,
> and also setting such values from an internal data structure used for
> transporting bound data over GWT RPC.
> S3) A central servlet would be used for all the client-side GWT
> RemoteService's, to receive the data structure containing values from
> bound widgets, and convert such data into a server-side domain object
> graph, which can then be passed in one or more arguments to a bound
> service method. This servlet would also be responsible for the other
> direction, converting the return value of the service method into the
> data structure defined by S2's Generator.
> S4) Coupled to the servlet of S3, there would be a data binding aware
> implementation of the user-defined RemoteService, able to apply the
> data structure returning from the server-side to a set of bound
> widgets.
>
> I hope this doesn't sound too crazy... The ultimate goal is to avoid
> the need to have lots of code in use case-specific RemoteService
> implementations dedicated solely to data conversion between UI-
> specific DTOs and business entities. Today this is biggest pain point
> in our use of GWT.
>
> Regards,
>
> Rogerio
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
