Code Herding: 2010

2010-11-19

GWT + Struts 1.x + Netbeans Tutorial (Part 8c)

<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 8b...

The algorithms to make the authorization flow described in the previous 2 parts of this chapter are simple and they provide for tweaking and the usual stakeholder requisite changes.

First the core of our filter, how to know in which part of the authorization flow through which the user is in transit:

Returning authorized user(1)
Everyone else(2)
- After authorization prompt(2.1)
- Canvas(2.2)
- Site(2.3)

Now let me explain how to know and what parameters to check to know in which part of that tree the user is located and what you might do after that:

(1)access_token present in session

Retrieve user information using access_token

(2)access_token not present in session

(2.1)requestURL == redirect_uri

(2.1.1)code parameter present

Retrieve "access_token" using "code"

Store "access_token" in session

(2.1.1.1)source parameter == canvas

Redirect to canvas

(2.1.1.2)source parameter == site

Continue to site

(2.1.2)error_reason parameter present

log error reson

(2.1.2.1)source parameter == canvas

Redirect to canvas with onclick auth link

(2.1.2.2)source parameter == site

Continue to site with regular auth link

(2.2)signed_request parameter present

Decode signed request

(2.2.1)userId present in signed_request

Retrieve user information using access_token

(2.2.1.1)profileId present in signed_request

Retrieve user information using access_token

(2.2.1.2)profileId not present in signed_request

Retrieve user information using access_token

(2.2.2)userId not present in signed_request

Redirect to canvas with onclick auth link

(2.3)signed_request parameter not present

Continue to site with regular auth link

To decode the signed_request you need to use a Base64 decoder which handles URLsafe decoding. After decoding use class javax.crypto.Mac to get a Message Authentication Code for the algorithm passed in the JSON decoded signed_request. Use your aplication secret (known only to you as a developer) and sign the JSON payload of the signed request and compare it to the decoded signature. If they match then you can rest assured the signed_request comes from the Facebook servers.

A few things to keep in mind which will be important when you test your code: use the EXACT same redirect_uri (including the source parameter) to retrieve the access_token. This was clearly stated in the documentation even from the early stages of the migration to the new Graph API, it helped me a lot to remember it. I used all the parameters used by Facebook (appId, appSecret, appKey, redirectUri, canvasUrl, siteUrl) as init parameters of the filter to be able to reuse the filter for other applications without changing code, and just changing those init parameters in the xml configuration.

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

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

<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 8a...

Now that we know where was the user before we redirected him/her to the authorization prompt, we know the structure of our redirect_uri. After decoding (Base64) the Signed Request then we need to look for an attribute named "user_id", if this attribute is not present then the user has not yet authorized our application to access their information. In the first draft I decided to do an automatic redirection to the authorization prompt but then I thought about it and I chose not allow the user to have control over the flow; never force the user to do things if you don't know whether they want to do them or not.

In this design a simple Facebook logo with a link to the authorization prompt will be displayed to let the user decide to link their profile information to our application or to browse the application as a guest user. In the canvas version the link provides an onclick event handler to set the window.top.location and in the web application version a regular link.

Now, how to know if the user authorized our application after the prompt? The user is going to be redirected to the redirect_uri you provide and the parameters passed to this uri are the key. If you get a "code" parameter then the user authorized the app, if you get an "error_reason" parameter (along with other error parameters) then the user did not authorize it. In the filter I check if the requested URL is the redirect_uri and then I do 2 things, first i look for the "source" parameter I passed along with the redirect_uri to know where to send the user after I retrieve their access token which provides us with a means to know the information they have allowed us to access, second I look for the "code" or "error_reason" parameters and if the "code" parameter is present then we need to exchange it for an access token by fetching a URL (web service) and parsing the (JSON) response. If the "error_reason" is present then we can log the error reason, nothing much after that. The filter redirects the user to the canvas if the "source" parameter is canvas or simply continues to the regular flow if the "source" is site.

That covers, on an eagle-view, the canvas authorization process, now the web app authorization process and at the end of this chapter there will be a detailed design for the filter.

The web app authorization process is now more simple since we made the canvas authorization process practically the same by providing a link to the authorization prompt. The difference comes in the JSP file, if you find a "signed_request" parameter then the user is coming from canvas and we need to use an onclick event to set "window.top.location=<fb_auth_url>" and if it's not present then a regular link to the fb_auth_url.

The rest is the same because we now took the common parts of the authorization and the only thing that changes can be decided by checking the "source" parameter and redirecting to the relevant page accordingly. After we have fetched the access_token (the user authorized our application to access their information) we need to store it for safe-keeping and to avoid going through the whole process each time the user comes to our application. It's is so that now we need to change the first part of our algorithm, we need to check if the access_token is present for the current visitor and if it's not then provide a link to the authorization flow.

That's all there is to it on paper, now on the next section the relevant algorithms to decide in which part of the authorization process currently the user is going through, how to parse the "signed_request" parameter, how to verify the encoded signature and how to fetch the "acccess_token" after the user has authorized us.

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

GWT + Struts 1.x + Netbeans Tutorial (Part 8a)

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

Part 8: Facebook Authentication (Canvas + Web Application)

If you're a curious developer, as I suppose you are, then you probably are always on a quest for new APIs and new ways of making your work easier to accomplish. Facebook has a platform to publish your work and expose it to millions of potential users. It provides a range of options from low-level (low-level for an experienced developer like you) badges and widgets like those you can find scattered around this blog post to full-fledged database persistence, JSON-based web services, and the like (pun intended ;D).

In this part of the tutorial i'll try to explain my <adjective related to pain here> experience in hopes of preventing others from falling in the same pits. When i started working on the integration of a website with the Facebook platform, the process of authentication and app authorization was in the process of change. My experience was not the greatest because of all the rapid changes happening to the authentication and authorization flow needed for your application to communicate with the Facebook servers to request user info and do all the nice things you probably have in mind to provide a great user experience.

There are 3 ways of integrating with the Facebook platform: as a canvas app, as a web application, or as a standalone application (a.k.a. desktop app). I was integrating a website so the 3rd option would be left for a future development cycle, if at all. After going through the documentation provided by Facebook I was wondering where to find an Aramaic translator, it's understandable (NOT) that they didn't have a stable design at the time as they were going through the authentication process change (they were changing to OAuth2.0). So I decided to go with the flow and work the Facebook way (trial and error until something works). I took the little that could be salvaged of the documentation and started coding according to their explanation of what needed to be done, and all the interaction between the different actors.

After a couple of days working with the code I got to an acceptable solution, involving a filter, a servlet and a jsp. I decided (more like deciphered, amirite?) the phase in the authentication process in the filter, did the heavy-lifting in the servlet and then provided the view in the jsp. As time went by the solution broke with all the changes going on on the FB side of the process so i decided to go through the documentation again and to design a solution flexible enough to withstand the changes and that provided for future tweaking as it evolved. Always keep that in mind in your designs, evolution and change.

The final solution involved just a filter which does all the heavy-lifting and would act as a Facebook client. Now the part you're looking for is how to organize the workflow. After reading the documentation again I noticed it had changed and it now provided a few hints to common pitfalls (some I found along the way) and I decided to dissect it. A user arrives and it can view your website through the FB canvas or through the regular Internet. The way to know which version the user is currently viewing is to look for the Signed Request parameter. After you know the version then you know how to request for authorization from the user to access their information. In the canvas version you can't simply redirect the user to the authorization screen because the screen is going to be inside an iframe and a bug (hopefully in the future it'll be solved) prevents the auth prompt from showing up, so I decided to do an ol' "window.top.location=" to redirect the user to the relevant location. This introduces an issue, you need to pass a redirect_uri for the auth prompt to redirect the user after he/she has made the choice to allow us to access (or not) their information. I solved this by appending a "source" parameter at the end of the redirect_uri: source=canvas or source=site.

In the next section we'll continue dissecting and solving the small parts involved in integrating a website with the Facebook platform.

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

2010-06-30

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

<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:

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

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

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

Part 7: Tying the I18N support from both GWT and Struts.

We have a working Struts application with regular page navigation, and GWT support, which is also i18n aware. This is important to keep in mind, it's ONLY i18n aware, in the sense that it knows about different locales. If you access you application from a web browser with an accept-language header different from "en" there are some glitches in the GWT display, it doesn't detect the language quite right.

It uses the "default" locale, which is English. I don't know if this just happened to myself or if it's a glitch in general. I will treat it as a general issue, because the fix i propose is also a nice-to-have feature, as usual.

I want both my Struts application and my GWT modules to keep in sync of what languages each one of them is using. Since changing the Struts language is easier i will make the GWT language a slave of the Struts language. This is something you would do if you have an existing i18n Struts application to which you just added GWT support. My application in this tutorial is a new application as well, and the steps needed to synchronize both views to the same language requires only a few lines of code in the JSPs, we also need to configure our gwt.xml file for this module to inherit the i18n classes and finally we're going to make our message resources available to GWT, just as it is available to Struts, but with a nice improvement which is provided by the i18n module in GWT.

In the previous section i mentioned the Constants and Messages interfaces, which provide utilities to internationalize an application. We're going to build a class that finds our international messages automatically from the given keys. GWT also comes with a command line tool called i18nCreator which can help us create this interface for us automatically. I'm gonna do it manually, since the procedure for the i18nCreator is pretty straightforward and requires little input. I recommend you read about i18n and i18nCreator in the GWT documentation and use it as a way to save you both time and patience.

I'm assuming our language translations are located in the com.example.strutsgwt.client.i18n package. Our entry point is located in the com.example.strutsgwt.client package. Our module gwt.xml file is located in the com.example.strutsgwt package. Our JSPs in the usual location.

The first thing we're going to do is configure our module's gwt.xml file by inheriting the i18n module. To achieve this we're going to edit it by adding the following after our <module> tag:

Now we need to declare the languages we're going to use, i wish it could be dynamic, and i suspect there's a way to do it which escapes me, so if anyone knows how, please post below and I'll add it here (with correct attribution of course). Now I'll give you an example of the code you need to place inside your gwt.xml file to declare your languages:

<extend-property name="locale" values="en"/>

<extend-property name="locale" values="es"/>

<set-property-fallback name="locale" value="en"/>

I'm going to explain these lines and in this way you're going to adapt it to your case. I declared 2 languages: en and es (English and Spanish, respectively) and in the last line i declared the "default" language, which in this case is en (English). You can declare your own languages in this fashion and remember to read the documentation for the GWT locales.

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

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

<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 7b...

The annotations tell the GWT compiler which method accesses which key. That's all we need to do to access a key inside the properties file, just add an access method and annotate it.

Finally to test all our configuration we're going to modify our EntryPoint to make use of the internationalized messages by asking GWT to create an implementation of our interface, but don't worry because all it takes is one line in our GWT code. I declared an attribute in the EntryPoint named messageResource of type MessageResource in this way:

MessageResource messageResource = (MessageResource) (GWT.create(MessageResource.class));

and now you can use that object to call the appropriate translated message by calling each declared method. In my example i have a label and a button that toggles the label when clicked. I removed the static text from the button and replaced it with messageResource.getClickMe() and for the label i did the same with the messageResource.getHelloGWT() method. So it should read:

final Label label = new Label(messageResource.getHelloGWT());
final Button button = new Button(messageResource.getClickMe());

That's how you manage to get the internationalized version of your messages from GWT. There's just one more thing you need to do to close the circle and that is associate the locale parameter to your Struts locale when it's present, because it takes precedence over the gwt:property defined in the meta tag. To do it just place the following code before the <html:html lang="true"> tag:

<logic:present parameter="locale">

<% request.getSession().setAttribute("org.apache.struts.action.LOCALE", new Locale(request.getParameter("locale"))); %>

</logic:present>

Now if the locale parameter is present, then Struts will use that setting and if it's not present then GWT will use whatever Struts is using. They're collaborating to present the information in the same way. Now you could create a menu to choose languages using the GWT facilty that returns all the available languages (just an idea).

After compiling you should have a perfectly synchronized locale between both Struts and GWT and an easily internationalized application, just drop a new properties file with a new language and declare it in the gwt.xml file and you're set. You have access to the message resources from both the Struts' tags and your GWT Messages interface.

The steps followed in this part of the tutorial are:

Configure the module's gwt.xml file to use GWT's i18n support and declare languages.
Tie Struts' i18n locale detection and set it as the current locale in GWT by editing JSPs.
Create Messages, Contants or ConstantsWithLookUp sub-interfaces for the language properties files.
Use your interface to access the key/value pairs by declaring methods in it and using @annotations.

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

2010-06-28

GWT + Struts 1.x + Netbeans Tutorial (Part 6)

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

Part 6: Add I18N support to a Struts 1.x application.

TL;DR: move the MessageResource.properties file(s) to the "client" package. I used a package called "i18n" inside it, so mine points to:

com.example.strutsgwt.client.i18n.MessageResource

also modify struts-config.xml to reflect the change.

You might think this is a joke, because Struts has a very simple and straightforward way to add i18n support. Netbeans creates each new Struts project already having a default properties file (in English) which you can simply copy and rename, adding the appropriate language and country codes to the end, to add a new language to your application. So, is this a joke? No, this is not a joke.

This is a foreword to the i18n support in both Struts and GWT and how they work. The title should read "Adding i18n support to Struts in preparation for GWT".

Now that we have that clear, we need to know a few things about how Struts and GWT each handle i18n support. Struts uses properties files in a key=value format for all definitions we may want to have internationalized and you can also put placeholders for any dynamic strings you want to pass "as is" into the internationalized version. GWT uses 2 interfaces: Constants and Messages (there are other classes too, read the API). The first works just as the key=value properties file in Struts and the second works like the key=value properties with placeholders. They are pretty similar, right? Yes, they are. In fact what we're going to do is prepare the Struts project to accept the GWT i18n out of the box and also from the GWT point of view we're going to use the existing i18n support already provided by the Struts project.

GWT compiles everything in the "client" package into the JavaScript permutations, or so i think (please correct me if i'm wrong in the comment section). Therefore, to be able to use the i18n properties files from Struts we need to place those files into the "client" package. When you created the Struts project you were asked where to put the resources.

It was something like com.example.strutsgwt.MessageResource and you might have changed it a bit. So, now navigate to that package in your source structure.

I'm going to use the following structure to keep things tidy: com.example.strutsgwt.client.i18n. So create those packages and place your provided properties files inside.

After you move those files, you need to configure Struts to find them at the new location. You configure Struts to find the location of the message resources file (which i'm calling MessageResources.properties) by modifying the struts-config.xml file and changing the <message-resources> tag to <message-resources parameter="com/example/strutsgwt/client/i18n/MessageResources" /> and check everything works by compiling and testing.

You can then go ahead and add a new language by copying the MessageResources.properties file to the same package, renaming that file to MessageResources_es.properties or MessageResources_fr.properties (or your favorite language code) and modify the contents to the correct translation for each key that is found in the default file.

You should now have a working internationalized Struts web application project which is ready for GWT.

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

2010-06-27

GWT + Struts 1.x + Netbeans Tutorial (Part 5)

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

Part 5: Add GWT support to a Struts 1.x application.

In the previous parts we've configured our environment to work with both GWT and Struts. This part is as short as the last one, we're going to add GWT support to our "existing" Struts application (which happens to be a new Struts application too) and also make the GWT module available to our welcome page.

To add GWT support to our Struts project we need to right-click the project's name in the project tab in Netbeans, and select "Properties". In the properties section select "Frameworks" we need to click the "Add" button next to the "Used Frameworks" list and select Google Web Toolkit from the available frameworks list. Especify the location of the GWT SDK and the GWT Module name. Things get a lot easier if you expecify the GWT Module name to be the same as your MessageResource location and adding a dot and the module name in this way: ".<the-module-name-here>" at the end.
In our example i chose com.example.strutsgwt.Welcome.

After adding the GWT framework to our project, our structure changes to accommodate to the new classes, we get a "client" package with an EntryPoint subclass inside, a <the-module-name-here>.gwt.xml module file and a welcome file. We defined our Struts message resources file location to be com.example.strutsgwt.MessageResource therefore it can be found inside the com.example.strutsgwt package along with the Welcome.gwt.xml file. The gwt.xml file has the name of the module, which in our example it would translate to Welcome.gwt.xml.

Let's get to the important part, how to add the generated JavaScript to the pages we want. In the welcomeGWT.html file you find along with the welcome files and JSPs there are 2 important lines you need to copy. First there's a meta tag with a property GWT understands and then there's the usual script tag with the location of the EntryPoint. We are going to copy those 2 lines from the welcomeGWT.html file to the welcomeStruts.jsp file. I placed the 2 lines inside the head section of the JSP file.

You can now compile everything and test it. GWT compiles your Java code into JavaScript code so the compilation is a bit long and you might want to get used to this coding philosophy: use Hosted Mode for GWT testing, make changes and refresh the page while using hosted mode. I use Hosted Mode for the client (GWT) and i like compiling everything every now and then to check the whole project. Find your own pace.

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

2010-06-26

GWT + Struts 1.x + Netbeans Tutorial (Part 4)

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

Part 4: Create a simple Struts 1.x application.

TL;DR: Scroll down to the video.

This is a straightforward task. Simply open Netbeans, if it's not already opened, click "File" and then select "New Project" or alternatively you could Click on the "New Project" icon on the toolbar. After selecting "New Project", choose the "Java Web" category and then the "Web Application" project type. In the "New Web Application" wizard fill-in the information, such as the project name and click "next".

I am using Google App Engine (GAE) as a web server but you can choose any servlet container you like, such as Apache Tomcat or Sun Glassfish, which come bundled with Netbeans. If you're using GAE as the server, and you haven't added it to your services (i.e. it's not selectable in the drop-down menu), click the "Add" button. Select "Google App Engine" from the server selection list and click "next". In the location, point to the easy-to-find location where you saved and unpacked the GAE SDK. Configure the properties and click "finish". Now you can use the GAE development server to develop web applications for the Google App Engine cloud server.

After selecting the server for your new web application, click "next" and head to the frameworks section and check the "Struts" framework, don't worry if your application will have i18n support because we will deal with those specific details in the following parts of the tutorial, now check the "Add Struts TLDs" check-box and click "finish". If you noticed we didn't add GWT support to the web application, although it was available from the frameworks menu. This was done intentionally to create the Struts file structure first and to configure it the way you would normally do when starting a new web application using Struts. We'll worry about GWT later, because what we just did also allows you to follow the next parts of the tutorial and apply GWT support to an existing Struts 1.x web application without having to rewrite or manually create the required file structure.

The music clips are here on the left, just in case you feel like listening to something while you read.

GAE quirks

So, we now have a new web application project with Struts support that should work in GAE (or maybe not). Except that sessions are not ON by default, so we need to modify appengine-web-xml to enable sessions using the Netbeans editor by clicking the "Enable Support for Servlet Sessions" check-box or by adding this <sessions-enabled>true</sessions-enabled> inside the root. What next? Ok, we need to adjust a few things according to the "Will it play in App Engine" page. In that page it says:

JSP session beans are not supported; to enable EL parsing, add <% @page isElIgnored="false" %> to your JSPs and <%@tag isElIgnored="false" %> to your tag files.

So, how do we make session beans available to JSPs? We need to make them available through memcache using the persistence provided by GAE (they need to make a buck somewhere around here). I found this technique running around in the wilderness of the interwebs, but i think the low-level API gives you more control, the choice is up to you. So for now we're covered and we can pretend we can use session beans in JSP, provided we only store Serializable objects in which all the important attributes are Serializable as well.

Now we adress the other issue; EL parsing. In every page we create we need to insert the <%@page isELIgnored="false"%> directive to be able to use EL (expression language) inside our JSPs. Problem solved.

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

Code Herding

Share / Save this...

2010-11-19

GWT + Struts 1.x + Netbeans Tutorial (Part 8c)

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

GWT + Struts 1.x + Netbeans Tutorial (Part 8a)

2010-06-30

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

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

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

2010-06-28

GWT + Struts 1.x + Netbeans Tutorial (Part 6)

2010-06-27

GWT + Struts 1.x + Netbeans Tutorial (Part 5)

2010-06-26

GWT + Struts 1.x + Netbeans Tutorial (Part 4)

Hits