+1: RPC is one of GWT's strong suits. Haven't seen another web-oriented
(de-)serialization mechanism that handles polymophism, generics and bidi
relations without config or pain. Doesn't litter your domain classes with
non-standard annotations or dependencies. AnyGWT 3.0 alternative should be
Maybe there is effectively going to be a fork? So if the interest was there
could be GWT 2.9 - GWT 2.123
I think that might represent the truth that there is one user base that
wants to build Java apps that happen to run in a browser vs users who are
working on products that need to squeeze
I'm puzzled as to what the disadvantages could be of GWT Widgets. They
are, after all, translated to efficient JavaScript and allow full use of
the browser. I can see that some developers might want to integrate with
JavaScript frameworks, but others, like me, start writing applications in
pure
I can see the logic of GWT 3.0. The browser has evolved a lot since GWT was
first designed. Back in those days every browser had significant quirks and
the lowest common denominator was very low. In 2015 there is less reason
for a big layer between domain code and the browser. I think the same
+1
I think the division of GWT-compiler and GWT-widgets is the right thing to
do. The web-platform is moving fast and to GWT has to adopt to stay
relevant.
Webcomponents have the potential to become the new widgets and the new
JSInterops will make it quite easy to consume webcomponents that are
If you just want to run java apps in the browser there are solutions out
thtere
Free: http://www.webswing.org
Paying: http://www.creamtec.com/products/ajaxswing/overview.html
Now if you want to run create webapps then it is another matter. For me the
web stack is a crazy platform. But still since
On Monday, October 19, 2015 at 12:22:19 PM UTC+2, Jens wrote:
>
>
>> * Stick with 2.x and risk being left behind and the project becoming
>> neglected due to split effort.
>>
>
> You are not behind when using 2.x:
>
> GWT 2 = GWT 2.x Compiler + JsInterop + Elemental 1 + Elemental 2 when
>
Somehow people seem to forget that they don't have to migrate at all if its
not profitable. Just stay on GWT 2.8.x and only start new projects with new
technology. There will be plenty of companies that have huge apps that will
not be rewritten anytime soon (if at all) so IMHO GWT 2.8.x will
I'm trying to understand my options.
* Stick with 2.x and risk being left behind and the project becoming
neglected due to split effort.
* Try to migrate to 3.x and possibly throw away a big investment.
* Look to move to something other than GWT.
Obviously we will also be taking action to
>
>
> * Stick with 2.x and risk being left behind and the project becoming
> neglected due to split effort.
>
You are not behind when using 2.x:
GWT 2 = GWT 2.x Compiler + JsInterop + Elemental 1 + Elemental 2 when
released + all current GWT SDK code + all GWT libraries.
GWT 3 = J2CL +
Actually what makes sense for me in an after split era is
* compile with the newest GWT 3.5, 4, 5 to pick up new features
* link with legacy but compatible gwt-widgets until I can gradually get rid
of them - or not.
This way I can migrate step by step my application (widget per widget) and
stay
I'm eager for GWT 2.8 because of Lambda support, but I can't see that my
company will ever use GWT 3.0 if what you write is true. We have products
that make substantial use of GWT Widgets, and there is no prospect of
re-writing to some other system. GWT without the Widgets just isn't GWT -
Thanks Thomas,
For my own use I'm going to keep a list of what I think I
know http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections
welcome.
I can see why they want to reduce the scope of GWT and integrate (not
build) but is such a high quality complete package in 2.7 it is a
Is there a guide somewhere of migration path to 3.0 per feature?
I've been trying to follow these threads but I'm still not sure on the
future of things like RequestFactory and Editor. They heavily depend on
GWT.create and the latter depends on Widgets, are they really going away?
We have a
I think nobody has such information yet; not even Google who are pushing
for the change. They do have many apps that use widgets and RPC today
(example: Google Groups, the exact app I'm typing this message into) and
will need to come up with a migration path for those apps too.
On Friday,
It was process but we ported everything to the low level
RequestBuildner.and json. Now we have just one timer in the UI a huge
reduction from the async nature of RPC.
In our situation we render everything out of a DataDictionary on the
server side and use a Frame for the results,
The GUI is
Where can I read that GWT RPC and widget system will be dropped with GWT 3.0?
Is there a presentation / doc online?
And what does it mean that GWT.create will be dropped?
And: really dropped or set as deprecated?
--
You received this message because you are subscribed to the Google Groups
Where can I read that GWT RPC and widget system will be dropped with GWT
3.0? Is there a presentation / doc online?
And what does it mean that GWT.create will be dropped?
And: really dropped or set as deprecated?
GWT 3.0 drops support for JSNI and GWT.create(). JSNI will be replaced
Thank you for your answer Jens. So much GWT solutions build on widget system so
I think there will be a port/solution (thinking about the new GWT Material
Project which was startend a view months ago...).
@Ed: so you use a REST service on backend? Seems also for us a good solution
but
Both gwt-jackson (https://github.com/nmorel/gwt-jackson/wiki/Type-support)
and restygwt (resty-gwt.github.io/documentation/restygwt-user-guide.html)
supports polymorphism (and gwt-jackson in addition generics)!
gwt-rpc is nice at the beginning (fast learning curve), but hurts later on
-
is dagger + ... an alternative to gwt-rpc?
Dagger is an injection library like google-gin with the difference that it
uses annotation processors instead of GWT.create(). It has nothing to do
with gwt-rpc.
--
You received this message because you are subscribed to the Google Groups
I cannot disagree more. Restful, as far as I understand, does not replace
gwt-rpc as it does not provide polymorphism. It might be an issue with the
current implementations I had a look - can someone tell me some
implementation that can handle object graphs and polymorphism as gwt-rpc
does?
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Well the internally used XMLHttpRequest / Timer classes would need to be
ported to JsInterop of course because they use JSNI.
There are some general to consider with RequestBuilder as well:
- It is quite low level
-
@jens
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Best Regards
Ed
On Mon, Jun 29, 2015 at 1:43 PM, Ed ej19...@gmail.com wrote:
Thanks Jens, Great response, gives our devs something to learn.
On Mon, Jun 29, 2015 at 12:55 PM, Jens jens.nehlme...@gmail.com
In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your domain model as resources
(might lead to a clean API).
I guess once Elemental 2.0 is released (AFAIK along the lines with GWT 3.0)
you could
@jens @umit
Thank you very much for this insight.
Best Regards
Ed
On Tue, Jun 30, 2015 at 9:44 AM, Ümit Seren uemit.se...@gmail.com wrote:
In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your
If I wanted to start now for the the GWT 3.0 release, what would be the
best mechanism to replace:
1. GWT.create
2. RPC
We starting a refactor of existing code, and would like some foresight into
this matter.
Thanks
Ed
--
You received this message because you are subscribed to the Google
1. GWT.create
generate-with: Annotation processors
replace-with: Dagger 2.x + AutoFactory (assisted inject) for injection
and System.getProperty() to build the Dagger dependency graph based on your
deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt
Thanks Jens, Great response, gives our devs something to learn.
On Mon, Jun 29, 2015 at 12:55 PM, Jens jens.nehlme...@gmail.com wrote:
1. GWT.create
generate-with: Annotation processors
replace-with: Dagger 2.x + AutoFactory (assisted inject) for injection
and System.getProperty() to
29 matches
Mail list logo
