Re: onLoad method of Composite is not called.

[Jens]

The LoadEvent is a native browser event that will be fired once the browser 
has downloaded some resources. So it does not apply to a GWT widget. But 
every GWT widget (and thus Composite as well) has a protected onLoad / 
onUnload method that you can override to execute code once the widget has 
been attached/detached to/from the DOM.

-- J.

-- 
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+unsubscr...@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.

onLoad method of Composite is not called.

[Azade Khaladj]

Hello all,

I have a class that extends Composite. I want to do some action when the 
component is loaded. The class implements the HasLoadHandlers and a 
LoadHandler is defined and added to the component.


The problem is that the onLoad method is never called.

Am I missing something?

Thanks

-- 
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+unsubscr...@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.

Re: GWT RPC in GWT 3.0+

[Daniel Kurka]

I summed up what I think about GWT RPC and it's future here:
http://blog.daniel-kurka.de/2016/07/gwt-rpcs-future.html

On Thu, Jul 14, 2016 at 12:01 AM JonL  wrote:

> While I agree that it could theoretically work with annotations,
> annotations require access to code, so for things you have no control over,
> you either would need to implement custom serialization anyways, or use the
> GWT serialization.
>
> I personally think there are optimizations to be had in the serialization
> policy generator that would prevent that whole classpath rescan issue, but
> I haven't had a chance to look into the code.
>
> If we were to use annotations, I think it would be better to use
> annotations on the RPC mechanism.
>
> On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
>
>>
>>
>> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>
>
>>> On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
>>> >
>>> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT
>>> object serialization has been plugged into the atmosphere (realtime
>>> communication/websockets) GWT extension. It would be useful to know if we
>>> should migrate away from the GWT serialization and towards JSON.
>>>
>>> It's the serialisation that's the problem, so it will be gone in 3.0.
>>> JSON is a good choice. (I'm moving that way)
>>>
>>
>> The actual problem is not serialization per se, it is that the RPC
>> generator scans the whole classpath for subclasses of transferred classes
>> to generate their specific ser/deser code (taking into account their
>> CustomFieldSerializer if one exists).
>> RPC (thus probably Atmosphere) could be made to work (as annotation
>> processors) if they use another mechanism to determine what can be
>> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
>> I believe Daniel Kurka said something along those lines a year ago when
>> first talking about those changes. The logical next question is: is there
>> anyone willing to make those changes and continue to maintain GWT-RPC? The
>> answer seemed to be (have been?) "at least that won't be Google", and this
>> is why people start to "panic". That does not mean RPC will be gone (that
>> doesn't mean it'll still be there either).
>> But let's concentrate on 2.8 for now.
>>
> --
> 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+unsubscr...@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+unsubscr...@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.

Re: GWT RPC in GWT 3.0+

[JonL]

While I agree that it could theoretically work with annotations, 
annotations require access to code, so for things you have no control over, 
you either would need to implement custom serialization anyways, or use the 
GWT serialization.

I personally think there are optimizations to be had in the serialization 
policy generator that would prevent that whole classpath rescan issue, but 
I haven't had a chance to look into the code.

If we were to use annotations, I think it would be better to use 
annotations on the RPC mechanism.

On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
>
>
>
> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>
>>
>> On 13 Jul 2016 9:17 a.m., "Kay Pac"  
>> wrote:
>> >
>> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT object 
>> serialization has been plugged into the atmosphere (realtime 
>> communication/websockets) GWT extension. It would be useful to know if we 
>> should migrate away from the GWT serialization and towards JSON.
>>
>> It's the serialisation that's the problem, so it will be gone in 3.0. 
>> JSON is a good choice. (I'm moving that way)
>>
>
> The actual problem is not serialization per se, it is that the RPC 
> generator scans the whole classpath for subclasses of transferred classes 
> to generate their specific ser/deser code (taking into account their 
> CustomFieldSerializer if one exists).
> RPC (thus probably Atmosphere) could be made to work (as annotation 
> processors) if they use another mechanism to determine what can be 
> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
> I believe Daniel Kurka said something along those lines a year ago when 
> first talking about those changes. The logical next question is: is there 
> anyone willing to make those changes and continue to maintain GWT-RPC? The 
> answer seemed to be (have been?) "at least that won't be Google", and this 
> is why people start to "panic". That does not mean RPC will be gone (that 
> doesn't mean it'll still be there either).
> But let's concentrate on 2.8 for now.
>

-- 
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+unsubscr...@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.

GWT 2.8 last call & help with testing

[Michael Joyner]

  
  
FROM: 'Daniel Kurka'
  google-web-toolkit-contribut...@googlegroups.com
  
  Hi all,
  
  
  the last patch that is needed for 2.8 (https://gwt-review.googlesource.com/15193)
is about to land.
  
  
  I will cut the release candidate on Friday morning (MTV
time). This means that we need one clean build before hand in
Jenkins. So we will be blocking master from any more patches
starting tomorrow morning MTV time.
  Anything that is not relevant
  to the GWT 2.8 release will have to wait until 2.8.0 final (or
  even slightly longer if we anticipate a 2.8.1).
  
  
  
  We also need someone to coordinate testing on the open source
side as well as tester to do the actual testing.
  Let me know if you want to take over coordination or testing
and I will help you get started.
  
  
  -Daniel
  
  
  


  




-- 
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+unsubscr...@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.

[gwt-contrib] GWT 2.8 last call & help with testing

[Thomas Broyer]

We have a regression due to Java 8 changes in c.g.g.emul and generators, that 
affects at least AutoBeans. I'll try to work on fixes tomorrow, Friday 
otherwise. I'll file (or reopen) an issue for better tracking.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/ba0edb2d-8796-4a3e-a7e4-9bb2b480553b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

users of spring 4 gwt?

[Kay Pac]

Are there users of spring 4 gwt? I have a fork I am working to get 
published to maven central, and it would be nice to have a beta tester or 
two before I publish any artifacts.
Please let me know ! Original project URL is here: 
https://code.google.com/archive/p/spring4gwt/

I will publish my github URL when I have cleaned up my changes a bit!

Ciao,

Kay

-- 
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+unsubscr...@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.

Re: Spring4GWT fork published to github

[Kay Pac]

I forgot to include the github url for the project:

https://github.com/heptetgroup/spring4gwt


On Wednesday, July 13, 2016 at 10:59:44 AM UTC-7, Kay Pac wrote:
>
>
> Greetings,
>
> I forked Spring4Gwt which was on google code (
> https://code.google.com/archive/p/spring4gwt/) and published it to 
> github. I'm working to get it deployed to central but I just opened a 
> ticket. The fork isn't polished yet but I needed to publish it in order to 
> deploy to central.
>
> It would be nice to know if it works okay with peoples projects that 
> depend on this component, if there are any. Also, if you need a spring4gwt 
> type component, this is maintained whereas the google code one is not.
>
> Kay
>
>

-- 
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+unsubscr...@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.

Spring4GWT fork published to github

[Kay Pac]

Greetings,

I forked Spring4Gwt which was on google code 
(https://code.google.com/archive/p/spring4gwt/) and published it to github. 
I'm working to get it deployed to central but I just opened a ticket. The 
fork isn't polished yet but I needed to publish it in order to deploy to 
central.

It would be nice to know if it works okay with peoples projects that depend 
on this component, if there are any. Also, if you need a spring4gwt type 
component, this is maintained whereas the google code one is not.

Kay

-- 
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+unsubscr...@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.

Re: GWT RPC in GWT 3.0+

[Vassilis Virvilis]

just a side note on this

Although GWT-RPC is the easy low threshold for someone coming from the java
world SOAP, RMI (like me) two things that didn't fly well were:

1) GWT-RPC favors overspecifying the collection type. So it is better to
say ArrayList > List > Collection in your interfaces.

2) It was difficult to share server side code without including GWT
specific jars. So I had to create proxies for my SOAP services which was
problematic. With Resty-GWT at least my server code can have multiple types
of clients js, java, GWT etc.

   Vassilis

On Wed, Jul 13, 2016 at 7:23 PM, Thomas Broyer  wrote:

>
>
> On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>>
>>
>> On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
>> >
>> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT object
>> serialization has been plugged into the atmosphere (realtime
>> communication/websockets) GWT extension. It would be useful to know if we
>> should migrate away from the GWT serialization and towards JSON.
>>
>> It's the serialisation that's the problem, so it will be gone in 3.0.
>> JSON is a good choice. (I'm moving that way)
>>
>
> The actual problem is not serialization per se, it is that the RPC
> generator scans the whole classpath for subclasses of transferred classes
> to generate their specific ser/deser code (taking into account their
> CustomFieldSerializer if one exists).
> RPC (thus probably Atmosphere) could be made to work (as annotation
> processors) if they use another mechanism to determine what can be
> transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
> I believe Daniel Kurka said something along those lines a year ago when
> first talking about those changes. The logical next question is: is there
> anyone willing to make those changes and continue to maintain GWT-RPC? The
> answer seemed to be (have been?) "at least that won't be Google", and this
> is why people start to "panic". That does not mean RPC will be gone (that
> doesn't mean it'll still be there either).
> But let's concentrate on 2.8 for now.
>
> --
> 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+unsubscr...@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.
>



-- 
Vassilis Virvilis

-- 
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+unsubscr...@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.

Re: GWT RPC in GWT 3.0+

[Thomas Broyer]

On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:
>
>
> On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
> >
> > Will the gwt serialization mechanism used in GWT-RPC remain? GWT object 
> serialization has been plugged into the atmosphere (realtime 
> communication/websockets) GWT extension. It would be useful to know if we 
> should migrate away from the GWT serialization and towards JSON.
>
> It's the serialisation that's the problem, so it will be gone in 3.0. JSON 
> is a good choice. (I'm moving that way)
>

The actual problem is not serialization per se, it is that the RPC 
generator scans the whole classpath for subclasses of transferred classes 
to generate their specific ser/deser code (taking into account their 
CustomFieldSerializer if one exists).
RPC (thus probably Atmosphere) could be made to work (as annotation 
processors) if they use another mechanism to determine what can be 
transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).
I believe Daniel Kurka said something along those lines a year ago when 
first talking about those changes. The logical next question is: is there 
anyone willing to make those changes and continue to maintain GWT-RPC? The 
answer seemed to be (have been?) "at least that won't be Google", and this 
is why people start to "panic". That does not mean RPC will be gone (that 
doesn't mean it'll still be there either).
But let's concentrate on 2.8 for now.

-- 
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+unsubscr...@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.

Re: GWT RPC in GWT 3.0+

[Paul Robinson]

On 13 Jul 2016 9:17 a.m., "Kay Pac"  wrote:
>
> Will the gwt serialization mechanism used in GWT-RPC remain? GWT object
serialization has been plugged into the atmosphere (realtime
communication/websockets) GWT extension. It would be useful to know if we
should migrate away from the GWT serialization and towards JSON.

It's the serialisation that's the problem, so it will be gone in 3.0. JSON
is a good choice. (I'm moving that way)

Paul

-- 
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+unsubscr...@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.

[gwt-contrib] Re: ListAutoBean Iterator broken in current snapshot

[Thomas Broyer]

+cc Colin, Goktug

On Tuesday, July 12, 2016 at 12:48:58 PM UTC+2, Ross Drever wrote:
>
> Calling remove on an iterator from list within an request factory entity 
> proxy results in an UnsupportedOperationException.
>
> I have isolated it to commit 288cc03 Hide Java 8 interfaces methods to 
> generators. If I revert that commit it works properly. Seems like it is 
> picking up the wrong implementation of iterator.remove() when it generates 
> the proxies.
>
>
> Iterator iterator = someEntityProxy.getSomeList().iterator();
> iterator.next();
> iterator.remove(); //throws UnsupportedOperationException
>
>
Ah right; this is "actually" because Iterator#remove *became* a `default` 
method in Java 8:
https://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html#remove%28%29 
vs. https://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html#remove--
Really not sure what would be the best outcome here; but I think we need to 
re-investigate this decision of *hiding* default methods to generators, as 
there might be other similar cases either in the JDK or in third-party libs 
moving to Java 8.
In the short-term, we may want to maybe add an annotation to ask GWT to 
expose a `default` method as if it were 'abstract', only for 
backwards-compatibility for cases like this.
For AutoBeans specifically, one possibility would be to *not* generate the 
IteratorAutoBean and instead provide one that implements the remove() 
method; or to special-case java.util.Iterator to have the generated shim 
extend a provided base class.
In the medium/long-term, AutoBeans would probably be rewritten as an 
annotation processor anyway (which could also unify the JVM vs. GWT 
implementations, instead of using java.lang.reflect.Proxy in the JVM).

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5c9d5f02-3918-4fe5-a04b-07cfbc743212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GWT RPC in GWT 3.0+

[Kay Pac]

Will the gwt serialization mechanism used in GWT-RPC remain? GWT object 
serialization has been plugged into the atmosphere (realtime 
communication/websockets) GWT extension. It would be useful to know if we 
should migrate away from the GWT serialization and towards JSON.

On Thursday, July 7, 2016 at 3:53:18 AM UTC-7, Thomas Broyer wrote:
>
>
>
> On Thursday, July 7, 2016 at 11:54:11 AM UTC+2, Philippe Gonze wrote:
>>
>> Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the 
>> current GWT developpers,
>>
>> For me GWT is "Web development based on Java expertise, with practically 
>> no other technology implications". Extremely powerful and pleasant. Seems 
>> that GWT 3.0 is announced as "no more GWT":
>>
>
> From http://www.gwtproject.org/makinggwtbetter.html: “GWT’s mission is to 
> radically improve the web experience for users by enabling developers to 
> use existing Java tools to build no-compromise AJAX for any modern browser.”
> Also pay attention to what GWT is NOT about.
> GWT 3.0 as described in this thread would still follow this mission 
> statement.
> Providing tools to do RPC, even if differently than today, would still 
> follow the design axioms. But RPC in itself is about making compromises on 
> AJAX use ("obscure" payload, asymmetrical payload because they were not 
> meant to be parsed by the same tools and in the same environments, 
> everything sent to the URLs, etc. all of this make it impractical at best 
> to use RPC along with, for example, service workers), and that will 
> eventually degrade the web experience for users. Moving away from RPC is 
> actually trading development "convenience" for a better user experience.
>  
>
>> Our plan will probably to stay with 2.8...
>>
>
> And this is exactly why GWT 2.x and GWT 3 are expected to coexist for a 
> while.
>
>

-- 
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+unsubscr...@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.

Re: Cascading GWT Application ?

[Pierre Mineaud]

The official GWT's example Ruxit is really looking at what I want to do. 
- A Menu always shown. On the left, on the top... who cares...
- An url changing when I change page
- An "Module Loader" on the right side of the page to charge my differents 
page.

I do not want using iframe cause I want to be able to log my user on this 
menu. That said I have to do some server / session works in that iframe and 
by my experience, there is always something wrong when using it.
To be honest, that's one of the reason we quit meteor :)

-- 
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+unsubscr...@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.