Here are some of my best practices which I would have loved to have had in place from the beginning. They would have saved a lot of time and reduced bugs…

Use id based Equality
This is contrary to a lot of the typical recommendations but I don’t see a problem with it. It means that you have a working equality method without any further effort. Furthermore, you have a guaranteed equality, the same equality that the database uses. There are some issues with this when it comes to one-to-one relationships, but those can be resolved by adjusting the equals method. The other issue is that there are instances where there is no business based unique key.

Don’t use auto generated Keys
So in your model classes set the id. This will mean you need another field as a persistence marker. The fundamental reason for this, coupled with the fact that you’re using the id for equals, is that you have immediate equality, both prior to persisting the object and in your tests. By using auto generated keys you you have to wait until the object is persisted before its equals method works. You cannot thus use it in a set prior to persistence, and when you run tests you have to manually set the id every time you create the object.

Use instrumentation
Hibernate has an issue (a big issue IMHO) that if you execute the following code (Person is set to be Lazy loaded).

Person p = session.load(Person.class, id);
ContactDetails cd = p.getContactDetails();

And on the database that particular object (contact details) is actually a subclass of ContactDetails called AddressDetails, the real type of the variable cd will be ContactDetails and _not_ Address Details as you would have expected. In order to get the real type you have to do first ask hibernate for the real type of the object and then call load again with that real type. So in order for the variable cd to be the correct type you would require the following code:

Person p = session.load(Person.class, id);

ContactDetails cd = p.getContactDetails();
cd = (ContactDetails)load(id, Hibernate.getClass(cd));

An extra line is required.

Instrumentation however injects code into the compiled class of ContactDetails and intercepts the call to getContactDetails to add the bit to load the real type. It’s a small little ant job that runs within the context of our IDE and sorts it all out.

Use Field access over method access
Unfortunately, I only discovered that hibernate had the ability to directly act on the fields rather than go via methods too late to make use of this ability. It would have enabled me to setup some nice validation and/or side effects on the setting of a value in a hibernate managed object. I’m sorry I didn’t do it earlier. This is a practice which I have thus not been able to test, it does sound like a good idea but maybe there are other issues I do not know about.

Think hard about your Cascades
Hibernate is not good at saving a whole object tree in one go. The problem is that as soon as any sql is executed on the database, the sql is validated against the state of the database. So any constraint violations are immediately raised. If you think hard on the cascades the ability so save whole trees is significantly improved though it is not totally enabled. One obvious practice is that if it has a not-null constraint the cascade must be set. If this is not set unless you save the foreign object before the local one you will get a constraint violation. The objects go together (thus the not-null) so the cascade should be on.

The above recommendations are fairly generic to any project that uses hibernate in the real world. There’s a few that I’ve learnt on this project that are specific to a high performance and high concurrency web application…

Prefer trawling the object model over running queries
The kind of application we have is one where a user would login and probably send on average 10 – 20 minutes on the web site. Thus we would typically have a lot of the objects they require in cache already. Thus when you need to find some data for the person concerned it is a lot better to simply trawl the objects rather than use a hibernate query. The reason for this is twofold..

• Querying in hibernate always causes a flush. Data is therefore written to the database at a time when it shouldn’t necessarily be. Even though you know the query does not touch any of the pending writes, the flush will still happen.
• A data connection is made. On our application we gained significant performance concurrency improvements by removing queries – the objects were already in the cache in any case. Where we had deadlocks we simply removed the query from the equation (changed to trawling the model) and the deadlocks were significantly reduced.

Make everying lazy
On our application where isn’t a single relationship which is not lazy. We can’t think of a case where having lazy off would be useful to us. Yes, I understand that it means the first read will be slow, but after that it’ll be in the cache so it will be fast. If lazy is off even if the object is in the cache it will still load that object from the cache

In other words, if you have an object A which has a reference to object B and the reference is specified as non lazy. When you load A it will _always_ load B even if you don’t go near B. Even if B is in the cache it will still load B from the cache. On our application we have a lot of static data. This static data was initially set to be lazy disabled (prefetching). Then we would preload all this static data. We found that the preload was very slow – even though it was coming from the cache – because it would have to load the root object plus all the non lazy relationship stemming from that object.

Consider the reusability of the following code:

Let’s say you want to iterate on the results, the following code would throw a NullPointerException if used in conjunction with the code above:

Iterating on an array is one of the most commons practices in Java, so returning null instead of an empty array means the person is going to have to do extra null checks when they really don’t need to. In this situation, an empty array would suffice and would not produce any errors.

To summarize, it makes the code shorter, easier to read, and less likely to throw a NullPointerException. Also, there is some confusion with returning null since you may (or may not) be saying an empty array is the same thing as null. For example, the following would be confusing logic:

In this situation its not clear why you might act differently on the two return values and this can lead to confusing, ambiguous code.

The only time I might consider returning null valid is if there was an error of some kind, but then you should be throwing an exception (something more programmers are hesitant to do). Think of it like this, would you rather read a stack trace with a detailed error what went wrong in the code created by you, or would you rather see NullPointerException and wonder what of a dozen objects might have been null?

Fiji is a framework that provides the following:

• A library of ready-to-use Flex charting components for JSF
• A universal wrapper that allows the use of any Flex component within a JSF page
• Most importantly, with Fiji, you can bind Flex components to the same JSF-managed beans properties or methods (or Seam components or Spring beans) used by the rest of your JSF application.

The current version ships with the following ready-to-use charts:

• Column chart
• Stacked column chart
• Bar chart
• Stacked bar chart
• Line chart

For example, here is a screen shot of a Flex component inside a JSF page

You can see all Fiji components in action at http://livedemo.exadel.com/fiji-demo

Now that I have given you a short introduction to Fiji, you are probably wondering what problem Fiji is trying to solve. Let’s see.

Why Fiji?

Let’s start with the basics. JavaServer Faces (JSF) is a standard (Java EE) framework for building Web user interfaces out of components. Today, we are interested in building Rich Internet Applications, so RichFaces was created takes JSF a step further by allowing the easier building of AJAX-based applications in JSF. (In case you don’t know, RichFaces offers a large number of ready-to-use AJAX components.)

While JSF has been constantly growing, one area where it’s still lacking is in displaying rich and interactive charts, graphs, and other similar visuals. Even with AJAX, any serious charting is extremely difficult, not to mention the testing that would be required for different browsers. It really comes down to two things. First, the technologies used behind JSF such as HTML, JavaScript, and CSS are not meant for displaying rich and interactive visual data (possible, but very difficult). Second, people have much higher expectations from a browser. The browser alone was never meant to display such visual data. It was primarily meant to display text and static images. So, in the end, it’s not really JSF’s fault, we are simply asking the underlying technologies (HTML, JavaScript, CSS, the browser) to do too much.

Of course, there is hope. We can use a Flash player to display rich and interactive charts.

Adobe Flash

With Flex, complex rich applications can be compiled and then run inside a Flash player. A Flash player is a virtual machine that installs as a plug-in into any browser. Because the application (built with Flex) is running inside a virtual machine, it provides a far more superior environment for rich and interactive charts and graphs than the browser alone (which just interprets HTML, JavaScript, etc.).

The obvious next question is: So, why not use Flex and JSF components together right now? While it’s possible to use Flex and JSF components inside the same page, the two technologies are not aware of each other. This means that JSF components are bound to JSF managed beans (or Seam components or Spring beans) while Flex is bound to completely different objects. This kind of integration is equivalent to inserting an image into a JSF page – in other words, not much integration.
Back to Fiji

This is a good place to revisit Fiji. Fiji is the perfect fit for helping with the above problem. Not only does Fiji provide ready-to-use chart components and a universal wrapper to use any Flex component, but, with Fiji, you can bind Flex components to standard JSF managed beans. As a JSF developer, you just use the standard and the familiar JSF component-centric approach, while now also being able to use Flex components.

So, where does it make sense to use Fiji. One scenario is if you have an existing JSF application and you would like to insert richer content based on Flash while still using your existing model (JSF managed beans, Seam components or Spring beans). This content can be charts, graphs or any other rich content.

Another situation where Fiji would make sense is where you have an existing JSF application, but want to use a Flash-based user interface (instead of HTML/JavaScript). By using Fiji, you can still use the existing model part of your application.

However, to be honest, it wouldn’t make sense to use Fiji if you have an existing Flash-only application and are using a service like GraniteDS, BlazeDS, or Exadel Flamingo.

There are three basic steps to get started.

1. Download project template
2. Download JAR file and add them to project template
3. Open the project in your favorite IDE

Download Project template

Download and unzip the project template. <link>

Download Fiji JAR files

1. Go to http://exadel.com/web/portal/fiji and click on Download to download Fiji distribution
2. Unzip the downloaded file
3. In the next step you are going to copy JAR files from lib folder to fiji/web/WEB-INF/lib directory
   1. If running Tomcat 5.5, copy all files
   2. If you are running Tomcat 6, copy all files except:
   ¦ el-api.1.0.jar
   ¦ el-impl-1.0.jar

Import Project

Import the project into your favorite IDE. Here is how to do it in JBoss Tools (same steps for JBoss Developer Studio).

1. Select File/Import
2. Select Other
3. Select JSF Project
4. Point to the web.xml file location in the project
5. Click Next
6. Keep all setting as they are (I’m assuming you have a server defined)
7. Click Finish

To tell you the truth, installing Fiji is very simple. It’s basically a RichFaces project (has to be RichFaces version 3.2.2 or higher) plus the JAR files for Fiji:

• fiji-api-1.x.x.jar
• fiji-ui-1.x.x.jar
• flamingo-service-jsf-1.6.x.jar – to use HttpService via <fiji:endpoint> component. Covered later in article.

Besides using HttpService, if you would like to use DataServices (AMF format), you need two additional JAR files:

• amf-serializer-1.6.x.jar

That’s it. Nothing else is needed, not even changes to web.xml.

Using Bar Chart

Let’s start with a simple example using bar chart. The first step is to create the data for the chart. Because we can easily bind charts to JSF managed beans, that’s where we are going to create our data.

The Java bean looks like this:

public class BarChartBean {
 public BarChartBean() {
 }
 private Integer[] data;

 public Integer[] getData() {
  return data;
 }
 @PostConstruct
 public void init () {
  data = new Integer[5];
  data[0] = 5;
  data[1] = 2;
  data[2] = -3;
  data[3] = 10;
  data[4] = 9;
 }
}

To make it a JSF managed bean we need to register it in a JSF configuration file:

<managed-bean>
  <managed-bean-name>barChartBean</managed-bean-name>
  <managed-bean-class>fiji.BarChartBean</managed-bean-class>
  <managed-bean-scope>session</managed-bean-scope>
 </managed-bean>

So far this is just basic JSF. Let’s now create the page.

Open start.xhtml. Look at the top, the page already contains a namespace for the Fiji tag library. Insert the following between <body> tags:

<h:form>
 <fiji:barChart id="barChart" value="#{barChartBean.data}"
  title="Bar chart" width="500" height="300">
  <fiji:chartData type="name" value="Just some numbers" />
 </fiji:barChart>
</h:form>

<fiji:barChart> is just like a standard JSF component. The value attribute is bound to chart data inside the managed bean. <fiji:chartData type=”name”..> sets the chart name.

Save everything and run the page. You should get the following:

Let’s try another example, this time using column chart. I’m sure most of you still remember the Summer Olympics, so we’ll take the medal count and display it in the chart.

Using the column chart

You can reuse the same page or create a new page if you would like. If you create a new page, make sure to include the namespace for Fiji.

We are going to take the top three countries (USA, China, and Russia) and display their gold, silver and bronze medal count. As before, let’s start with data for the chart.
The Java bean looks like this:

public class MedalsBean {
    private  Map<String, Integer[]> medalsData = new LinkedHashMap<String,Integer[]>();
    private  ArrayList<String> colors = new ArrayList<String>();
    private  ArrayList<String> names = new ArrayList<String>();

    private Integer[] medalsChina = new Integer[]{51, 21, 28};
    private Integer[] medalsUSA = new Integer[]{36, 38, 36};
    private Integer[] medalsRussia = new Integer[]{23, 21, 28};

    @PostConstruct
    private void init() {
    	medalsData.put("China", medalsChina);
    	medalsData.put("USA", medalsUSA);
    	medalsData.put("Russia", medalsRussia);

        names.add("Gold");
        names.add("Silver");
        names.add("Bronze");

        colors.add("#DAA520");
        colors.add("#C0C0C0");
        colors.add("#B87333");
    }

    public Map<String, Integer[]> getMedalsData() {
		return medalsData;
	}
	public ArrayList<String> getColors() {
		return colors;
	}
	public ArrayList<String> getNames() {
		return names;
	}
	public Integer[] getMedalsChina() {
		return medalsChina;
	}
	public Integer[] getMedalsUSA() {
		return medalsUSA;
	}
	public Integer[] getMedalsRussia() {
		return medalsRussia;
	}
}

Because we now display three bars per country (one for each medal), we use a Map object and inside it put an array of integers representing the medal count.

To make it a JSF managed bean, we need to register is in a JSF configuration file:

<managed-bean>
  <managed-bean-name>medalsBean</managed-bean-name>
  <managed-bean-class>fiji.MedalsBean</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
 </managed-bean>

Now we are ready to build the page. The page is not much different than in the first example:

<h:form>
<fiji:columnChart id="goldMedals" value="#{medalsBean.medalsData}"
   legendPosition="top"
   barColors="#{medalsBean.colors}"
   width="250" height="300">
	<fiji:chartData type="name" value="#{medalsBean.names}" />
</fiji:columnChart>
</h:form>

Running the page will produce the following:

fiji3

While the integration with JSF is neat (we can easily use JSF managed beans as a data model for Flex components), we can even take it a step further. It’s possible to click on a Flex chart, send an AJAX request and do a partial page update. Let’s see how it’s done.

Event handlers

Fiji components have event handlers such as onitemclick which are very similar to the standard DHTML event handlers such as onkeyup. Going back to our example, let’s say we want to click on any bar and display the medal information outside the chart. When a bar is clicked, an AJAX request will be sent to the server, properties will be set, and then rerendered.

The changes to the managed bean are minimal. All we do is add three properties:

private String countrySelected;
private String medalTypeSelected;
private String medalCountSelected;

// getter and setters methods

Don’t forget to generate getters and setters.

This is how our page now looks.

<h:form>
<fiji:columnChart id="goldMedals" value="#{medalsBean.medalsData}"
   legendPosition="top"
   barColors="#{medalsBean.colors}"
   width="250" height="300">
	<fiji:chartData type="name" value="#{medalsBean.names}" />
             <a4j:support event="onitemclick" reRender="info">
   	     <a4j:actionparam name="param1" value="event.x"                         assignTo="#{medalsBean.countrySelected}" noEscape="true"/>
		<a4j:actionparam name="param2" value="event.y" assignTo="#{medalsBean.medalCountSelected}" noEscape="true"/>
		<a4j:actionparam name="param3" value="event.name" assignTo="#{medalsBean.medalTypeSelected}" noEscape="true"/>
   	</a4j:support>
</fiji:columnChart>
</h:form>

<h:panelGrid id="info">
	<h:outputText value="#{medalsBean2.countrySelected}"
			style="text-decoration: underline;"/>
	<h:outputText value="#{medalsBean2.medalTypeSelected}
				   #{medalsBean2.medalCountSelected}"/>
</h:panelGrid>

We use the most popular tag from RichFaces, <a4j:support> to attach an event (onitemclick) to the parent component, <fiji:columnChart>. When a bar is clicked on a chart, an Ajax request is sent to the server passing three arguments defined by the <a4j:actionparam> tag. The <a4j:actionparam> tag automatically takes the value from value attribute and assigns it to property defined in the assignTo attribute. The following three arguments are passed:

event.x – is the x-axis data. In our case, it is the country name
event.y – is the y-axis data. In our case, it is the medal count
event.name – is the the active bar. In our case, it will be the medal type selected

I have also set noEscape=”true” for each <a4j:actionparam>. This is necessary in order for the value to be treated as JavaScript code instead of being enclosed in single quotes and just passed to the server as a parameter.

Finally, we rerender the information inside the panel grid. As you can see, we are using standard RichFaces techniques to send and rerender information even though we are mixing in Flex components.

Using the universal wrapper

So far I have shown you how to use charting components that ship with Fiji. Obviously you might want to use other, existing Flex components or maybe even build your own. To use any other Flex components, we use the universal wrapper or <fiji:swf> component.

We will use one of the charts provided by amCharts.com.
Note: We can use their charts for free. The only limitation is that a small URL will appear pointing to their Web site. I don’t think it’s such a limitation for such nice charts.

The SWF file for the chart as well as chart data are included in the template under web/ampie directory. You can also download them from here:

SWF file – ampie.swf <link>
Settings file – ampie_settings.xml <link>
Data file – ampie_data.xml <link>

The page looks like this:

<fiji:swf src="/ampie/ampie.swf" bgcolor="#FFFFFF" width="420" height="300">
   <f:param name="path" value="/ampie" />
   <f:param
       name="settings_file"
       value="#{facesContext.externalContext.requestContextPath}/ampie/ampie_settings.xml" />
 <f:param
     name="data_file"
     value="#{facesContext.externalContext.requestContextPath}/ampie/ampie_data.xml" />
 <f:param name="preloader_color" value="#999999" />
</fiji:swf>

Using the src attribute of <fiji:swf>, we point to a Flash component. The Flash component can also be loaded as a resource by using src=“resource:///file.swf”. This particular Flash component (ampie.swf) requires some data. The data is being passed using the standard JSF attribute, <f:param>. When a Flash object is rendered on a page, it has a special flashVars attribute that provides arguments to the Flash module. In our case, the <f:param> tags with their information are rendered as flashVar arguments to the Flash component. This is how the charts gets its data.

Running the page will produce the following:

In case you need to update the data for the chart, one possible way is to rerender the Flash component using the standard RichFaces approach.

Using <fiji:endpoint>

As a final example, I’m going to show you how to use <fiji:swf> together with <fiji:endPoint>. This will allow us to send a parameter from a Flash component to a JSF managed bean.

Let’s start with the Flash part. This is the Flex application we want to use in our JSF page:

hello.mxml:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:Script>
		<![CDATA[
			import mx.rpc.events.ResultEvent;
			import mx.rpc.http.HTTPService;

			private var userRequest:HTTPService;

	private function send():void {
                userRequest = new HTTPService();
                userRequest.url = Application.application.parameters.fiji;
                userRequest.addEventListener("result", httpResult);
                var param:Object = {};
                param["hello"] = username.text;
                userRequest.send(param);
            }
            public function httpResult(event:ResultEvent):void {
                if (event.result) {
                    helloLabel.text = event.result.value;
                }
            }
		]]>
	</mx:Script>

	<mx:Form x="22" y="10" width="280">
    	<mx:Label id="helloLabel" styleName="text"
    		      text="{Application.application.parameters.text}" />
        <mx:HBox>
            <mx:Label id="helloPerson" text="Username"/>
            <mx:TextInput id="username"/>
        </mx:HBox>
        <mx:Button label="Submit" click="send()"/>
    </mx:Form>
</mx:Application>

It’s a pretty simple MXML file which you can compile either in Flex Builder or just from the command line after installing Flex SDK

>mxmlc hello.mxml

I have also provided the SWF file inside the template (and here hello.swf <link>) in case you want to skip the compilation step.

The MXML file will produce the following:

[img_assist|nid=5017|title=|desc=|link=none|align=undefined|width=267|height=110]

Now, let’s look at the JSF page:

<h:form>

	<fiji:swf src="/hello.swf"

		bgcolor="#FFFFFF" width="350" height="200">

		<f:param name="text" value="Hello Fiji World"/>

		<fiji:endpoint name="fiji"

			decoder="fiji.HelloDecoder"

			encoder="fiji.HelloEncoder"

			service="#{serviceBean.greeting}"/>

</h:form>

<fiji:swf> is used to include the Flash component as we did before. The service attribute points to a JSF managed bean with a method called greeting:

public Object greeting(Object value){
		if(value != null){
			return "What's up, "+value+"?";
		} else {
			return "What's up, unknown?";
		}
	}

It also has to be registered in a JSF configuration file:

<managed-bean>
  <managed-bean-name>serviceBean</managed-bean-name>
  <managed-bean-class>fiji.ServiceBean</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
 </managed-bean>

I will cover HelloDecoder and HelloEncoder later.

When running this page, we will get something very similar to the previous image; however, now it’s inside a JSF page and, if we enter a value for Username and click Submit, we will get the following.

[img_assist|nid=5018|title=|desc=|link=none|align=undefined|width=271|height=118]

The question is, how are we able to send a request to the JSF managed bean from the Flash component? It’s done via the <fiji:endpoint> component:

<fiji:endpoint name="fiji"

			decoder="com.exadel.fiji.demo.simple.HelloDecoder"

			encoder="com.exadel.fiji.demo.simple.HelloEncoder"

			service="#{serviceBean.greeting}"/>

We define an endpoint with the name of fiji. If you look back at the MXML file, we have the following:

private function send():void {
                userRequest = new HTTPService();
                userRequest.url = Application.application.parameters.fiji;
                userRequest.addEventListener("result", httpResult);
                var param:Object = {};
                param["hello"] = username.text;
                userRequest.send(param);
            }

Inside the Flex component, the HTTP URL points to Application.application.parameters.fiji which in turn points to the Fiji endpoint defined in the JSF page by <fiji:endpoint> tag. When the Submit button inside the Flash is clicked, the URL is resolved. This is a standard JSF request and that’s how we invoke the serviceBean.greeting method inside a JSF managed bean. The URL is again passed via the flashVars attribute when the page is rendered.

Finally, the initial label value is set via

{Application.application.parameters.text}

Its value is set via this <f:param> tag:

<f:param name="text" value="Hello Fiji World"/>

Decoders and Encoders

First, why do we even need these decoders and encoders? Well, when using the Flex HttpService, the data is being sent to the server and returned in XML format. The JSF managed bean that we are using doesn’t know anything about XML. It simply returns a string value. So, in order to convert the request into a format that the managed bean understands, we use a decoder. When we invoke a method, the value returned has to be encoded in order for the Flash module to understand it. I know, it sounds complicated, but it’s really not.

The decoder shown below will be called by Fiji and the value returned will be passed to the greeting(Object) method inside a JSF managed bean. The decoder will just pull the value from the XML sent by the request.

public class HelloDecoder implements FlexDecoder , Serializable {

private static final String ENDPOINT_PARAM = “hello”;

public Object decodeRequest(FacesContext context, UIComponent component) {
return context.getExternalContext().getRequestParameterMap().get(ENDPOINT_PARAM);
}
}

When the greeting(Object) method inside the JSF managed bean returns a value, this encoder will be called to convert the response back to XML format.

public class HelloEncoder implements FlexEncoder {

private static final String VALUE = “value”;

public void encodeObject(FacesContext context, UIComponent component,
Object object) throws IOException {
ResponseWriter responseWriter = context.getResponseWriter();
responseWriter.startElement(VALUE, component);
responseWriter.writeText(object, null);
responseWriter.endElement(VALUE);

}
}

You can implement different encode and decode methods in case your Flash module requires the XML request/response to be in a specific format.

Orginal URL : http://java.dzone.com/articles/using-jsf-and-flex-components-?page=0%2C0

A resource can be reference via the EL using the following syntax:

#{resource['<resource name>']}

OR

#{resource['<library name>:<resource name>']}

Where and are both literals that map to a resource within the application. If using Facelets, it would be possible to output the resource URL directly without using a component:

<a href="#{resource['header.jpg']}" />;

The resource expression can also be used in h:graphicImage:

<h:graphicImage value="#{resource['corp:header.jpg']}" />;

That said, I do think the EL expression syntax is somewhat limiting (due to limitations of the EL itself). Consider theming. An application could have several themes partitioned as different resource libraries. In this situation it would be impossible to overload the library value of the expression without a custom ResourceHandler implementation.

However, it is possible to eschew the value attribute on h:graphicImage and specify a library and name attribute that accept expression to resolve the library and resource name dynamically.

Keep an eye out for the next blog entry where I’ll cover the expanded event system.

Orginal Link : http://java.dzone.com/news/jsf-20-new-feature-preview-ser-2

Several component and application level APIs have been added to enable a robust event system for component and application developers to take advantage of. Please note that this blog is based on EDR1 and as such the signatures of the APIs will change. When this is the case, I’ll try to remember to update the blog accordingly.

Let’s start with the changes to javax.faces.component.UIComponent.

public void subscribeToEvent(Class<? extends SystemEvent> systemEventClass,
                                                               ComponentSystemEventListener componentListener)

public void unsubscribeFromEvent(Class<? extends SystemEvent> systemEventClass,
      ComponentSystemEventListener listener)

public List<SystemEventListener> getListenersForEventClass(Class<? extends SystemEvent> systemEventClass)

The signatures are fairly straight forward. The API allows a developer to, on this single component instance, associate/disassocaite a ComponentSystemEventListener with some event type extending SystemEvent.   The method, getListenersForEventClass() is leveraged by the Application implementation when an event is published.

The other class central to the event system is javax.faces.application.Application. The following methods have been added:

public void subscribeToEvent(Class<? extends SystemEvent> systemEventClass,
                                                               Class sourceClass,
                                                               SystemEventListener listener)

public void publishEvent(Class<? extends SystemEvent> systemEventClass,
                                                       SystemEventListenerHolder source)

public void unsubscribeFromEvent(Class<? extends SystemEvent> systemEventClass,
                                                                          Class sourceClass,
                                                                          SystemEventListener listener)

The subscripbe/unsubscribe methods are similar to those define on UIComponent, however, these are application-wide instead of per-component.  It should be noted that an optional sourceClass can be provided so that the listener will only be invoked when the source of the event is of the configured type. I should note, that there is a two argument version of the subscribe and publish methods on Application that do not have sourceClass in their signature. These merely call through to the three argument version passing null as the sourceClass.

Now, publishEvent is where all the work happens. As currently spec’d, publishEvent will look for any listeners defined within the provided SystemEventListenerHolder (UIComponent implements this interface, hence the description of the methods on UIComponent) interested in the provided SystemEvent type. Following that, publishEvent will invoke any listeners interested in both the provided SystemEvent and source type. Lastly, publishEvent will invoke any listeners interested in received the specified SystemEvent type regardless of the source.

The spec includes several new events:

• AfterAddToParentEvent. This event will be published under the following circumstances:
  • When UIComponent.getChildren().add(childToAdd) is called (*)
  • When UIComponent.getFacets().put(facetName, facetChildToAdd) is called (*)
  • After the the view has been built
• BeforeRenderEvent. This event will be published when UIComponent.encodeBegin() is called.
• ViewMapCreatedEvent. This event will be published when UIViewRoot.getViewMap() or UIViewRoot.getViewMap(true) has been called (this is the basis for the new view scope).
• ViewMapDestroyedEvent. This event will be published by the default NavigationHandler when the view is being transitioned to a new view (i.e. the view IDs are not equal) and the view map has been used by the application

More events may be added by the time the JSF 2.0 specification is completed.

As you can see, the new event system is quite flexible and extensible enough to be adapted for many uses.  For example, the jsf-guessNumber2.0 demo application (to be included with the Mojarra 2.0.0 EDR1 release some time this week) leverages the BeforeRenderEvent to perform a hybrid of client/server-side validation.   Having this system in place also allows for another new feature which I will be discussing in the next entry, resource relocation. I won’t give too many details here, but resource relocation is the facility that allows stylesheets or scripts to be rendered in one of several locations independent of where actual tag was placed within the view definition.

Orginal URL : <a href=”http://java.dzone.com/news/jsf-20-new-feature-preview-ser-3″>http://java.dzone.com/news/jsf-20-new-feature-preview-ser-3</a>

MVC will be the overarching pattern for the macro level of our application. Additionally, we’ll use some other common object-oriented (OO) patterns on other levels because of the general benefits these approaches provide. For example, we’ll use the Observer pattern for event handling as part of the mechanism of communication between our model and our view. We’ll also use the Strategy pattern within the logic and operations parts of our model. We’ll provide more detail about each of these patterns, and the reasoning behind their use in each situation, as we come to those portions of the application.

The most important pattern we need to consider is MVC itself. This pattern is the most useful we have found for creating GWT applications, while still keeping them manageable and testable.

MVC and GWT

MVC is a familiar pattern to many developers. The pattern was first described in the late 70s by Trygve Reenskaug, who was working on Smalltalk at the time, and it has since been adopted, in various forms, by a wide range of programmers using many languages. The pattern is intended to separate responsibilities and allow for reuse of the logic and data portion of an application’ the model. The view layer represents the model graphically, as the UI. Delegation between these layers is handled by an intermediary that is invoked by the user’s input, the controller. The basic MVC pattern is shown in figure 1.

Figure 1 A basic model-view-controller architectural pattern diagram. The solid lines indicate a direct association, and the dashed lines indicate an indirect association, such as through an observer/observable relationship.

The key concepts to take away from MVC are the following: the model should be completely unaware of the view and controller, and the pattern can be applied on many different levels within an application.

In MVC, the model can be equipped to alert observers of changes within it, using the Observer pattern (something we’ll look more closely at in the section on communicating by observing events). This is shown by the dashed line in figure 1. In this way, any other layer observing the model can react to events coming from the model. Nevertheless, the model does not directly update the view, and this distinction is important. The model is the reusable part in all incarnations of MVC; if the model had any direct knowledge of the view, that tenet would break down. How the view and controller are linked together is often more variable.

The view typically has a reference to the controller, and may invoke controller methods directly, based on user input. The controller ideally will have no direct references back to the view, and should simply update the model. If the view is an observer of the model, this effectively updates the view without direct controller/view coupling. Alternatively, it’s also common to see situations in which the controller and view are treated as a pair, with direct references from the controller to the view.

There are many ways to divide up the responsibilities, and the various approaches have their pros and cons. The important part, though, is that the separation of responsibilities makes the code clearer, and often also makes testing easier. MVC can be applied with GWT, and it can happen on many different levels. An overall application may have a master domain, or model, and an overarching controller. Individual widgets can have their own encapsulated MVC, and small elements, such as a button, can repeat the pattern on their own level.

The possible variations of MVC, and many somewhat similar GUI architectural patterns, such as Presentation Abstraction Control (PAC) and Model View Presenter (MVP), are very interesting but are beyond our scope here. Fortunately, entire tomes on the subject exist. For our purposes, we’ll turn to concrete examples of MVC that we have found work well with GWT. To do this, we need to get into code and implement the pattern.

Creating a widget

The functional specifications for a calculator (at least a simple one) are fairly universal; they include a display, some buttons, and some mathematical operations defined by the likes of Pythagoras and Euclid. For our calculator, we’ll make use of one GWT TextBox for the display and many GWT Buttons for, well, the buttons. We’ll also use a layout derived from a Panel and a Grid to control the overall placement of the UI items. In terms of MVC, view elements are where all widgets begin, starting with the layout. The model and controller for our calculator will be implemented as separate classes that are referenced by the widget.

With GWT, you use widgets to create your application. These components are built from layout panels, input elements, events, data objects, and various combinations thereof. This is where GWT really departs from typical web applications and may seem somewhat foreign to those accustomed to standard server-side Java development. To create an application, you use widgets that are capable of being inserted or removed from the screen, in a single page, on the client side.

For our purposes, we’ll extend the GWT-provided VerticalPanel component to build our view, and then include references to our separate controller and model, as shown in the class diagram in figure 2.

Figure 2 CalculatorWidget top-level class diagram showing the extension of GWT’s VerticalPanel as the view, and the included model and controller references

It’s worth noting that figure 2 does not display all the attributes or operations of the CalculatorWidget class. We have included just a representative sample of attributes to keep it concise. The code for the CalculatorWidget will be displayed in three parts in listings 1, 2, and 3. Listing 1 addresses the beginning of the class, showing what the class needs to import and how the class is derived from, and makes use of, other existing GWT classes.

Listing 1 CalculatorWidget.java, part one:

package com.manning.gwtip.calculator.client;

import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.ClickListener;
import com.google.gwt.user.client.ui.Grid;
import com.google.gwt.user.client.ui.TextBox;          

//. . . remainder of imports omitted

public class CalculatorWidget extends VerticalPanel {
	private TextBox display;

	public CalculatorWidget(final String title) {
		super();

		final CalculatorData data = new CalculatorData();

	   final CalculatorController controller =
new CalculatorController(data);                           

//...

Within the first part of the CalculatorWidget class there are several important items. First of all, we’re making use of some existing GWT client.ui classes to compose our view . Our entire class is, in fact, a subclass of VerticalPanel . This is significant in that we inherit all of the hierarchy of a GWT UI Widget automatically with this approach.

Directly extending a panel in this manner is simple (in this case, intentionally so), but it’s also limiting. It’s often better to use a GWT Composite. We’re using direct subclassing here to keep things very basic, and we’ll move on to Composite in due course.

In listing 1 we then go on to define a simple constructor, and within it we create an instance of CalculatorController . CalculatorController itself will be addressed in the section on controlling the action, after we complete the CalculatorWidget class. The controller we’ll be using is a client-side component, which itself contains a reference to the data portion of our model, which is a single CalculatorData object. That takes us to part two of the CalculatorWidget class: layout and buttons. These view elements are displayed in listing 2.

Listing 2 CalculatorWidget.java, part two:

VerticalPanel p = new VerticalPanel();
p.setHorizontalAlignment(VerticalPanel.ALIGN_RIGHT);
p.setStyleName(CalculatorConstants.STYLE_PANEL);     

Grid g = new Grid(4, 5);
g.setStyleName(CalculatorConstants.STYLE_GRID);

final Button zero = new ButtonDigit(controller, "0");
g.setWidget(3, 0, zero);

final Button one = new ButtonDigit(controller, "1");
g.setWidget(2, 0, one);

final Button two = new ButtonDigit(controller, "2");
g.setWidget(2, 1, two);

//. . .

final Button divide = new ButtonOperator(controller, new OperatorDivide());
g.setWidget(0, 3, divide);

final Button multiply = new ButtonOperator(controller, new OperatorMultiply());
g.setWidget(1, 3, multiply);

//. . .

final Button clear = new Button(CalculatorConstants.CLEAR);
clear.addClickListener(new ClickListener() {
		public void onClick(Widget sender) {
				controller.processClear();
		}
	});
	clear.setStyleName(CalculatorConstants.STYLE_BUTTON);
	g.setWidget(2, 4, clear);

//...

In this second part of the CalculatorWidget class, we add components to our widget and add event handlers for those components. First, we create a GWT Grid , a component made of rows and columns that ultimately will be implemented as an HTML table. We’ll use this to lay out our calculator buttons. Then we add our two different types of buttons: ButtonDigit and ButtonOperator . The digits on our calculator are implemented by our own class, ButtonDigit, which extends the GWT Button class. The operators are similarly implemented by our own ButtonOperator class. Once again, for the sake of brevity, we have not included the code for all the fairly self-explanatory buttons and operators.

We have yet to create ButtonDigit and ButtonOperator, which we’ll do next, but the important thing to know at this point is that these classes both implement a ClickListener. This listener gets the control when the buttons are clicked, and it invokes a controller method. Listeners are common in component-oriented development and enable an event-driven approach. Various listeners, such as ClickListeners, OnChangeListeners, KeyboardListeners, and more are available in GWT. By using listeners in this way, the controller is notified to perform an appropriate action when any button or operator is pressed on our calculator.

About KeyboardListeners

In this example, we have not attached KeyboardListeners to our calculator, for brevity’s sake. But, obviously, including them would be very useful for a calculator. They can be enabled by setting a default focus element and then attaching the listeners.

Finally, we also add a standard GWT Button for both our calculator’s CLEAR and EQUALS functions. These buttons directly invoke methods on our controller instance without our own Button subclass. This is done with regard to CLEAR and EQUALS because these are special cases in terms of calculator buttons, as we shall see when we get to the controller in the next section. Before moving on, though, we need to implement the remainder of the CalculatorWidget, as shown in listing 3.

Listing 3 CalculatorWidget.java, part three:

// . . .

display = new TextBox();                                       

data.addChangeListener(new CalculatorChangeListener() {
	public void onChange(CalculatorData data) {
			display.setText(
			String.valueOf(data.getDisplay()));
			}
		});
	display.setText("0");
	display.setTextAlignment(TextBox.ALIGN_RIGHT);

	p.add(display);
	p.add(g);
	this.add(p);
	}
}

The final part of the CalculatorWidget class creates a GWT TextBox for our calculator’s display area , and then adds that component and our Grid to an earlier created VerticalPanel, which is in turn added to the current instance of itself. This ensures that all of the items are visible when CalculatorWidget is used .

Getting back to event handling, we have also introduced a custom listener’ our own CalculatorChangeListener interface . This is implemented as an anonymous inner class, and it connects our display widget (the view) to the data it represents (the model), through events.

These events are a manifestation of the Observer pattern. We’ll now take a closer look at this relationship, because it’s what facilitates the separate responsibilities in our MVC-powered GWT calculator.

We need to briefly elaborate on the event handling we have just introduced via CalculatorChangeListener. The general pattern, Observer, is how our calculator’s model and view will be connected. It’s also how default GWT components themselves generally communicate.

In addition to MVC, many developers will be accustomed to event handling. Some non-GUI programmers may also have realized the power of this approach and may be using it on the server side. If you’re already familiar with events, you may find our initial examples here primitive. This is because we’re trying to simplify and demonstrate the concepts, rather than to create the most efficient or streamlined code. (For example, we’re not using such standard Java event idioms as PropertyChangeSupport and related constructs.).

This approach should bring those who have not yet encountered event-based and asynchronous programming, especially in relation to a GUI, up to speed quickly. We’ll bring the pattern, itself, to the forefront with our first manually driven example. Listening for, and notifying of, events are all aspects of the Observer pattern. Figure 3 illustrates this pattern.

Figure 3 The Observer pattern, which is used in GWT to connect the model and view

In our example, the CalculatorChangeListener is used to register our view component (our CalculatorWidget itself) with the data portion of our model (CalculatorData). This is basically the first half of an observer/observable relationship between these components. Our change listener interface is shown in listing 4.

Listing 4 CalculatorChangeListener.java

public interface CalculatorChangeListener {
	public void onChange(CalculatorData data);
}

CalculatorChangeListener has a single callback method, onChange() . This is a fairly typical basic listener interface. Our CalculatorData model component, as we’ll see in a bit, makes itself observable (available for listeners to listen to) by implementing another simple interface, CalculatorChangeNotifier. This change notifier interface is shown in listing 5.

Listing 5 CalculatorChangeNotifier.java

public interface CalculatorChangeNotifier {
	public void addChangeListener(
final CalculatorChangeListener listener);
}

CalculatorData, as shown in listing 6, therefore carries out the other half of the observer/observable relationship and notifies any listeners that come along when things change.

Listing 6 CalculatorData.java: the data portion of the model layer:

public class CalculatorData implements CalculatorChangeNotifier {
private String display;
private double buffer;
private boolean initDisplay;
private boolean lastOpEquals;
private CalculatorChangeListener listener;

public CalculatorData() {
	this.clear();
}

public void addChangeListener(
final CalculatorChangeListener listener) {
	this.listener = listener;
}

public void clear() {
	this.display = "0";
	this.buffer = 0.0;
	this.initDisplay = true;
	this.lastOpEquals = false;
	if (listener != null) listener.onChange(this);
}

public double getBuffer() {
	return buffer;
}

public void setBuffer(double buffer) {
	this.buffer = buffer;
	listener.onChange(this);
}

public String getDisplay() {
	return display;
}

public void setDisplay(String display) {
	this.display = display;
	listener.onChange(this);
}	

//...

CalculatorData allows a single listener to register , and then, when its own setters are invoked, it notifies that listener of the change. Again, keep in mind that we have simplified the approach here. In the real world, as is the case with GWT’s own components that use this same pattern, you will likely see more than one listener attached to an observable in a collection, and hierarchies of specialized interfaces or abstract classes used for both observable and observer support (and you will need support to remove and clean up observers).

Along with the event mechanism, you probably have also noticed by now that the CalculatorWidget makes references to CalculatorConstants. This is a simple constants class that defines CSS styles and String constants such as: ADD, SUBTRACT, SQRT, and EQUALS. Now that we have our CalculatorWidget in place and our event handling taken care of, we’ll go back to the remainder of our example. This means we need to address ButtonDigit and ButtonOperator, where we’ll meet the other half of our model, the logic.

Operator strategy

As we saw in the code in the ‘Creating a widget’ section, CalculatorWidget makes use of several custom button types. The buttons of a calculator handle the numeric and operator input. Buttons are, of course, view components, but the buttons we’ll create to fill these roles are also backed by the logic portion of our model, our calculator’s operators. We have used our own specific Java types, ButtonDigit and ButtonOperator, so that we can easily distinguish the logical types of buttons pressed, and so that we can further encapsulate the logic for each operation. Listing 7 shows our ButtonDigit implementation.

Listing 7 ButtonDigit.java

public class ButtonDigit extends Button {
	public ButtonDigit(
	  final CalculatorController controller,
	  final String label) {
		super(label);
		this.addClickListener(new ClickListener() {
				public void onClick(Widget sender) {
					controller.processDigit(label);
				}
			});
		this.setStyleName(CalculatorConstants.STYLE_BUTTON_DIGIT);
	}
}

ButtonDigit is a very straightforward extension of the GWT Button class. It simply includes a CalculatorController object reference in its constructor , and then invokes the controller’s processDigit() method each time a ButtonDigit instance is clicked . This is a repeat of the pattern we’re using in the outer CalculatorWidget, using the same controller reference. This invocation is achieved via a ClickListener.

The primary point in this example, especially for server-oriented developers, is that extending the basic UI classes is not only possible, but desirable. Using OOP techniques to extend functionality allows for much cleaner separation and reuse of code. This is in contrast to HTML-based development, where the <input type=”button”> represents an opaque instruction. This fairly simple example just passes on a value, but you should note that the MVC pattern is present on multiple levels.

In listing 8 we see this pattern again with the ButtonOperator class. In this case, MVC comes into play on a micro level, while it’s also used on a macro level with the entire outer Widget. ButtonOperator has a model, represented by the label; a view, managed by the parent class of Button, tweaked by the designation of a style to the button; and a controller layer represented by an AbstractOperator instance, which translates actions up to the larger scope controller for the calculator widget.

Listing 8 ButtonOperator.java

public class ButtonOperator extends Button {
	public ButtonOperator(final CalculatorController controller,
		final AbstractOperator op) {
		super(op.label);
		this.addClickListener(new ClickListener() {
				public void onClick(Widget sender) {
					controller.processOperator(op);
				}
			});
		this.setStyleName(CalculatorConstants.STYLE_BUTTON_OPERATOR);
	}
}

ButtonOperator works in much the same way as ButtonDigit does. It extends the GWT Button class and includes a CalculatorController object reference in its constructor . Then it invokes the controller’s processOperator() method each time a ButtonOperator instance is clicked . The difference with ButtonOperator is that it includes a reference to an AbstractOperator class in its constructor.

Now that we have operator buttons, we obviously need operations to back these view components. To complete these components, we’ll use the Strategy pattern to encapsulate the logic. Rather than a monolithic if/else logic block, we’ll delegate each operation to a specified instance of an operator class (each an implementation of AbstractOperator) and let those classes update our calculator’s model. Using our operators in this manner makes our calculator easier to understand and allows for greater flexibility and extensibility. With this approach, we can add new operators later without affecting our existing logic. Figure 4 shows the Strategy pattern.

Figure 4 The Strategy pattern used in the GWT calculator example to implement operators

The only exceptions to this strategic structure for operators are the CLEAR and EQUALS operations, which are handled directly by the calculator controller, not by operator subclasses. Doing it this way requires less code and makes things a bit clearer. (We have some global state information in the controller that CLEAR and EQUALS rely upon. A purist implementation could put this information in our model and make separate operators for CLEAR and EQUALS as well, but that would complicate the other operations just for the sake of the pattern, and we think that would be overkill in this instance.)

These concepts may seem slightly off the beaten GWT path, but they serve to demonstrate the important point that you can use many OO design principles within the context of the toolkit. This flexibility is one of the advantages of GWT. In addition, this approach provides a much more robust calculator at the end of the day.

To handle the individual operators for our calculator, we need to implement the AbstractOperator and the subclasses that will extend it. As we saw in listing 8, ButtonOperator includes a reference to AbstractOperator. This is because each operator needs to do something different within a calculator application; each has a unique behavior. AbstractOperator, the straightforward beginning of the hierarchy, is shown in listing 9.

Listing 9 AbstractOperator.java

public abstract class AbstractOperator {
	public String label;

	AbstractOperator(final String label) {
		this.label = label;
	}
	public abstract void operate(
		final CalculatorData data);
}

AbstractOperator defines a single abstract method, operate(), which takes CalculatorData as input and updates it accordingly . We further divide operators with abstract types that determine whether or not the operator being implemented is binary or unary. BinaryOperator and UnaryOperator are as follows:

public abstract class BinaryOperator extends AbstractOperator {
	BinaryOperator(final String label) {
		super(label);
	}

public abstract class UnaryOperator extends AbstractOperator {
	UnaryOperator(final String label) {
		super(label);
	}
}

With our operator abstractions in place, we’ll now implement a simple concrete operator for addition. (We’ll not explicitly cover all the concrete operators used in our CalculatorWidget in the text for the sake of brevity). Listing 10 displays OperatorAdd.

Listing 10 OperatorAdd

public class OperatorAdd extends BinaryOperator {

	public OperatorAdd() {
		super(CalculatorConstants.ADD);
	}

	public void operate(final CalculatorData data) {
		data.setDisplay(String.valueOf(data.getBuffer() +
			   Double.parseDouble(data.getDisplay())));
		data.setInitDisplay(true);
	}
}

The binary addition operator adds the current buffer to the current display value, and then updates the display . Binary operators in this context are basically responsible for updating the display, based on the values in the CalculatorData object. Also, this operator sets the initDisplay status to true ; this indicates that, when the next digit is entered, the display should start over rather than append digits to any possible existing value. Now, with all of the other aspects of our CalculatorWidget in place, we can move on to the controller.

Controlling the action

The calculator’s controller handles the interaction between the other calculator components. The controller is called upon by the various buttons to perform actions such as invoking an operator or otherwise manipulating the model or internal state.

The GWT CalculatorWidget controller component is significant for several reasons beyond just the separation of responsibilities derived from the MVC pattern itself. We’ll write this component in Java, and it will be compiled into JavaScript by GWT along with our UI components, yet this has nothing to do with the interface. GWT allows you to create not only your UI but also any logic and data representations with client-side intentions. You can create classes, like we’re about to do with our CalculatorController and have already done with our CalculatorData, which end up in the client browser as completely non-view-related items.

In the CalculatorController, which is presented in listing 11, notice that there are no references to GWT-related classes.

Listing 11 CalculatorController.java

public class CalculatorController {

	CalculatorData data;
	AbstractOperator lastOperator;
	Private double prevBuffer; 

	public CalculatorController(
		   final CalculatorData data) {
		this.data = data;
	}

	public void processClear() {
		data.clear();
		lastOperator = null;
	}

	public void processEquals() {
		if (lastOperator != null) {
			if (!data.isLastOpEquals()) {
				prevBuffer = Double.parseDouble(data.getDisplay());
			}
			lastOperator.operate(data);
			data.setBuffer(prevBuffer);
			data.setLastOpEquals(true);
		}
	}

	public void processOperator(
				final AbstractOperator op) {
		if (op instanceof BinaryOperator) {
			if ((lastOperator == null) || (data.isLastOpEquals())) {
				data.setBuffer(Double.parseDouble(data.getDisplay()));
				data.setInitDisplay(true);
			} else {
				lastOperator.operate(data);
			}
				lastOperator = op;
		} else if (op instanceof UnaryOperator) {
			op.operate(data);
		}
		data.setLastOpEquals(false);
	}

	public void processDigit(final String s) {
		if (data.isLastOpEquals()) {
			lastOperator = null;
		}
		if (data.isInitDisplay()) {
			if (data.isLastOpEquals()) {
				data.setBuffer(0.0);
			} else {
				data.setBuffer(Double.parseDouble(data.getDisplay()));
			}
			data.setDisplay(s);
			data.setInitDisplay(false);
		} else {
			if (data.getDisplay().indexOf(
				   CalculatorConstants.POINT) == -1) {
				data.setDisplay(data.getDisplay() + s);
			} else if (!s.equals(CalculatorConstants.POINT)) {
				data.setDisplay(data.getDisplay() + s);
			}
		}
		data.setLastOpEquals(false);
	}
}

CalculatorController is instantiated with a new instance of CalculatorData . Along with the data object member, our controller also has four main actions: equals() and clear(), which are used for the calculator operations of the same names, and processOperator() and processDigit() , which are used when their respective operator buttons are clicked.

Controller actions, such as the pressing of a digit or an operator, update the model, which fires the corresponding events. When the data in the model changes, in response to actions from the controller, components that are registered to listen will be notified. Our view, CalculatorWidget, is one such component. The controller also contains a reference to the lastOperator so that it can make decisions about what to do in the chain of operations it provides. Figure 5 shows an overview of the classes involved in our now-complete MVC-enabled calculator project.

Figure 5 Overview of the classes involved with the GWT calculator example

This use of CalculatorController allows our client-side application, all by its lonesome, to handle state, logic, delegation, and the use of a separate model, along with the view. It’s important to remember this expression of the MVC pattern, and where the responsibilities lie. Java developers accustomed to the request-response cycle will be used to the view being rendered in a single, generally procedural action based on a single-state model. In GWT, as in well-designed desktop applications, the model can change independently of a singular view layer. This is notably different from a more transient view that performs a single operation and then goes away. Dealing with the state of the view, not just of the model, is something you will need to keep in mind during your development.

Now we have an event-driven GWT calculator in the form of a reusable CalculatorWidget. In addition, our code is fairly resilient to change and is extensible because we have used an OO approach with operators responsible for their own individual operations.

The compiled JavaFX Script plug-in is built in the same continuous build that compiled JavaFX Script is, so updates will be available frequently.  To get both NetBeans 6.1 beta and the compiled JavaFX Script plug-in, visit the OpenJFX Community site and check for the JavaFX Script Plugin Daily Builds Available news item.

Enjoy!
Jim Weaver
JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-side Applications
Immediate eBook (PDF) download available at the book’s Apress site

Link : http://java.dzone.com/articles/my-new-favorite-ide-compiled-j

* Oracle support
* MSSQL and Sybase support (experimental)
* Multithreading (experimental)
* SQL syntax highlight
* Query history
* TOAD-like schema browser
* Schema browser data filter
* Primary and foreign keys highlighting (experimental)
* Table creation interface (experimental)

Requirements:
Java 6.0

Screenshots:

Link : http://java.dzone.com/announcements/chronos-021-beta