Nicozan-Blog

Knowledge Seeking

GWT Visualization – Transform Data into Information March 30, 2011

Filed under: GWT,Java — nicozan @ 12:22 pm
Tags: , ,

Introduction

Beginning with the concept, that data it is not information. A table full of rows (i.e. 1000 rows) it can be consider data, and you’ll agree with me that trying to find meaningful data (Information) from the table it’s going to be a tedious task. At this point of the reasoning is when we use Charts (i.e. Line Charts, Pie Charts, Scatter Charts, etc) to summarize the data from the table and in that way we obtain information to make a decision. GWT Visualization will help us to add Charts to our GWT webapp, by using its simple API.

Using the GWT Visualization API

If you are not familiarized with the GWT Framework, you need to have a look at its documentation or my post. Considering that you are using the Maven GWT Plugin, all you have to do is define the next dependency in the projects pom.xml.

<dependency>
  <groupId>com.google.gwt.google-apis</groupId>
  <artifactId>gwt-visualization</artifactId>
  <version>1.0.2</version>
</dependency>

The next thing to do is define the module inheritance so the client side of the webapp can use it. In the “myWebApp”.gwt.xml you have to write:

<inherits name='com.google.gwt.visualization.Visualization'/>

Now that we have GWT Visualization ready to use, let’s see the elements that are part of a Chart:
-DataTable (Data Format that is going to be injected into the Chart so it can display information)
-Options (Set of characteristics of the Chart: width, height,background,color,etc. )

If you want to see a basic example working go to this page: GWT Visualization Example.

Short Tip:

If you want to draw a Line Chart and you have dots or coordinates best thing, you should use a Scatter Chart and set the option ScatterChart.Option.setLineSize(1); . The line size has to be 1 or greater than 1.

 

GWT – Adding Jar Dependency to our GWT project. (Maven-Gwt-Plugin) March 17, 2011

Filed under: GWT,Java — nicozan @ 4:16 pm

Introduction

You might be asking yourself, Why am I doing this post?, because you might think that adding a dependency in a GWT Project using the Maven-GWT-Plugin is just as simple as adding a dependency in a Regular Maven project. Sorry to disappoint but apart from that you have to do something else … 🙂

Concepts

Every gwt project has a gwt.xml file that represents the GWT-module. This file contains specific information related to the module, for example:
—Entry-point (The java class that represents the web page that is going to be displayed in the web browser)
—Inherits (External Modules that our GWT-Module uses)

These two elements shown above are represented by tags. These tags are child elements of the root element module . The next code snippet shows how the gwt.xml file is structured.
MyWebApp.gwt.xml

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to='MyWebApp'>
 <!-- Inherit the core Web Toolkit stuff.                        -->
 <inherits name='com.google.gwt.user.User'/>
 <!-- Inherit the default GWT style sheet.  You can change       -->
 <!-- the theme of your GWT application by uncommenting          -->
 <!-- any one of the following lines.                            -->
 <inherits name='com.google.gwt.user.theme.standard.Standard'/>
 <!-- <inherits name='com.google.gwt.user.theme.chrome.Chrome'/> -->
 <!-- <inherits name='com.google.gwt.user.theme.dark.Dark'/>     -->

 <!-- Other module inherits                                      -->
 <inherits name='com.wordpress.nicozan.Model'/>

 <!-- Specify the app entry point class.                         -->
 <entry-point class='com.wordpress.nicozan.client.MyWebApp'/>

 <!-- Specify the paths for translatable code                    -->
 <source path='client'/>
 <source path='shared'/>
</module>

As you can see the name of the gwt.xml file is the same, and must be, as the Entry-point Java Class name. There are some modules that are standards and need to be inherited, (i.e : com.google.gwt.user.User)

Adding Jar Dependencies

Let’s consider the MyWebApp.gwt.xml shown before and that we have a project with two sub modules : webapp and model. The project has the next directory structure:

parent-project/                                    
|- pom.xml
|
|- model/                                      (External JAR module:)
|  |- pom.xml
|  \- src/main/java/
|     \- com/wordpress/nicozan/
|        |- Model.gwt.xml
|        \- model/utils/Element1.java
|
\- webapp/                                      (GWT-Module)
 |- pom.xml
 \- src/
    |- main/java/
    |  \ -com/wordpress/nicozan/
    |     |- MyWebApp.gwt.xml
    |     \- client/MyWebApp.java
    \- main/webapp/
       \- WEB-INF/web.xml

Take special attention to the model module. There is a gwt.xml file (Model.gwt.xml) that it’s in charge of specifying the source path from where the resources we’ll be built so the webapp module will then be able to use them. The Model.gwt.xml will look like this:

<module>
<inherits name="com.google.gwt.user.User"/>
<source path="model"/>
</module>

The Java classes are found recursively so you just need to specify the root directory.
The next thing to do is to generate this resources so the GWT webapp can use them. The pom.xml of the model module would look like this:

<project xmlns="http://maven.apache.org/POM/4.0.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>

<parent>
  <groupId>com.wordpress.nicozan</groupId>
  <artifactId>parent-project</artifactId>
  <version>1.0-SNAPSHOT</version>
</parent>

<artifactId>model</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<build>    
  <resources>
    <resource>
      <directory>src/main/java</directory>
      <includes>
        <include>**/*.java</include>
        <include>**/*.gwt.xml</include>
      </includes>
    </resource>
  </resources>
  <plugins>
        <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <executions>
        <execution>
          <goals>
            <goal>resources</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
</project>

Now, when you do mvn clean install of the parent-project, the resources will be generated and the GWT webapp can consume them. 🙂

TIPS/NOTES:
– Don’t forget to add all the dependencies as you usually do in your common maven projects.
– Remember to add the maven-gwt-plugin to the pom.xml of the resource you want generate.
– You don’t need to do all the steps explained above if you are adding dependencies that are going to use on the server-side. In that case just add the dependency to the pom as usual.

 

Cargo Maven Plugin – Functional Testing March 1, 2011

Filed under: Java — nicozan @ 3:10 pm
Tags: , ,

Introduction
The main idea of this post is to help you and give you a set of steps to create en embedded web-app container where you can put different compiled modules inside it and run integration tests.

Container JAVA API:

Cargo has a Java API that allow as to start/stop/configure Java Containers and deploy modules into them. The objects related to this API are:

* Container: is the top level interface wrapping a real physical container. Cargo supports Local and Remote containers. (In this explanation we’ll be using Local Containers). A Container is composed of a Configuration.
* Configuration: tells the Cargo how the container is to configured (logging, security, data sources, location where to put deployables, etc). A Configuration can be configured to install Deployables before the containers is started.
* Deployer: it is used to hot-deploy Deployables. Hot-deploy means when you deploy a Deployable into a running container.
* Deployables: are archives (WAR,EAR,etc) that can be deployed into the container.

MAVEN 2 Cargo Plugin:
The plugin wraps the Cargo JAVA API and from various types of use cases of it, we’ll explain how to start and stop a container, including deploying some deployables as it starts.
As we said before we’ll run an embedded container.The most basic container you can use in cargo is an Embedded Jetty 4x/5x/6x Container. The following maven 2 plugin definition will configure an embedded Jetty 6x container. Note the use of the embedded type element to specify an embedded container.

[...]
<build>
  <plugins>
     <plugin>
         <groupId>org.codehaus.cargo</groupId>
         <artifactId>cargo-maven2-plugin</artifactId>
         <version>1.0.6</version>
         <configuration>
             <container>
                   <containerId>jetty6x</containerId>
                   <type>embedded</type>
             </container>
         </configuration>
     </plugin>
  </plugins>
</build>
[...]

Before we continue please remember that the code snippet from above goes in your pom.xml and that if you don’t specify the value the embedded container we’ll be Jetty 5.X.

Now it is time to start deploying our deployables. The deployables are archives (i.e. EAR and WAR) that can be deployed in the container. The code snippet below shows how to deploy deployables in an embedded container, in this case jetty:

<dependencies>
[...]
   <dependency>
       <groupId>com.wordpress.nicozan</groupId>
       <artifactId>my-war</artifactId>
       <version>1.0.0</version>
       <packaging>war</packaging>
    </dependency>
[...]
</dependencies>
[...]
<build>
  <plugins>
     <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <version>1.0.6</version>
        <configuration>
             <container>
                   <containerId>jetty6x</containerId>
                   <type>embedded</type>
             </container>
            <configuration>
                      <type>embedded</type>
                      [...]
                      <deployables>
                            <deployable>
                                  <groupId>com.wordpress.nicozan</groupId>
                                   <artifactId>my-war</artifactId>
                                   <type>war</type>
                             </deployable>
                      </deployables>
            </configuration>
       </configuration>
     </plugin>
  </plugins>
</build>
[...]

Okay, let’s talk about the tags we have seen above. As we can see, we have specified the that represents our . You might have noticed that the dependency tag and the deployable tag have almost the same properties. The property that they don’t share is the version. This is because cargo gets the version information from the dependency declaration at the moment it has to deploy the deployable.

When do we use Cargo?

Imagine that you have a Web App,in Java obviously using the maven archetype. This Web Application is divided in two modules: Client and Server. The hierarchical structure of the project would be like this:
MyWebApp (pom.xml)
—> Client-Module (pom.xml)
—> Server-Module (pom.xml)
Up to now we see a very common structure of a project, but cargo empowers the use of an extra module to start the Functional Testing. We’ll add the module Deployer to our project structure.
MyWebApp (pom.xml)
—> Client-Module (pom.xml)
—> Server-Module (pom.xml)
—> Deployer-Module (pom.xml)
In the Deployer-Module you have to modify its pom.xml and write a configuration similar to the one written in code snippets above, it should be something like this:

  
<dependencies>
[...]
<dependency>
  <groupId>com.wordpress.nicozan</groupId>
  <artifactId>Client-Module</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
</dependency>
<dependency>
  <groupId>com.wordpress.nicozan</groupId>
  <artifactId>Server-Module</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
</dependency>
[...]
</dependencies>
[...]
<build>
  <plugins>
    <plugin> 
         <groupId>org.codehaus.cargo</groupId>
         <artifactId>cargo-maven2-plugin</artifactId>
         <configuration>
             <container>
                   <containerId>jetty6x</containerId>
                   <type>embedded</type>
             </container>
             <configuration>
                  <type>embedded</type>
                  [...]
                  <deployables>
                            <deployable>
                                  <groupId>com.wordpress.nicozan</groupId>
                                   <artifactId>Client-Module</artifactId>
                                   <type>war</type>
                             </deployable>
                    <deployable>
                                  <groupId>com.wordpress.nicozan</groupId>
                                   <artifactId>Server-Module</artifactId>
                                   <type>war</type>
                             </deployable>
                  </deployables>
             </configuration>
         </configuration>
    </plugin>
  </plugins>
</build>
[...]

Hope this helps you to understand the main idea of cargo. If you are interested in improving your ways of building a web app, you can have a look at Leandro’s post that explains how to create web app using SmartGwt.

 

Drools-Guvnor – Spring Context Feature February 3, 2011

Filed under: Drools — nicozan @ 5:00 pm

Introduction

Drools-Guvnor has now the possibility to create, modify and delete Spring Context Files. This new feature allows you to define Drools Knowledge Bases, Knowledge Sessions, Knowledge Agents and Common Spring Beans inside your Spring Context File.

How to Create a Spring Context in Guvnor

You have to go to the Knowledge Bases Tag on the Left Menu and select:
Create New —> New Spring Context.
Like any other asset you will have to give it a name and set in which package it’ll be saved.

It is time to Edit our Spring Context

The next image shows the SpringContext Editor. You will be able to insert new tags in this XML file, by positioning your text cursor in the place where you would like to insert this new tag and then click on one of the options on the left palette. (KSession, KBase, Node, KAgent, Spring Bean)

Another feature of the SpringContext editor is that we can validate our XSD file against the XSD file implicitly referred in the Spring Context File. All you have to do is go to : Source—> Validate.

Adding New Buttons to our Palette

If you want to add new buttons to your palette, Drools Guvnor allows you to do this through a Properties File. The name of the file is springContextElements.properties, it’s located in the path:$GUVNOR_HOME/WEB-INF/Clases/springContextElements.properties.

Downloading The Spring Context Files

Each spring context is exposed through an URL. These URLs could be found at the bottom part of the Package editor where the context files are defined.

Stay tuned for updates related to Drools… ;), this new feature is now in the trunk, in Drools 5.2.0.M1. 🙂

 

GWT – Asynchronous RPC January 14, 2011

Filed under: GWT,Java — nicozan @ 1:28 pm

Most semi-complex WebApps have a back-end server. GWT give us the possibility to interact with the server-side using RPC (Remote Procedures Call). I’ll explain how it works through an example:

On the client-side, we have 2 Interfaces that will be the key to our communication with the server-side.

BankClient.java

package com.wordpress.nicozan.client;
import com.google.gwt.user.client.rpc.RemoteService;
public interface BankClient extends RemoteService {
  public String askForLoan(String s);
}

BankClientAsync.java

package com.wordpress.nicozan.client;
public interface BankClientAsync {
   public void askForLoan(String s, AsyncCallback<String> callback);
}

The nature of asynchronous methods requires the caller to pass in a callback object that can be notified when an asynchronous call completes, since by definition the caller cannot be blocked until the call completes. For the same reason, asynchronous methods do not have return types; they generally return void. Should you wish to have more control over the state of a pending request, return Request instead. After an asynchronous call is made, all communication back to the caller is via the passed-in callback object.

On the server side we just have 1 class, that implements the methods of the BackClient interface.

Bank.java

package com.wordpress.nicozan.server;
import com.google.gwt.user.server.rpc.RemoteServiceServlet;
import com.wordpress.nicozan.client.BankClient;
public class Bank extends RemoteServiceServlet implements
    BankClient {
  	public String askForLoan(String s) {
			if (Integer.parseInt(s) <= 1000){
				System.out.println("granted");
				return new String("Loan Granted");	
		 	}else{
		 		System.out.println("Deny");
		 		return new String("Loan Denied");
		 	}

        }
}

It is very important to take into consideration the suffix Async and argument referencing the AsyncCallback. The relationship between service interface and its asynchronous counterpart must follow certain naming standards. If the naming standards aren’t applied the GWT compiler won’t generate the proper code to implement RPC.
The service interface and the asynchronous interface must be in the same package. Each method in the asynchronous service interface must have a corresponding method in the asynchronous service interface with an extra AsyncCallback parameter as the last argument.

Up to now we have defined all the necessary elements, but how should we use them?. Usually in common WebApps we have to define and map our servlet in the web.xml file:

...
<servlet>
   <servlet-name>bankServlet</servlet-name>
   <servlet-class>com.wordpress.nicozan.server.Bank</servlet-class>
   <load-on-startup>1</load-on-startup>    
</servlet>
  
<servlet-mapping>
    <servlet-name>bankServlet</servlet-name>
    <url-pattern>/bankServlet</url-pattern>  	
</servlet-mapping>
  	
<servlet-mapping>
   <servlet-name>bankServlet</servlet-name>
   <url-pattern>/com.wordpress.nicozan.Application/bankServlet</url-pattern>
</servlet-mapping>  	
...

Please remember that one servlet can be mapped in more than one URL, no the other way around. GWT needs an other definition of the servlet in the Module Configuration File,”Application.gwt.xml” :

…      
<servlet path="/bankServlet" class="com.wordpress.nicozan.server.Bank"/> 
...

Nothing further to say, thanks for reading it. I hope it helps.. 😀

 

GWT (Google Web Toolkit) Framework – Basic Concepts to do things well. January 11, 2011

Filed under: GWT,Java — nicozan @ 3:04 pm

As you might know there are various frameworks that give us the chance to develop Web Applications using the Java language. For example Seam, Wicket or JSF. But today I’ll be showing the basic concepts of the Google’s framework to develop Web Applications, GWT.

MODULES and ENTRY POINTS

The GWT web apps are called MODULES. A module “myModule” is described by a configuration file “myModule.gwt.xml”. Each module can have one or more Entry point classes. An Entry Point class has the onModuleLoad() method that would be the main() method in analogy with a standard Java program.

Every single module is connected with a HTML page, which is called “host-page”. The code for a GWT web application executes within this HTML document. The UI components of the host-page can be placed into “div” containers. Other way of placing the UI components is by assigning them to the body of the HTML page. Some of the classes related to the placement of an UI component into the host-page are: VerticalPanel, HorizontalPanel and RootPanel (Body) amongst others.

Mostly, the web apps developed using GWT have ONLY ONE ENTRY-POINT and ONE HTML this is because one can changed the UI components dynamically by changing the WIDGETS and LAYOUTS.

WIDGETS and LAYOUTS

If you are not familiarized with the terms, here you have a simple definition of each one.

Layout: refers to the dimensioning of content in a device display. Layouts end up being visual content frameworks, that can be fixed, they can use relative measure units or they can provide fluid layout with proportional dimensions. The concept of the layout it’s a very wide and powerful one, because when we take the role of web designers we don’t know the size of the web browser window. The browser could be in a cellphone, Ipad, laptop amongst other devices. Thanks to layouts we don’t have to think for each case of window size.

Widget: is a stand-alone application. This Application can be embedded into third party sites by any user on a page in which they have authorship rights. For example, in personal blog you could a “Twitter Widget” to show all your tweets.

That would be all for the moment ;)…

 

Theoretical Background for Drools – Expert Systems – part 4 January 7, 2011

Filed under: Drools — nicozan @ 5:06 pm

Well, we have reach the part number four of these posts related with Expert Systems. In this post we’ll be seeing the concept of INFERECE and some METHODS OF INFERENCE.

INTRODUCTION

In the knowledge domain that it knows about, the expert system “reasons” or makes inferences in the same way a human expert would infer the solution of a problem. That is, given some facts, a conclusion that follows is inferred.

For example, if your spouse hasn’t spoken to you in months, you may infer that he or she had nothing worthwhile to say. However, this is only one of several possible inferences.

In a rule-based system, the inference engine determines which rule antecedents, if any, are satisfied by the facts. Two general methods of inferencing are commonly used as the problem-solving strategies of expert systems: forward chaining and backward chaining.

INFERENCE

Is the standard technique by which expert systems solve problems. Expert Systems are commonly used when an inadequate algorithm or no algorithmic solution exists and inference offers the only possibility of a solution.

Decision structures, like binary trees, can be mechanically translated into production rules. This can be easily be done by a breath-first searching of the structure and by generating IF…THEN rules at every node. The breath-first search begins at the root node and explores all the neighboring nodes. Then for each of those nearest nodes, it explores their unexplored neighbor nodes, and so on, until it finds a terminal node.

TYPES OF INFERENCE

There are many types: deduction, induction, intuition, heuristics, generate and test, abduction, default, auto-epistemic, nonmonotonic and analogy. The Commonsense knowledge could be a combination of any of these types. One of the most frequently used methods of drawing inferences is deductive logic, which has been used since ancient times to determine the validity of an argument. The meaning of argument in logic is a group of statements in which the last is claimed to be justified on the basis of the previous ones in the chain of reasoning.

Before we continue, we need to define one important term: Syllogism. Is a kind of logical argument in which one proposition (the conclusion) is inferred from two others (the premises) of a certain form.

Although Venn diagrams are a decision for syllogisms , the diagrams are inconvenient for more complex arguments because they become more difficult to read. Propositional Logic offers another means of describing arguments. In fact, we often use propositional logic without realizing it.
For example: If there is water and gas, I can cook the pasta. This argument can be expressed in a formal way by using letters to represent the proposition as follows:
A= There is water.
B= There is gas.
C= I can cook the pasta.

A ^ B —> C

The representation above, it might look familiar to you. Because it’s a representation of knowledge using production rules, like we explained in a previous post.

METHODS OF INFERENCE

Chain: a group of multiple inferences that connects a problem with its solution.
Forward Chain : a chain that is searched or traversed from a problem to its solution. Another way to describe it is, reasoning from facts to the conclusions that follow from facts.
Backward Chain: a chain that is traversed from a hypothesis back to the facts that support the hypothesis.

Some Characteristics of Forward and Backward Chaining:

FORDWARD CHAINING BACKWARD CHAINING
Planning, monitoring , control Diagnosis
Present to future Present to past
Antecedent to consequent Consequent to antecedent
Data driven, bottom up reasoning. Goal driven, top-down reasoning
Work forward to find what solutions follow from the facts. Work backward to find facts that support the hypothesis.
Breath-first search facilitated Depth-first search facilitated
Antecedents determine search Consequents determine search
Explanation not facilitated Explanation facilitated (Very Important in Exp Systems)

CONCLUSIONS

-Term inferencing is generally used for mechanical systems such as expert systems. Reasoning is for human thinking.
-The result of the inference depends on the knowledge base (rules) and the information we obtain from the real world (facts).
-The inferencing doesn’t pass rule by rule sequentially, like an algorithm that has a sequence of steps to reach an objective.