GWT + Struts 1.x + Netbeans Tutorial (Part 7b)

GWT + Struts 1.x + Netbeans Tutorial (Part 7b)

GWT + Struts 1.x + Netbeans Tutorial (Part 7b)

https://www.blogger.com/share-post.g?blogID=4038066669955738165&postID=3131558703471022668

---

---

<c:choose>
     <c:when test="${user.likes}"> 
          Share this with your friends
     </c:when>
     <c:otherwise>  
          Send me feedback.
     </c:otherwise>
<:choose>

---

Continues from part 7a...

We have configured our module to use different locales, but we haven't tied the Struts locale to the GWT locale. The GWT locale is specified by a parameter in the request called, surprisingly enough, "locale". Let's assume you access your application in your callback address (127.0.0.1 / localhost) through port 8080 in this fashion: 

http://localhost:8080/app

You can pass a parameter defining what language to load by appending a locale attribute and the resulting address would be:

http://localhost:8080/app?locale=en

Sounds easy, but it's cumbersome (or not) to pass this parameter in each call. I don't want to be worrying about this, i just want to configure it and forget about it. So i chose the other option to specify a locale, which is to define it in the JSP. This sounds dangerous since looks like we're hard-coding the language into the JSP, but you can make it dynamic by selecting the language that Struts has detected (and is using).

I added this line to my welcomeStruts.jsp file inside the head:

<meta name='gwt:property' content="locale=${sessionScope['org.apache.struts.action.LOCALE']}">

Remember to add the <%@page isELIgnored="false" %< to the JSP as seen on a previous chapter when we discussed GAE quirks if you're using Google App Engine (GAE).

Now we're going to create a sub-interface of the Messages interface with the same name as our localized properties files. This will help us make the properties files with our translations available to GWT. Create an interface in the same package where your localized properties files are and name it accordingly (with the same name as your localized properties files). In this example the files are named MessageResource[_ll[_CC]].properties so our interface will be named MessageResource. This interface should extend the Messages interface from the i18n package, be careful not to extend any of the other available Messages classes or interfaces.

Inside this interface we declare methods to access our key=value pairs, and since we made the interface extend Messages, we can also use the placeholder facility to pass strings which are not to be localized, such as "Welcome {0}!!!". If our access method is called "greet" when we call greet("Mary") the output will be "Welcome Mary!!!". In a real application you would do something like greet(user.getFirstname()).

I added 2 key/value pairs to each properties file. button.clickme and label.hellogwt with the respective translation in each file. In the English file it reads:

button.clickme=Click me!
label.hellogwt=Hello, GWT!!!

And in the Spanish file it reads:

button.clickme=Presióname!
label.hellogwt=Hola, GWT!!!

In the interface i added accessors to those 2 keys by declaring 2 methods:

/**
   * @gwt.key button.clickme
   * @return the localized click me message
   */ 

@Key("button.clickme")
public String getClickMe();


/**
   * @gwt.key label.hellogwt
   * @return the localized hello gwt message
   */
@Key("label.hellogwt")
public String getHelloGWT();

Continues here... 

---

If you have any suggestions, ideas for full blown system integration (sb) or comments, leave a message below.
I would appreciate if you could Share this with your friends

---

---