We're working on GWT 2.1.1 right now, largely to address a lot of RequestFactory shortcomings. I can't commit to a date other than "a lot faster than usual." The specifics are being tracked here:
http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 On Tue, Nov 9, 2010 at 11:41 AM, Jack Kennedy <jkenn...@skywaysoftware.com>wrote: > Ray, > > I am forwarding this note to the wider audience at your suggestion, thanks > again. > > For background, Skyway Software and Genuitec offer a product called > MyEclipse for Spring (ME4S) that offers a wizard based scaffolding feature > to generate Java applications built on reusable software components > utilizing a variety of inputs to the process including (RDBMS tables,Java > Beans, JPA entities, WSDL/Schema). > > Our current release support GWT 2.0.x and we are in the process of updating > our support to GWT 2.1. We are committed to utilizing the advances in 2.1 > since we are big fans of all of these improvements. > > We are facing a few challenges regarding the use of the RequestFactory > infrastructure with existing RDBMS tables and I wanted to be sure that we > understood the current restrictions as we would need to communicate those > restrictions to developers using our tools. > > If there are any opportunities to assist or contribute to GWT in support of > the following cases I would certainly be happy to help. > > Specific Challenges: > > - Tables without ID or Version fields would require modifications to > the schema and updates to all existing records > - The table must be updated to add the id and version fields (or > have the JPA provider auto add the new fields) > > Yes, this magic field requirements are pretty bad. If it helps, they don't have to be fields, just getter methods. Relaxing the version requirement is on the 2.1.1 list, but I'm not sure if the plan is to make it completely optional or just relax its type. I'm also not sure if we'll be able to get more flexible about the getId requirement. Perhaps the service layer will provide enough flexibility for both of these issues? > > - This would also mean that the existing data in the DB would need to > be updated to so that each record has the version field filled in with a > default value > - The newly added ID value for each existing record in the table > would also have to be updated with a value that is unique for each > record > - Tables that use multiple existing fields for unique identification of > each record are not supported > - Many existing RDBM tables use multiple fields in their keys to > uniquely identify a record > - In our GWT 2.0.x support, we generate a Key object that wraps 1 - > M fields based on the table design and pass this object from Client to > Server > - What is the position of the RequestFactory / JSONRequest handling > layer here? To push a secondary identification field (id) and persist > it > along side the other primary key data in the db, or to enable composite > keys > in the GWT layers in the future? > > In 2.1, the easiest workaround would be to provide a String getId() method that serializes your compound key, and a static finder method that deserializes it. > > - Tables with an existing field named 'id' that is a String can not > have the id value passed from the client on create > - The JSONRequestProcessor has a method to get the String value for > the "create" operation that returns null by default > - If the value of the ID was passed in from the client it would be > ignored and not bound to a newly created Entity because the JSONRequest > handling assumes the ID fields to be auto generated > > I think that's a use case that just didn't occur to us. We've consistently treated ids as things that are generated by the server. Do you mind logging it in the GWT issue tracker? How realistic a use case is it? For that matter, it may have been inadvertently fixed by the 2.1.1 work already, there has been some drastic re-writing. > > > I have included a project that was built using Roo that demonstrates the > results that are received when you combine the Roo db reverse engineering > capability with the Roo GWT generation when the table was defined with no ID > field and with a composite primary key as an illustration of the composite > primary key issue. > > Since we are working to release this update in the near term, I would need > to warn or restrict our users from scaffolding from tables that do not meet > the requirements as proposed by the RequestFactory which I fear is likely a > relatively large percentage of existing tables. I plan on offering a > document that can help them to understand the manual steps they would need > to undertake, and the trade offs that they would need to consider, but I > want to be sure that my view is correct. > > Thanks, > Jack Kennedy > V.P. Engineering > Skyway Software > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
