RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
I am not smart enough for requestFacyory. On 12月14日, 午後9:14, Karthik Abram karthik.ab...@gmail.com 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? - 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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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! -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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? On Tue, Dec 14, 2010 at 8:05 AM, Thomas Broyer t.bro...@gmail.com wrote: 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! -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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. On Tue, Dec 14, 2010 at 9:18 AM, Daniel Simons daniel.simo...@gmail.com wrote: 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? On Tue, Dec 14, 2010 at 8:05 AM, Thomas Broyer t.bro...@gmail.com wrote: 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! -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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 On Tue, Dec 14, 2010 at 9:05 AM, Thomas Broyer t.bro...@gmail.com wrote: 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! -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory without creating proxies? Anyone else reminded of J2EE early days?
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 On Tue, Dec 14, 2010 at 10:55 AM, Thomas Broyer t.bro...@gmail.com wrote: 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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
