Who processes the gwt.codesvr parameter a browser plugin or java script on the hosted page

211 views
Skip to first unread message

Adib

unread,
Mar 26, 2011, 3:29:04 PM3/26/11
to Google Web Toolkit
Hello,

I am trying to figure out where the gwt.codesvr parameter gets
processed? I can think of the following options and would like to get
clarity about which of these options in the correct example.

a) Is it used by the browser plugin so that the browser plugin can
talk to the code server

b) is it used by the host page in some bootstrap java script. I
find this to be not very likely because there does not seem to be a
bootstrap javascript that is not generated from java code.

c) is there supposed to be a servlet on the server side side that
should be configured to understand this parameter?

Thanks
Adib

Thomas Broyer

unread,
Mar 26, 2011, 4:07:33 PM3/26/11
to google-we...@googlegroups.com, Adib


On Saturday, March 26, 2011 8:29:04 PM UTC+1, Adib wrote:
Hello,

I am trying to figure out where the gwt.codesvr parameter gets
processed?  I can think of the following options and would like to get
clarity about which of these options in the correct example.

    a) Is it used by the browser plugin so that the browser plugin can
talk to the code server

It's the thing that triggers the use of the plugin, so it can't be the plugin that processes it (I guess it could, once loaded, process it, but I believe that's not the case)
 
    b) is it used by the host page in some bootstrap java script. I
find this to be not very likely because there does not seem to be a
bootstrap javascript that is not generated from java code.

Yes it is. It's in the *.nocache.js, which either loads the hosted.html (or hosted.js, depending on the linker) or the appropriate *.cache.html/js.
You can compile in --style PRETTY to have a readable version; and you'll find the templates in com/google/gwt/core/linker in the gwt-dev.jar

    c) is there supposed to be a servlet on the server side side that
should be configured to understand this parameter?

No, it's all client-side. GWT is backend-agnostic (with the exceptions of GWT-RPC and RequestFactory, of course, but even those can be –and are!– implemented in non-Java backends)

Adib

unread,
Mar 28, 2011, 8:25:04 AM3/28/11
to Google Web Toolkit
On Mar 26, 1:07 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Saturday, March 26, 2011 8:29:04 PM UTC+1, Adib wrote:
>
> >     b) is it used by the host page in some bootstrap java script. I
> > find this to be not very likely because there does not seem to be a
> > bootstrap javascript that is not generated from java code.
>
> Yes it is. It's in the *.nocache.js, which either loads the hosted.html (or
> hosted.js, depending on the linker) or the appropriate *.cache.html/js.
> You can compile in --style PRETTY to have a readable version; and you'll
> find the templates in com/google/gwt/core/linker in the gwt-dev.jar

I thought that the *.nocache.js was being generated by the code
server, or
when I explicitly compile the code. Does that mean that if I am using
tomcat
to host the GWT page I have to run the compile manually every time
I try to run the application.

Thomas Broyer

unread,
Mar 28, 2011, 8:42:02 AM3/28/11
to google-we...@googlegroups.com, Adib


On Monday, March 28, 2011 2:25:04 PM UTC+2, Adib wrote:
On Mar 26, 1:07 pm, Thomas Broyer <t.br...@gmail.com> wrote:
> On Saturday, March 26, 2011 8:29:04 PM UTC+1, Adib wrote:
>
> >     b) is it used by the host page in some bootstrap java script. I
> > find this to be not very likely because there does not seem to be a
> > bootstrap javascript that is not generated from java code.
>
> Yes it is. It's in the *.nocache.js, which either loads the hosted.html (or
> hosted.js, depending on the linker) or the appropriate *.cache.html/js.
> You can compile in --style PRETTY to have a readable version; and you'll
> find the templates in com/google/gwt/core/linker in the gwt-dev.jar

I thought that the *.nocache.js was being generated by the code
server, or when I explicitly compile the code.

It is being generated by DevMode when you launch it (which explains why the -war argument is mandatory even with -noserver), unless it already exists (unless it's older than the gwt-dev.jar, maybe, can't remember the details for sure).
...and by Compiler, of course, unconditionally.
When generated by DevMode, it only contains the code that's necessary to launch DevMode.
In any case, it contains nothing related to your Java code, everything comes from the *.gwt.xml files; with the exception of the permutation IDs (names of the *.cache.html/js files when you compile your app).
 
Does that mean that if I am using tomcat to host the GWT page I have to run the compile manually every time
I try to run the application.

Fortunately not!

If you can point DevMode's -war to the folder where Tomcat reads the files (exploded web app), then you don't need to compile your app, not even once.
Otherwise, you'll have to compile the app once (or launch DevMode once and then deploy the generated *.nocache.js file)

Really, compile once in -style PRETTY to have a look at what it looks like and how it works.

Chris Conroy

unread,
Mar 28, 2011, 10:17:13 AM3/28/11
to google-we...@googlegroups.com, Adib
It's used by the bootstrap to know to load the plugin, and then it's used by the plugin to connect to the code server.


--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.


Reply all
Reply to author
Forward
0 new messages