Sunday, May 30, 2010

A smarter SmartGWT

Once upon a time, there was a sweet meat vendor in the principality of RajaPutra Sri Nada, which sat at the edge of the expansive Thar desert to its north and the banks of a great river at its south.

His name was Manda-manda Agatha, which roughly meant "slowly-slowly come". It was probably because while he had to haul his heavy wooden cart, wheels creaking, into any village, the impatient children would yell "mandam manda!"

He was not a rich man, selling sweet meats with profits just enough to feed his family hand-to-mouth. Sometimes he watched the gold-trimmed carts of merchants on their way to the great Palace in the capital city of the great Moogle empire. He aspired to be one of those merchants.

"No, no. Correction." A local village chieftain would inflectively declare, "He aspires to be one of the Rajputs lording over those merchants in the service of the great Moogle Emperor."

The Moogle royalty and nobility were enthusiastic connoiseurs of sweet meats. So much, so that the Moogle royalty had devised a special formula of concocting sweet meats - using toffee made with coffee beans and cinnamon specially imported from the faraway kingdoms of Java. All every sweet meat vendor had to do was put their own specialised wrapper around it and the concoction would absorb and fuse the wrapper with its core. And the Moogles did not make it a secret recipe but made the recipe free to anyone who wanted it. Even appointed the benevolent Lord Aapachita II to oversee to its general availability and advertised the formula as Sri-Moogle Madhura Sutra (Sweetness Formula of Moogle the Gracious). For convenience, let's just call the formula SMMS.

Incidentally, for Agatha (Arya Agatha, Sir Agatha - as he preferred to be called), he found that his sweet meat core formula was just as competitive in flavour as that of the royal formula and yet the only people enthusiastic with his sweet meats were village kids. He would expel his breath, "kimartam karma-tam?" Why, why business/activity so dark? Even though he had submitted his formula to Lord Apachita for general availability too.

Until, until he chanced upon, incidentally also, a sweet meat supplies supplier who understood all the intricacies of both Agathaa Karya (Agatha's Concoction) and Madhura Sutra. Let's just call this sweet meat supplies supplier Zamdhiji for convenience' sake.

Zamdhiji had found that Agathaa Karya could have blended so perfectly and almost seamlessly with the royal formula. What was missing was a special sauce that would stitch the two together. Zamdhiji worked tiringly and tirelessly night and day in his spare time in his alchemy chamber and months' later voila! He emerged from his laboratory, eye brow sweating, declaring to everyone - !heurekamen! - and called the combined product Sri-Moogli Madhura Sutra Agathaa Karya, SMMS-AK.

Zamdhiji submitted his concoction to Lord Aapachita too. After which, nearly the whole civilised world got excited. From Arabia and Ethiopia in the west, to Byzantine and Persia in the north, Langka in south, Java and China in the far east. Fellow sweet meat supplies suppliers from the four, five or six corners of the world made contributions to Zamdhiji's karya to further enrich it. And Agatha's business bloomed.

Then Aarya Agatha took a moment in hind-sight. "I need to send my children to the best dharma-sutra sanghas - learning centres - in Lhasa, or Samarkand, or Gujerat or Alexandria. I could feed my family better. Wouldn't it be great if I could also own one of those Polynesian hand-crafted ocean-crossing yachts? And vacation twice yearly on the beaches of Gova?"

So, he created a similar sauce and called it ... well he could not call it SMMS-AK for obvious reasons. So he called it Agathaa Karya Sri-Moogli Madhura Sutra, AK-SMMS.

That was brilliant, he thought and gave himself a pat on his back. He further declared that he is taking all of Agathaa Karya, contributions from people from all over the known-civilised world inclusive, with him. They will no longer be administered by Lord Aapachita. Instead, he submitted them to the ascetic SriPaduka Aarya Matha (the venerated meditative stall-man whose-gracious-sandals-you-are-not-even-worthy-to-lick).

What is the difference? Ooo, the difference between Lord Aapachita and Lord Aarya Matha is huge. But that is beside the point because you can read their respective philosophies and zaastras (legalities) and what their implications would entail to the sweetmeat business from world-wide antara-sangha sutras. The point is ...

Well, the point is, Aarya Agatha has appeared to the known civilised world as an immature untrustworthy greedy business partner.

There was an uproarious uproar within the known civilised world - from Arabia and Ethiopia, to Constantinople, to Baghdad, to China, to Java and Sumatera and to Langka and even Madagascar and Tasmania.

To make matters worse, he declared, "Y'all are a bunch of wimps like puppets in a Javanese wayang opera."

To which, Zamdhiji protested, "Discussing the difference between Lord Aapachita and Lord Aarya Matha and their extreme implications to our business is nothing close to being puppets in a Javanese wayang opera."

To which, Aarya Agatha would shoot back, "True, true - but, but the way y'all whine about it is like being unprofessional puppets in a Javanese wayang opera." Like as though, "y'all could have silently come to my matha (meditation stall) and we could have discussed over it with chai and English muffins, and then I might graciously consider your proposals."

Well, we never knew that puppets in Javanese wayang operas could in any miraculous ways act professionally, did we? Which is also beside the point.

OK, end of debate. Zamdhiji and his collaborators decided - to naraka (hell) with Agathaa Karya, "We come up with Samartha Karya Sri-Moogli Madhura Sutra." A smarter recipe with Moogle's sweetness. Yes, indeed, next time we would be smarter than to fall into deceitful business dealings - I guess that is why they prefixed their new recipe with "Samartha".

Though Samartha is a Sanskrit word, incidentally, people ought to know that Shmarta in Hebrew has an implication of "being watchful and observant".

Thursday, May 20, 2010

ODBC on steroids

So, this has nothing much to do with Java, but I am also a C# programmer.

It is rather discouraging that most (if not all) examples that people post on ADO.NET use it like ODBC on steroids, merely using it to execute SQL statements.

What is the point?

I am unilaterally issuing a recommendation, if possible a technological fatwa, that people should no longer write ADO.NET examples to solely demonstrate SQL execution. Any further examples should demonstrate objects and entities.

The ultimate purpose of using ADO.NET is its ability to project objects and entities and people are either unaware of how to use it that way or are addicted to SQL on ODBC. So - no more monkeys jumping on the bed!

Very very annoyed.

When I issue a technological fatwa, does it mean that I consider myself a guru? Hmm ... embarrassing.

Wednesday, May 19, 2010

Accessing Google UserService from GWT client through RPC

There are times when you create a web app, you would want users to log in to provide user-contextual features. However, you don't wish to manage the log-in accounts. To do that, you could use OpenID or Google Accounts. The strategy is to have Google or an OpenID provider maintain and authenticate user existence. By doing that you do not carry the liability of lost passwords, log-in security, etc.

This tutorial concerns using Google Accounts to maintain the existence of your users in a Google App Engine application.

Google App Engine provides the class UserServiceFactory to facilitate that. UserServiceFactory is then used to generate UserService object, which in turn provides the following features
createLoginURL
createLogoutURL
getCurrentUser
isUserAdmin
isUserLoggedIn

You would use UserService object to generate the login URL for the browser. The browser would be directed/redirected to this URL. On reaching this URL, the Google log-in prompt would be displayed by Google's server.

Once logged in, your application could use the UserService object to inquire about the current user.

However, UserServiceFactory should be used on the server side not the client side. You cannot include it as part of your GWT module because

  • GWT compiler would request for the source code of UserServiceFactory and UserService - because GWT compiler needs to be presented all source code that is to be compiled into Javascript.
  • You cannot run UserServiceFactory and UserService on GWT client because they need to access Google's internal server-side objects.


If that is the case, how then do you pass UserService information to the GWT client? Simple - use RPC.

Server-side interface
You need to create a server-side GWT RPC interface similar to the following.
public interface UserServiceWrapper
extends RemoteService{
  String createLoginURL(String callbackUrl);
  String createLoginURL(String callbackUrl, String authDomain);
  String createLogoutURL(String callbackUrl);
  String createLogoutURL(String destinationURL, String authDomain);
  UserInfo getCurrentUser();
  boolean isUserAdmin();
  boolean isUserLoggedIn();
}

RPC servlet
Then your RPC server-side servlet would implement that interface
public class UserServiceServlet
extends RemoteServiceServlet
implements UserServiceWrapper
{
  final static public UserService userService = UserServiceFactory.getUserService();

  @Override
  public String createLoginURL(String callbackUrl) {
    return userService.createLoginURL(callbackUrl);
  }
  @Override
  public String createLoginURL(String callbackUrl, String authDomain) {
    return userService.createLoginURL(callbackUrl, authDomain);
  }
  @Override
  public String createLogoutURL(String callbackUrl) {
    return userService.createLogoutURL(callbackUrl);
  }
  @Override
  public String createLogoutURL(String destinationURL, String authDomain) {
    return userService.createLogoutURL(destinationURL, authDomain);
  }
  @Override
  public UserInfo getCurrentUser() {
    return mkUserInfo(userService.getCurrentUser());
  }
  @Override
  public boolean isUserAdmin() {
    return userService.isUserAdmin();
  }
  @Override
  public boolean isUserLoggedIn() {
    return userService.isUserLoggedIn();
  }
 
  static public SeriUser mkSeriUser(User user){
    return new SeriUser(
      user.getAuthDomain(),
      user.getEmail(),
      user.getNickname(),
      user.getUserId()
      );
  }
}

You cannot pass Google User object to a GWT client, unless you have the source code or fake the source code for User class. The simple way is to define a serializable SeriUser class and pass an instance of that class to the GWT client.

Client-side interface
Google Plugin for Eclipse would then aid you to create the client-side RPC interface:
public interface UserServiceWrapperAsync{
  void createLoginURL(
    String callbackUrl,
    AsyncCallback<String> callback);
  void createLoginURL(
    String callbackUrl, String authDomain,
    AsyncCallback<String> callback);
  void createLogoutURL(
    String callbackUrl,
    AsyncCallback<String> callback);
  void createLogoutURL(
    String destinationURL, String authDomain,
    AsyncCallback<String> callback);
  void getCurrentUser(
    AsyncCallback<UserInfo> callback);
  void isUserAdmin(
    AsyncCallback<Boolean> callback);
  void isUserLoggedIn(
    AsyncCallback<Boolean> callback);
}

Client-side call
Let us say you have a GWT main client window with a MenuBar.
public class MainMenuBar
extends Composite{
  private final UserServiceWrapperAsync userInfo =
    GWT.create(UserServiceWrapper.class);
  .....

  final Command doLogin = new Command(){
    @Override public void execute() {
      userInfo.createLoginURL(
        "googleLoggedin.jsp",
        loginCallback
      );
    }
   
    AsyncCallback<String> loginCallback = new AsyncCallback<String>()
    {
      @Override
      public void onSuccess(String loginUrl) {
        popupFrame.showPage(loginUrl, "Google Log-in");
      }
     
      @Override
      public void onFailure(Throwable caught) {
        Window.alert(caught.getMessage());
      }
    };
  ....
}

On your MenuBar, you would have a MenuItem [Log in to Google].

  • On clicking this item, it would execute a Command doLogin to either create a NamedFrame in the main window or show a DialogBox embedded with a NamedFrame.
  • Here, popupFrame is the instance of a class extension of DialogBox, which creates a NamedFrame by providing it with the Google login URL.
  • The NamedFrame would access that URL where a Google server would display the Google Accounts log-in page.
  • When users authenticate their account with Google successfully, Google server would redirect the page to the URL of your page which is stored in the String entryPointURL.
  • Hopefully, you have provided a close button on your DialogBox or NamedFrame to either close the frame or the DialogBox.
  • On closing the DialogBox or Frame, the onClose listener would trigger the MenuBar to update itself to show the current user.

The MenuBar would fire a RPC call
userInfo.getCurrentUser()
to the server in order to list the user.

To logout, a MenuItem [Log out] would similarly fire a RPC call to the server
userInfo.createLogoutURL
go through the whole whatnots similar to logging in.

Tuesday, May 11, 2010

Using Vaadin with Google App Engine

Under the current situation of misalignment between Google and Vaadin in creating a project in Eclipse, to develop Vaadin applications that would work with Google Plugin for Eclipse, a few minor hurdles need to be jumped over. This tutorial outlines the simple steps that need to be taken to create a Vaadin project in Eclipse that runs on Google App Engine development environment.

Presuming the Google Plugin for Eclipse is already installed, follow the instructions found in http://vaadin.com/eclipse to install the Vaadin Plugin for Eclipse using [Help - Install new software] in Eclipse.

Have you ever wondered why [Install new software] item is found under [Help] menu in Eclipse? The help item is not instructions on how to install new software but actually installing new software. What are the nerds at Eclipse/IBM up to with this deliberate choice of menu structure? Difference between a nerd and a geek: a geek insists on being meticulously precise, whereas a nerd insists on being meticulously imprecise.

After restarting Eclipse (Do you really need to restart Eclipse? Could we just apply changes?), create a new Vaadin project.  You will find Vaadin section listed under the [New] menu item. If it is not within the first page of menu items, you would have to find it under [Other ...].
  • Give the project a name. Let's say you called it Zebra.
  • Set [Vaadin:Deployment configuration] to Google App Engine Servlet.
  • Choose the Vaadin version, or click download to download the latest one. This step may not be necessary because it is one of the causes of the project needing repair - but we have to fill in something no matter how erroneous, to be allowed to complete defining the project.
  • Then complete the rest as best as you can, before clicking [Finish].

Repairing the Vaadin project to use Google App Engine as development server
With a Vaadin project called Zebra,
  • Right-click on project Zebra for [Properties] item.
  • At [Java Build Path - Libraries tab], delete WebApps (under which is found the vaadin jar).
  • At [Google - App Engine] enable [Use Google App Engine] check box and fill the rest the best you could.

And again, voila Viola!

If you don't make these changes, you would encounter ClassNotFoundException when you try to launch the Vaadin Application. The reason being, there is disagreement of some sort between Vaadin and Google plugins on how plugins should build and dispense library references. Vaadin believes we should stick to the Eclipse standard and apparently Google has no vested interest in doing so.


You might also wish to allow OOPHM (browser plug-in debugging code server) to be used with debugging the project:
  • Delete the library references to vaadin downloaded gwt-user.jar and gwt-dev.jar files.
  • Create a new library reference for the vaadin.version.jar found in the WEB-INF/lib folder. If the jar is not found there, place a copy of the jar file there before making the library reference.
  • At [Google - Web Toolkit] enable [Use Google Web Toolkit] check box and fill the rest the best you could.
You should now be able to create a new Vaadin Application in the project from the context menu.

Do you have trouble correlating the term Out of Process Hosted Mode (OOPHM) with anything meaningful? Out of  what process? I think it is JVM-Based Browser Plug-in Hosting the Client-Side Debugging Co-Operand (of the Server-Side Debugger), which would be JVMBBPHtCSCO(oSSD). That's a mouthful. Hence, regardless being less precise, it is easier to say with a punch "Oophm!" Like someone had just punched you at the tummy.



Monday, May 10, 2010

Vaadin

Vaadin is a rather attractive JEE web application framework, where the client and server components are integrated into a single paradigm. To achieve that,
  • It uses GWT to present skeletal widgets on the client
  • Each client widget has a corresponding server widget component
  • It uses its own client-server communication channel rather than GWT RPC to connect the client and server   parts of a UI component.
  • The server component injects further presentation density into its corresponding client GWT widget skeletal by sending UIDL messages through that channel.
  • UIDL is in JSON, but with origins in XML.

It is a brilliant architecture which gives the server total management of the framework, hence freeing the programmer from having to set-up RPC communications. Entry point classes are defined by extending the Application class. The programmer merely defines classes (must implement Serializable) and instantiates objects just as in any non-webapp Java application.

Whenever a client class refers to an object or class defined in a class running on the server, vice versa, Vaadin takes care of that communication for you. The transparency between client and server resources is so seamless to the programmer that it tends to blur my karma from being conscious of whether I am working on the client or server code.

However, to extend a Vaadin component, you would not only need to construct its GWT skeletal widget but also the server side component. Therefore, you could not simply any old how take a GWT widget and deploy it within the Vaadin framework. However, within a web app, you could certainly mix and mesh Vaadin with pure GWT entry points by URLing each other.

I think Google should buy this company and integrate it with the rest of GWT and present it as GWT 3.0.

Running the Vaadin Samples
Download the latest Vaadin pack and unpack it.
Look for the vaadin-examples project in the unpacked directory and import it into Eclipse.
When the project is imported into Eclipse, look for the launch file vaadin-examples.launch. Run that launch file (by double-clicking on it, obviously).

You could also run it on the command line without importing the project into Eclipse.
Run either the file start.sh (for linux/unix) or start.bat (for Windows).

You will notice that the source files in vaadin-examples are placed within the war folder in WebContent/WEB-INF/src, because the pages of the samples allow you to view the code of the respective sample - and if the http server is to display source code, the source code has to be placed within the war structure.


Modifications required on the launcher
You might notice that examples from Vaadin tend to be hard-coded to run on http port 8888. That makes you mad because you will not be able to run more than one Vaadin example simultaneously on the same machine.

There is a class file  com.vaadin.launcher.DevelopmentServerLauncher. The programmers have created all the handles for the http port to be specified. The programmer has even written the line to read the port number that would be supplied as input argument to the Main class, but the programmer has somehow forgotten to apply that port number.

First test if Vaadin has rectified the file to read the port number. At Eclipse's Launch Configuration window, modify the Java Application launch for vaadin-examples. Find an unused port on your system. Let us say the unused port you found is 8200,  Add the the following argument at the Arguments tab
--httpPort=8200
Then, run the launch for vaadin-examples again (presuming you have stopped it in the first place). If the console output still says http port 8888 is used, they have not rectified it yet.

Here is the patched version of DevelopmentServerLauncher, that would apply the port number read as input argument:

If you wish to run the samples outside of Eclipse on the command line, you have to define an env variable (in unix/linux - a shell variable exported to system env)
VAADIN_PARAMETERS=--httpPort=8200

Voila Viola! (A former colleague had a slight habit of saying this - perhaps, his girlfriend's name was Viola.)