Hi, a side note. IMO you should not start using request factory. It is a pretty awesome lib which solves a lot of problem which probably you don't have with the cost of a complexity which will make you ask a lot of doubt's like this one for a long time. IMO if you want a API focused in your model, with type inheritance, generics, etc. you should use GWT RPC. If you want a more message payloads focused API, you should use some REST lib like RestyGWT (mature, full java type support) or AutoREST (new, though to be used with JsInterop, do not support inheritance or other fancy things).
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Hehe this is not a bad thing! Just means that now exists simpler solutions. I personally think that RF keeps track of object (the entity id) which add really a lot of complexity, at this point I think that the lib should include some kind of storage with remote synchronization because if not, the complexity just makes thing difficult with the "only" benefit of reducing transfer size. I also don't like the obscure encoding, not easy to debug, not compatible with changes in the model (sometimes). IMO RF was promising, but it's complexity do not justify its benefits. But the best thing to do is always an small project, and test each strategy, RF, RPC and Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is done almost everything in the browser natively without different code for different browsers.
--
Hehe this is not a bad thing! Just means that now exists simpler solutions. I personally think that RF keeps track of object (the entity id) which add really a lot of complexity, at this point I think that the lib should include some kind of storage with remote synchronization because if not, the complexity just makes thing difficult with the "only" benefit of reducing transfer size. I also don't like the obscure encoding, not easy to debug, not compatible with changes in the model (sometimes). IMO RF was promising, but it's complexity do not justify its benefits. But the best thing to do is always an small project, and test each strategy, RF, RPC and Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is done almost everything in the browser natively without different code for different browsers.
El jue., 5 ene. 2017 15:01, salk31 <sal...@gmail.com> escribió:
:(--
On Monday, December 26, 2016 at 2:11:35 PM UTC, Thomas Broyer wrote:+1 Do not start learning/using RequestFactory (or even GWT RPC I'd say). Learn JsInterop and use json-based http APIs.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
I migrated everything from RPC to RF. Thinking it was a better alternative to 3rd party libs and could be sustainable when 3.0 arrives was I wrong in this thinking?Regards
On Fri, Jan 6, 2017 at 7:10 AM, Ignacio Baca Moreno-Torres <ign...@bacamt.com> wrote:
Hehe this is not a bad thing! Just means that now exists simpler solutions. I personally think that RF keeps track of object (the entity id) which add really a lot of complexity, at this point I think that the lib should include some kind of storage with remote synchronization because if not, the complexity just makes thing difficult with the "only" benefit of reducing transfer size. I also don't like the obscure encoding, not easy to debug, not compatible with changes in the model (sometimes). IMO RF was promising, but it's complexity do not justify its benefits. But the best thing to do is always an small project, and test each strategy, RF, RPC and Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is done almost everything in the browser natively without different code for different browsers.
El jue., 5 ene. 2017 15:01, salk31 <sal...@gmail.com> escribió:
:(--
On Monday, December 26, 2016 at 2:11:35 PM UTC, Thomas Broyer wrote:+1 Do not start learning/using RequestFactory (or even GWT RPC I'd say). Learn JsInterop and use json-based http APIs.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Hehe this is not a bad thing! Just means that now exists simpler solutions. I personally think that RF keeps track of object (the entity id) which add really a lot of complexity, at this point I think that the lib should include some kind of storage with remote synchronization because if not, the complexity just makes thing difficult with the "only" benefit of reducing transfer size.
I also don't like the obscure encoding,
not easy to debug, not compatible with changes in the model (sometimes). IMO RF was promising, but it's complexity do not justify its benefits.
But the best thing to do is always an small project, and test each strategy, RF, RPC and Rest+Jackson, Rest+JsInterop. The last one has de benefit nowadays than is done almost everything in the browser natively without different code for different browsers.
And who knows, maybe one day we'll finally have grpc-web ;-)
Salk31, please note that we are saying that if you are going to start learning RF right now, you better try other approach. But as you said, RF, editor framework, probably validations, ui binder, etc is a pretty good solution. You should note that this solution is not going to evolve anymore (I think), but this again might be a good thing because hasn't evolved in the last 4 years and it is still a good solution. Actually I stop using RF when I stopped using editor framework. Both together is a good option.
And who knows, maybe one day we'll finally have grpc-web ;-)Oh please! +1
--
Salk31, please note that we are saying that if you are going to start learning RF right now, you better try other approach. But as you said, RF, editor framework, probably validations, ui binder, etc is a pretty good solution. You should note that this solution is not going to evolve anymore (I think), but this again might be a good thing because hasn't evolved in the last 4 years and it is still a good solution. Actually I stop using RF when I stopped using editor framework. Both together is a good option.
El vie., 6 ene. 2017 15:54, Jens <jens.ne...@gmail.com> escribió:
And who knows, maybe one day we'll finally have grpc-web ;-)Oh please! +1--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.