Re: Need to understand GWT DOM - on which frame does my module reside.
Certainly this is a trivial matter but for all the efforts put in to
write a fairly comprehensible JSNI explanation in the GWT docs, I am
unable to find any clarification on how the DOM is mapped by GWT.
Because, when I do the following (instance of user using a static
reference to Main to call refresh() ) it works:
[code file=Main.java]
public class Main
implements EntryPoint
{
static public Main mainref;
public void onModuleLoad() {
mainref = this;
yada
public void refresh(){
yada
}
}
[/code]
[code file=User.java]
yada
AsyncCallbackHello helloCallback = new AsyncCallbackHello{
yada
Main.refresh(); // this works.
}
[/code]
Since a static reference works, certainly GWT through some
mysteriously way I have yet to comprehend is able to get across frames
to get to refresh(). And so could I, if I had not used GWT but coded
in pure javascript as I would have control and possess full
consciousness of the frame structure of my app.
--
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Need to understand GWT DOM - on which frame does my module reside.
The code fragment you pasted will all reside in the same frame. Because it
is all part of the same module, there is nothing mysterious about it -
(other than the fact that GWT will minify and obfuscate the generated js
code).
Your earlier question was about two different GWT Modules (one on the
regular page, the other in an iframe in a dialog box) able to communicate
with each other through JSNI. Someone will likely give you a solution to the
problem you described., *but*
... Why complicate your architecture to include multiple modules that depend
on each other via native JSNI method, which is also detrimental to client
side performance and usability in general?
You could just put your logic in the same module and invoke it when the
DialogBox opens. If you are concerned about loading the code unnecessarily,
you can try out code-splitting.
That's just my opinion. Someone else may have an answer to your specific
problem.
--Sri
On 7 April 2010 15:38, Blessed Geek blessedg...@gmail.com wrote:
Certainly this is a trivial matter but for all the efforts put in to
write a fairly comprehensible JSNI explanation in the GWT docs, I am
unable to find any clarification on how the DOM is mapped by GWT.
Because, when I do the following (instance of user using a static
reference to Main to call refresh() ) it works:
[code file=Main.java]
public class Main
implements EntryPoint
{
static public Main mainref;
public void onModuleLoad() {
mainref = this;
yada
public void refresh(){
yada
}
}
[/code]
[code file=User.java]
yada
AsyncCallbackHello helloCallback = new AsyncCallbackHello{
yada
Main.refresh(); // this works.
}
[/code]
Since a static reference works, certainly GWT through some
mysteriously way I have yet to comprehend is able to get across frames
to get to refresh(). And so could I, if I had not used GWT but coded
in pure javascript as I would have control and possess full
consciousness of the frame structure of my app.
--
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
--
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Need to understand GWT DOM - on which frame does my module reside.
Then, the next question that begs to be answered is, Is maintaining a static reference a good practice for inter-frame communication? If I used only one browser session, I invoked Main entrypoint on two separate Firefox tabs, will both instances of Main be contending to write to static public Main mainref? Or does a static variable in GWT is actually a global to all frames within the same root frame of an instance of Main. I am also thinking of maintaining a HashMapInterger, Main appHash, so that onModuleLoad of any Main instance int thisKey = this.hashCode(); Main.appHash.put(thisKey, this); And then when instance of Main pops up an instance of User, Main would pass its value of thisKey to User as part of the URL. Then, instance of User could draw out its corresponding instance of Main Main mymain = Main.appHash.get(thiskey); mymain.refresh(); Would maintaining appHash be a good idea? Or would maintaining a static reference be sufficient since static variables do not leak into another instance of Main (or do they?) ? Please advice: - the DOM mapping of frames by GWT - the behaviour of static variables in a GWT module. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Need to understand GWT DOM - on which frame does my module reside.
I thought, I did not need to expose the innards of my app. The namedframe housed in the dialogbox is actually a google or open id login. Since both google and open id login/outs require uri and callbacks, I cannot possibly eliminate the frame so that Main and User could refer to each other in any honky-dory fashion. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Need to understand GWT DOM - on which frame does my module reside.
If I used only one browser session, I invoked Main entrypoint on two separate Firefox tabs, will both instances of Main be contending to write to static public Main mainref? No. Each tab is a different context altogether. They will not interfere with each other at all. Or does a static variable in GWT is actually a global to all frames within the same root frame of an instance of Main? Static variables in GWT do not translate to globals in javascript. Please advice: - the DOM mapping of frames by GWT - the behaviour of static variables in a GWT module. When you include a GWT module, it creates a hidden iframe behind the scenes. The id of this iframe is your module name. The generated javascript code is scoped to this iframe. Say you have a html page which has another iframe. If the main page and iframe include the same gwt module, they will still be scoped differently. Methods and Variables in one module will not interfere with the other module. Both will retain their individual state. As to how history would be maintained - I don't know. Its going to be completely messy. Since both google and open id login/outs require uri and callbacks, I cannot possibly eliminate the frame so that Main and User could refer to each other in any honky-dory fashion. I think I now understand what you are trying to do. OpenId requires the user to be redirected to a provider (like google) for authentication; but you don't want the user to leave your site. So you want to send the user to the provider in an iframe. Take a look at the gwt-exporter http://code.google.com/p/gwt-exporter/project. It allows you to export your GWT methods as standard javascript methods. In your case, you can export your refresh() method as a JS method, and then use your iframe to call it using standard JS techniques. Or, you could just redirect the user to the OP, let the user authenticate himself over there, and then let the OP redirect to your website when everything is done. This is a simpler flow for the user, and a lot simpler for the developer. This is the standard way it is done - see how its implemented on stackoverflow.com. --Sri On 7 April 2010 15:58, Blessed Geek blessedg...@gmail.com wrote: I thought, I did not need to expose the innards of my app. The namedframe housed in the dialogbox is actually a google or open id login. Since both google and open id login/outs require uri and callbacks, I cannot possibly eliminate the frame so that Main and User could refer to each other in any honky-dory fashion. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
