Re: [gwt-contrib] Problem with JsInterop

[Arnaud TOURNIER]

Hi Collin,
Thanks for your answer, I understand now, I was only focusing on my problem
and forgot the JS to Java way. As you say, something cool would be to be
able to say to JsInterop that the interface will only be used in the Java
to JS way...
Thanks!

Le sam. 27 août 2016 16:13, Colin Alworth  a écrit :

> Part of the problem would come from figuring out how to call from JS back
> into Java - if you called resolve(null), was null a T or was null a
> Promise? And from JS, how could you typecheck to figure out whether to call
> the resolve_1(value) or resolve_2(promise)?
>
> Its also possible in JS to call with too many arguments, and if you call
> with not enough, they get a null value, so we'll have a resolve_0() in
> there too - but if the wrong number of arguments are there, which do you
> invoke?
>
> So, rather than JsInterop being a method lookup layer to translate to Java
> method call semantics, JsInterop uses JS semantics and lets you use them
> from Java. Just as you would write your resolve method in JS, you should
> write it in Java - take the object, and based on the value, decide what to
> do with it.
>
> Now I realize that this doesn't directly apply to your case, since you
> want to do it the other way around - pass an object implemented in JS into
> Java and interact with it there, but JsInterop provides functionality to
> work in both directions, and I'm not certain how you could tell JsInterop
> that you will never implement an interface in Java, or if that is
> functionality that we want. Instead, you could have a single method
> resolve(Object), and let JS sort it out, whether you call it with null, a
> value, or another promise.
>
> (Disclaimer, I'm not a JsInterop expect, but I'm trying to learn quickly.)
>
> On Sat, Aug 27, 2016 at 8:51 AM Arnaud TOURNIER  wrote:
>
>> Hi,
>>
>> I am playing with js Promises and maybe there's a problem with JsInterop
>> or i don't understand something.
>>
>> When wrapping the promises with JsInterop, i come to define the Resolver
>> interface which represents the resolving callback that is given when
>> constructing a promise. In Javascript it is a function and not an object,
>> so the interface has the @JsFunction annotation.
>>
>> Here is the Resolver interface (inspired from the TypeScript definition
>> of Promises...) :
>>
>> @JsFunction
>> @FunctionalInterface
>> public interface Resolver
>> {
>> void resolve( T value );
>> }
>>
>> Since the Javascript "resolve" function can be called without parameters
>> and also with a Promise instead of a value, i would like to make those
>> versions available in the interface.
>>
>> But the @JsFunction annotation prevents from having this :
>>
>> @JsFunction
>> public interface Resolver
>> {
>> void resolve();
>>
>> void resolve( T value );
>>
>> void resolve( Promise value );
>> }
>>
>> That's because it allows only one method in the annotated interface.
>>
>> That is what i don't understand : AFAIK, the gwt compiler has to call the
>> same function in the same way for the three declared methods (because of
>> the semantic of the @JsFunction annotation), just changing the calling
>> parameters. So i don't understand why is there the limitation of having
>> only one method allowed in @JsFunction interfaces... If it would it would
>> give even much power to JsInterop !
>>
>> Could you please bring light to my misunderstanding ?
>>
>> Thanks !
>>
>> Arnaud
>>
>> --
>>
> 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/15705e1b-c1cf-46ec-add7-96d2b787f8fe%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Contributors" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit-contributors/pNmyrzkfPWo/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CADcXZMxQAj-TExK50id9AVKB36mWv8JnAW5f%2BK0Zg4%3D9SOi74A%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are 

Re: [gwt-contrib] Problem with JsInterop

[Colin Alworth]

Part of the problem would come from figuring out how to call from JS back
into Java - if you called resolve(null), was null a T or was null a
Promise? And from JS, how could you typecheck to figure out whether to call
the resolve_1(value) or resolve_2(promise)?

Its also possible in JS to call with too many arguments, and if you call
with not enough, they get a null value, so we'll have a resolve_0() in
there too - but if the wrong number of arguments are there, which do you
invoke?

So, rather than JsInterop being a method lookup layer to translate to Java
method call semantics, JsInterop uses JS semantics and lets you use them
from Java. Just as you would write your resolve method in JS, you should
write it in Java - take the object, and based on the value, decide what to
do with it.

Now I realize that this doesn't directly apply to your case, since you want
to do it the other way around - pass an object implemented in JS into Java
and interact with it there, but JsInterop provides functionality to work in
both directions, and I'm not certain how you could tell JsInterop that you
will never implement an interface in Java, or if that is functionality that
we want. Instead, you could have a single method resolve(Object), and let
JS sort it out, whether you call it with null, a value, or another promise.

(Disclaimer, I'm not a JsInterop expect, but I'm trying to learn quickly.)

On Sat, Aug 27, 2016 at 8:51 AM Arnaud TOURNIER  wrote:

> Hi,
>
> I am playing with js Promises and maybe there's a problem with JsInterop
> or i don't understand something.
>
> When wrapping the promises with JsInterop, i come to define the Resolver
> interface which represents the resolving callback that is given when
> constructing a promise. In Javascript it is a function and not an object,
> so the interface has the @JsFunction annotation.
>
> Here is the Resolver interface (inspired from the TypeScript definition of
> Promises...) :
>
> @JsFunction
> @FunctionalInterface
> public interface Resolver
> {
> void resolve( T value );
> }
>
> Since the Javascript "resolve" function can be called without parameters
> and also with a Promise instead of a value, i would like to make those
> versions available in the interface.
>
> But the @JsFunction annotation prevents from having this :
>
> @JsFunction
> public interface Resolver
> {
> void resolve();
>
> void resolve( T value );
>
> void resolve( Promise value );
> }
>
> That's because it allows only one method in the annotated interface.
>
> That is what i don't understand : AFAIK, the gwt compiler has to call the
> same function in the same way for the three declared methods (because of
> the semantic of the @JsFunction annotation), just changing the calling
> parameters. So i don't understand why is there the limitation of having
> only one method allowed in @JsFunction interfaces... If it would it would
> give even much power to JsInterop !
>
> Could you please bring light to my misunderstanding ?
>
> Thanks !
>
> Arnaud
>
> --
> 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/15705e1b-c1cf-46ec-add7-96d2b787f8fe%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CADcXZMxQAj-TExK50id9AVKB36mWv8JnAW5f%2BK0Zg4%3D9SOi74A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Problem with JsInterop

[Arnaud TOURNIER]

Hi,

I am playing with js Promises and maybe there's a problem with JsInterop or 
i don't understand something.

When wrapping the promises with JsInterop, i come to define the Resolver 
interface which represents the resolving callback that is given when 
constructing a promise. In Javascript it is a function and not an object, 
so the interface has the @JsFunction annotation.

Here is the Resolver interface (inspired from the TypeScript definition of 
Promises...) :

@JsFunction
@FunctionalInterface
public interface Resolver
{
void resolve( T value );
}

Since the Javascript "resolve" function can be called without parameters 
and also with a Promise instead of a value, i would like to make those 
versions available in the interface.

But the @JsFunction annotation prevents from having this :

@JsFunction
public interface Resolver
{
void resolve();

void resolve( T value );

void resolve( Promise value );
}

That's because it allows only one method in the annotated interface.

That is what i don't understand : AFAIK, the gwt compiler has to call the 
same function in the same way for the three declared methods (because of 
the semantic of the @JsFunction annotation), just changing the calling 
parameters. So i don't understand why is there the limitation of having 
only one method allowed in @JsFunction interfaces... If it would it would 
give even much power to JsInterop !

Could you please bring light to my misunderstanding ?

Thanks !

Arnaud

-- 
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/15705e1b-c1cf-46ec-add7-96d2b787f8fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Eclipse Code Server Launcher Icon

[Ignacio Baca Moreno-Torres]

Em... this is kind of related, some days ago I speak about this with manolo 
in gitter; currently the CodeServer use the standard nocache.js instead of 
the compile-on-refresh (actually uses the compile-on-refresh the first 
time, but subsequent compilations uses the standard one). And... does not 
makes more sense that the codeserver compilations always uses the 
compile-on-refresh nocache.js? I think that this is in general quite 
useful, but is even more useful for client only project so the codeserver 
serves all the resources (just need to move your index.html into a public 
folder like this 
https://github.com/ibaca/rxcanvas-gwt/blob/master/src/main/java/rxcanvas/public/index.html).
 
Hopefully this will promove using codeserver alone even more.

On Friday, August 26, 2016 at 5:34:28 PM UTC+2, JonL wrote:
>
> I guess I didn't word it correctly.  I think I am talking more of the 
> experience of running the CodeServer and the embedded Jetty Server serving 
> the app, in one shot utilizing the eclipse plugin has become synonymous in 
> my head with SDM.  Where as running the web app on an external server and 
> manually starting the CodeServer, I don't so much attribute to being 
> "super", but more "cumbersome" dev mode.  So I guess what I am trying to 
> say is that from the eclipse development perspective, utilizing the plugin, 
> there should always be a one shot command that starts up the CodeServer and 
> deploys the app for you and then maybe you start a browser using SDBG 
> Plugin, should remain the most cumbersome experience for utilizing the 
> plugin, by default.  
>
> I don't use the maven plugin, but I would guess by discussion that there 
> is a similar experience where the maven plugin starts up the codeserver and 
> uses DevMode plugin for deployment.  
>
> So ultimately, I think, unless there is a better way, across all these 
> plugins to provide a similar getting started experience where you run one 
> command to start the CodeServer and a deployment server, my vote, if it 
> counts for anything, would be to keep c.g.g.dev.DevMode with only SDM and 
> refactor it possibly so that its clear to what it is and separate it, 
> cognitively, from the old classic DevMode utilizing the browser plugin.
>
> On Friday, August 26, 2016 at 7:58:24 AM UTC-7, Thomas Broyer wrote:
>>
>>
>>
>> On Friday, August 26, 2016 at 4:30:48 PM UTC+2, JonL wrote:
>>>
>>> I have always considered the deprecation of "DevMode" to mean the 
>>> deprecation of the "HostedMode"/GWT Dev Mode plugin combo and that SDM was 
>>> the non-deprecated version. It sounds like some are considering losing SDM 
>>> as the default run mode.  I think that would be a mistake and would make it 
>>> appear that GWT is more cumbersome to use than it is.  Hosted Mode w./ Dev 
>>> Mode Plugin was broken due to the deprecation of the NPAPI plugin, other 
>>> than possibly refactoring out SDM from the DevMode class, I would 
>>> personally consider removing SDM as breaking something that isn't broken 
>>> for no particular reason.
>>>
>>
>> I don't understand what you mean.
>>
>> DevMode can mean either "dev mode using the browser plugin", or "the 
>> c.g.g.dev.DevMode entrypoint class".
>> SDM, to me, can only mean "dev mode using compiled-on-the-fly JS", so 
>> it'd be the opposite of "dev mode using the browser plugin", without saying 
>> "how" you run it.
>> The opposite of "the c.g.g.dev.DevMode class" is CodeServer (i.e. "the 
>> c.g.g.dev.codeserver.CodeServer class").
>> And SDM could be used either through c.g.g.dev.DevMode or CodeServer.
>> So for SDM, there's no terminology problem, and yet I don't understand 
>> what you mean by "removing SDM".
>>
>> CodeServer will stay, that's a given. The question (to the Steering 
>> Committee) is whether c.g.g.dev.DevMode will stay with only its SDM mode, 
>> or whether it'll be removed (and SDM can only run through CodeServer, which 
>> would remain the only "development mode" of GWT).
>>
>

-- 
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/80e84a7d-1afa-4d9d-847f-7cd2145571a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.