Blogs

A while back we partnered with Gigline Software to create JSF components based on our Complete UI suite. So to coincide with JavaOne, we have a preview build available to download (and by we, I mean Eric from Gigline. Great job!): Preview Release with live samples hosted at Gigline: http://giglinesoftware.com/NitobiJSFWeb

This preview release already has some nifty features. All the Nitobi JSF tags support value exressions on all attributes (save for the id attribute). Also, all the javascript and css files are bundled in the jar and will be loaded by the component automatically. Plus, there is a JSF tag for the Callout component allowing you to declaratively bind a Callout panel to a DOM element.

This is but a taste of things to come. Here’s what we’re trying to get into the final build, due for our forthcoming Q3 release:

• Make all data-dependent components able to populate through managed beans.
• Create a phase listener for all data-dependent components to handle parameters and simplify a bit.
• Get the rest of the components JSF compatible (including the new Tree Grid component).
• Short hand JSF tags that will allow developers to combine existing components together, without the need to muck about with javascript.

So for you JSF devs out there, give it go and let us know what you think!

So as promised, here is some more Java love in the form of an Eclipse plugin and a Struts 2 plugin.

Files
Eclipse Plugin 0.8 (This is plugin uses the trial versions of the components)
Struts 2 Plugin 0.8
Nitobi Taglib 0.8 (some small kinks worked out)
Nitobi Server Library 1.0.1 (This updated library (used to be called nitobicomponents.jar) is needed for the Struts 2 plugin)

Eclipse Plugin
This plugin is built on top of WTP (1.5.3) extension points and provides some custom project facets when creating a new Dynamic Web Project. It will copy over the needed script and style files to resources/nitobi/script and resources/nitobi/style in the root of your web content directory. It’ll also copy over the Nitobi Taglib and Nitobi Server Library jars to your project build path.

We’ve also added some contributions to the Snippet palette. Dragging a snippet to an open editor will insert a small, demonstrative declaration that will usually render without modification. I say “usually” because of course you’ll need to do some lifting of your own if you want to have the component bound to remote data.

Struts 2 Plugin
I put up a knowledgebase article on using Grid in Struts 2 and I realised while writing it that we could help simplify the process. So I put together a simple, but hopefully useful plugin which provides a Nitobi result type.

To use the result type, you need to declare a package in your struts.xml file that extends “nitobi-default” and your get handler action needs to specify a result type of “nitobi”. Par example:

<struts>
  <package name="grid" extends="nitobi-default">
    <action name="gethandler" class="example.GetHandlerAction">
      <result name="success" type="nitobi">
        <param name="encoding">UTF-8</param>
        <param name="handlername">gethandler</param>
      </result>
    </action>
  </package>
</struts>

Note that the result can take two optional parameters: encoding and handlername. The encoding attribute is used to set the encoding of the response. The handlername attribute is the name of your Action’s GenericGetHandler/GenericSaveHandler member variable that the Result will look for in the Value Stack. So, if in your Action you have a GenericGetHandler declared as such:

// You also need to declare a public getter for this member
// to make it available to the Result on the Value Stack.
GenericGetHandler monHandler;

You need to specify this using the handlername parameter. By default, encoding will be set to UTF-8 and handlername is set to handler.

There may be some kinks yet to work out so bear with me! We’ve got some improvements to the server library on tap and hopefully a NetBeans module too. Again, any feedback on this stuff would be most appreciated and will be reciprocated with a virtual, yet vigorous, high-five.

I just wanted to quickly point out a small difference between the new taglib we introduced last week and our regular, non-jsp tags. Most of the tags look the same, but for unbound Grids and ComboBoxes, the data elements are a bit different. For the taglib, instead of specifying data as attributes, there is a single data attribute that takes a JSON object. For example, the <e> element looks like this in the taglib:

<n:e data="{'xi' : '0',
             'a' : 'Mick Jones',
             'b' : 'Topper Headon',
             'c' : 'Joe Strummer',
             'd' : 'Paul Simonon'}"></n:e>

And for those who are interested, there are new articles in the KB describing how to set up a databound Grid in Struts 1 and Struts 2.