Group items tagged

the GWT compiler configuration is done in the web application project. This is the best place, since you can just change the dependency and the GWT module and the compiler will compile a completly different GWT client. With other words, the web application pulls the right JAR out from the Maven space and uses it. This is much better than letting another project compile some JavaScript and than copy the JavaScript to your web application, or whatever solution you might find. So just add the GWT Maven plugin configuration and dependency below to the photo-album-server module’s POM.

our project is just a simple Java project.

To help any syntax checkers know that they should avoid parsing the JavaScript code, you wrap it as a comment by using a modified standard comment, which starts with the characters /*- (a forward slash, an asterisk, and a dash) and ends with -*/ (a dash, an asterisk, and a forward slash) (2). It’s also important not to forget the trailing semicolon at the end of the definition; otherwise your code won’t compile!

Crossing the boundary from Java to JavaScript can come in two forms: writing JavaScript code in the Java application that performs some dedicated functionality, or writing JavaScript in the Java application that calls functionality in a Java- Script library already loaded into the web browser.

If you provide a return type, rather than just a void, then the JavaScript must return an object of the correct type. (Be aware that JSNI code can’t create new Java objects; it can manipulate ones passed in or create new JavaScript objects, but not new Java objects.) REMEMBER It isn’t possible to create new Java objects in a JSNI code block. Return types must either be primitive types, manipulated Java objects that have been passed in as input parameters, or references to newly created Java- Script objects (a JavaScriptObject type). It’s important to understand how the objects you provide as parameters are handled across the Java-to-JavaScript boundary

ensure that a clearly defined and repeatable mapping exists between Java typed objects and JavaScript untyped objects, which is what GWT provides.

Primitive Java numeric types, such as byte, short, char, int, long, float, or double, become simple objects in JavaScript whose value is that of the original object. For example, if you have a Java char, char keyPress = ‘a’, then it will become the JavaScript variable var k = ‘a’. Similarly, the Java int, int val = 10, becomes the JavaScript variable var v = 10. A Java String is translated across into JavaScript as a simple variable to which the original text is assigned. Therefore the Java object String name = “GWT In Action” becomes the JavaScript variable var s = “GWT In Action”. Finally the simple Java boolean, becomes another simple JavaScript variable; the Java boolean b = true becomes the JavaScript variable var b = true.

Moving on to more complicated Java objects that can be passed across the boundary, you have the Java array, a Java object, and a new object to GWT called the JavaScriptObject. We’ll discuss the last object more in the next section; for now, you should think of it as just a reference to a JavaScript object created somewhere else that can be passed around the Java code and on to other JavaScript methods—but you can’t look into its contents from the GWT Java code. This may sound strange, but we’ll explain in more detail later in the section on this object. Passing an array across the Java-to-JavaScript boundary is treated in a similar opaque way; you know you have an array object, but you can’t look into its contents. This means that if the JavaScript code needs to use values in the array, then you should move them out of the array before you cross the boundary: either into separate parameters or into another type of user-defined Java object. You can manage Java objects in JavaScript through the JSNI interface, as we’ll discuss next. You can also pass your own defined Java objects across the Java-to-JavaScript  boundary; GWT provides a special syntax allowing you to access the fields and methods of that Java object. This will take a little bit of explaining, so please, stick with us.

Event

So basically the way this works is that you can create a new Anchor widget and append a parameter to it. In your onModuleLoad function you can get the parameter from the window’s location, and then use this parameter to load a different state of your application. To create a parameter just append a “?” then the name of the parameter and finally the value of the parameter. Also you can include multiple paramters by using the “&” symbol, so for example you could do this: “?action=hello&noaction=bye”.

The next step is to initialize the state of your web application using the history stack.

AJAX history logic can get confusing quickly, so you should have a good plan in place before writing the logic.

If there are tokens in the history stack, and the user presses the Back button, or you invoke the History.back() method, then the following steps occur: a token is retrieved from the top of the stack this token (which is just a String) is then passed to your HistoryListener implementation, and this is how you know that the Back button is pressed. You then have to parse that token and change the state of your application to match what this token represents to your app.

no matter what happens, all these Back/Forward actions (whether initiated programmatically by your app, or by a user) ends up calling your HistoryListener’s onHistoryChanged(String token) method, which can act as a traffic cop of your state machine. You are in control of defining what a token is, and how it should map to various states in your application. You can encode parameters in the token and then parse them out later, to understand what your app is supposed to do now.

If you noticed the change in the browser’s displayed URL, when a hyperlink with a history token is clicked, then can see how the user is able to bookmark a specific state in your app… the token is simply added to the URL in the browser prefixed with a “#”. So, is it possible to add your own history token by typing in the URL for your app and just appending “#mynewtoken” to it? Yes! This is how GWT handles people bookmarking specific states of your application. One thing to keep in mind is that if you end the browser session, and then come into the app, then your app will have to process the initial history state, and it will have to check to see if there is “#mynewtoken” passed in the URL to the browser, and then adjust it’s state accordingly

you can hook into this mechanism and make it possible for the app to go to a particular state or load a particular resource or perform a function based on what is passed as a token to the URL.

You can use pass parameters to your app via the URL (here’s a coding quickie that shows you how), and you can use it along with tokens, but it’s bit confusing to use both.

let’s use this URL as an example: http://localhost:8888/Sample.Client/index.html#link2token?p1=v1&p2=v2 When you run the app with this URL, you will get the following string as the token: “link2token?p1=v1&p2=v2“. So as you can see it’s not a great idea to mix the two. This is the kind of URL that’s generated by the GWT Hyperlink class, so you can’t really mix and match query strings with history tokens.

If you want to create the URL yourself, then you can pass history tokens and query strings. In order to do this, you have to make sure to place the query string (?p1=v1&p2=v2) before the “#” in the URL and it will work. If you use this URL as an example: http://localhost:8888/Sample.Client/index.html?p1=v1&p2=v2#link2token When you run the app with this URL, you will get the following string as the history token: “link2token“. And a call to GWTUtils.getParamString() will return “?p1=v1&p2=v2“.