RequestFactory without creating proxies? Anyone else reminded of J2EE early days?

[Karthik Abram]

We have a significant sized app built using GWT 2.0 and we have simple
Command pattern based abstraction for sending entities back and forth
between the server and client. The new RequestFactory while
interesting seems to require too much "scaffolding" interfaces and
classes.

- Why should I create duplicate proxy interfaces? Can't I just reuse the entity?
- The requirement that the service implement the RequestContext
interface but not really - leads to poor code maintainability as one
cannot simply rename methods taking advantage of IDE features.
- The 2.1 idea of have DAO methods in entities? What was the thinking
here? Seems 2.1.1 is addressing it.
- The requirement to have findEntity() on the entity itself - leads to
very poor separation of concerns.
- The requirement to have getVersion() - well, what if I don't want my
entity to be versionable? Why am I being forced here? This is another
example of forcing the framework user to write code to make the
framework do its work.
- The requirement to explicitly edit() an entity (again, just so the
framework can figure out changes) is burdensome.

My concern now is that other libraries (e.g. Ext GWT) will adopt this
forcing theRequestFactory upon everyone. How far does 2.1.1 go in
alleviating the above? I think I'm going to stick with the simple
GWT-RPC. Hopefully that is not going away anytime soon.

[tshalif]

I am not smart enough for requestFacyory.

[Thomas Broyer]

On Tuesday, December 14, 2010 1:14:30 PM UTC+1, kabram wrote:

We have a significant sized app built using GWT 2.0 and we have simple
Command pattern based abstraction for sending entities back and forth
between the server and client. The new RequestFactory while
interesting seems to require too much "scaffolding" interfaces and
classes.

- Why should I create duplicate proxy interfaces? Can't I just reuse the entity?

No.

One of the goal of RF is to completely separate server code from client code, so that a) you can use whatever you want on the server side (including directly in your entities) and b) the client-side can be optimized at will because it's enterily generated by GWT.

See https://wave.google.com/wave/waveref/googlewave.com/w+WU4iAICkI

- The requirement that the service implement the RequestContext
interface but not really - leads to poor code maintainability as one
cannot simply rename methods taking advantage of IDE features.

See http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/requestfactory/server/RequestFactoryInterfaceValidator.html

You can use it as a command-line tool to validate your client-side interface against your server-side implementations.

I believe the next version of the Google Plugin for Eclipse (or at least a future version) will integrate it, just like it validates the sync and async interfaces of GWT-RPC (which suffer from the exact same issue).

 

- The 2.1 idea of have DAO methods in entities?

Not necessarily. But then methods *have* to be static. 

What was the thinking here?

AFAIK, Spring Roo generating static methods on entities, similar to Rails' ActiveRecord and the like (but Ruby allows monkey patching which makes testing and mocks possible, something that a statically typed language like Java cannot do)

Seems 2.1.1 is addressing it.

Yes!

 

- The requirement to have findEntity() on the entity itself - leads to
very poor separation of concerns.

See above, but 2.1.1 addresses that one too.

 

- The requirement to have getVersion() - well, what if I don't want my
entity to be versionable? Why am I being forced here? This is another
example of forcing the framework user to write code to make the
framework do its work.

Versions are necessary for the "update" mechanism. The constraint was initially relaxed in 2.1.1 but re-added last week: http://code.google.com/p/google-web-toolkit/source/detail?r=9381

 

- The requirement to explicitly edit() an entity (again, just so the
framework can figure out changes) is burdensome.

It makes you intents clear. Your proxies are there so you can communicate with the server, so edit()ing a proxy is kind of like creating a "request builder". You then add an "invocation" (service method call) and fire() the request. And everything is "magically" replayed on the server.

 

My concern now is that other libraries (e.g. Ext GWT) will adopt this
forcing theRequestFactory upon everyone. How far does 2.1.1 go in
alleviating the above? I think I'm going to stick with the simple
GWT-RPC. Hopefully that is not going away anytime soon.

The new Google Groups is using GWT-RPC, so I believe it's there to stay!

 

[Daniel Simons]

I have a project that utilizes RequestFactory and works in 2.1 but not in 2.1.1.  Is there an example out there making use of the 2.1.1 RequestFactory improvements?    

 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Karthik Abram]

Thomas,
Thanks for your response. Here are a few follow ups:

1) The idea of forcing separation between client and server code so
that GWT can generate client code is perhaps too restrictive. We have
a lot of getter methods with intelligence or decoration of the
returned value. Currently, we know this will work on the client and
server side. But with RF, I have to move that logic elsewhere. Keeping
the entities common and forcing them to be GWT actually has a nice
side-effect - it forces you to keep your entities clear of useless
dependencies.

2) Its nice that a command line validator is provided, but that just
means more build time checks for something that Java could natively
do. So the advantages of incremental compilation via Eclipse/IDEA etc
are gone. Also, there will be additional delays before this trickles
down to maven plugins and other artifacts.
Note: With the command pattern, my async interface only has one method
- Result execute(Action a); that is generified so I never have to
worry about it (and it is burried in common-library). Actions and
Results get associated by simply being defined as spring beans and
everything works like magic.

[Brian Reilly]

What I was hoping for in 2.1.1 is something with, I suppose, the
functionality of AutoBean and the simplicity of use of @ProxyFor.
Unless I'm missing something about AutoBean, it looks too cumbersome
to use outside of a tool that does code generation.

In my case, I don't need a proxy for my entities. I just need
something to help make it easier to create and maintain appropriate
DTOs that I can then use with GWT-RPC. I don't need the complexity of
something trying to manage DAO methods, entity versions, etc. and the
various requirements that puts on the entities. The proxy idea is fine
for CRUD applications, but not as useful for presenting an entity with
some actions that the user can perform that don't necessarily change
the entity.

At one point, I wrote a code generator that would use reflection to
find bean properties and generate DTOs with conversion utility
classes. I may have to revisit that and incorporate some inspiration
from @ProxyFor.

-Brian

[Thomas Broyer]

On Tuesday, December 14, 2010 4:38:54 PM UTC+1, Brian Reilly wrote:

What I was hoping for in 2.1.1 is something with, I suppose, the
functionality of AutoBean and the simplicity of use of @ProxyFor.
Unless I'm missing something about AutoBean, it looks too cumbersome
to use outside of a tool that does code generation.

In my case, I don't need a proxy for my entities. I just need
something to help make it easier to create and maintain appropriate
DTOs that I can then use with GWT-RPC. I don't need the complexity of
something trying to manage DAO methods, entity versions, etc. and the
various requirements that puts on the entities. The proxy idea is fine
for CRUD applications, but not as useful for presenting an entity with
some actions that the user can perform that don't necessarily change
the entity.

Couldn't you then use a ValueProxy instead of EntityProxy?

[Brian Reilly]

Ahh, good point. Perhaps ValueProxy is what I'm looking for. I noticed
mention of it in the RequestFactory_2_1_1 docs, but I didn't realize
that it might be used that way. I'll have to give it a try. Thanks.

-Brian