jQuery dynatree adapter for JSF 2

Introduction

dynatree-for-jsf is a JSF 2 adapter for dynatree jQuery plugin (http://code.google.com/p/dynatree/). dynatree allows to dynamically create html tree view controls using JavaScript.

Why this adapter though Richfaces or Primefaces already implements> tree components ? Because dynatree has more features, is more mature, robust and is a prooven component.

Source code and sample are available on https://github.com/nithril/dynatree-for-jsf 
Sample is running on Cloudbees at http://dynatree.nithril.cloudbees.net/tree.jsf

Features

This adapter handles events for all of the dynatree events. All events can be mapped to JSF ajax events.
Here is a typical use of the adapter

onLazyRead and onActivate ajax events are binded to methods of the managed bean treeBean.

• lazyRead populates the tree dynamicaly.
• activate refresh a JSF panel with the selected node key.

All with Ajax.
This project does not include jquery, nor dynatree. You should include their by yourself.

Example

I have create an example with an infinite ajax tree
Browse to http://localhost:8080/tree/tree.jsf

Licenses

Apache License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0

 

Credits

Authors of dynatree, a great component. Authors of Primefaces and Mojarra, a source of inspiration on how to create an JSF 2 component with Ajax behaviour

Lucene Generic Highlighter

I have pushed on GitHub a projet on how to create a generic highlighter with Apache Lucene.

Original Lucene Highlighter is too much coupled with snippet highlighting and :

• Do not allow easily to highlight a whole text 
• Handles only text with a formatter strongly coupled to text 

 I have modified the original Lucene Highlighter to allow highlighting of "anything". The highlighter is a callback instead of a formatter and it's purpose is to find terms in a whole text with a score. I used this code to highlight XML, PDF, HTML... with or without Solr.

Note : This project is an extract of a large project with submodule.

Play! vs Spring MVC - View / Controller performance

Subbu Allamaraju posted an excellent article about Node.js vs Play! for Front-End Apps.

Play! is an excellent Web framework which is quite similar to Spring MVC on the view/controller aspect and is using Groovy as the view technology.

Spring usual views (JSP, JSTL, Freemarker, Velocity) are quite outdated and I do not understand why Spring does not improve them and why Matt Raible set their as a "pro" in his comparaison.

I believe in using the Grails View as the Spring MVC View. See my previous article about the "How To" and according to the Spring MVC roadmap, Grails View support will be added to Spring 3.1.

Let's benchmark Play! vs Spring MVC with Grails View. This microbenchmark will focus only on the view/controller performance.

Grails Taglib : The template composition pattern

Grails leverages Sitemesh, a decorator engine, to support view layouts. Sitemesh layout is restricted to page layout and are not applicable to do template layout. For example a template layout which describes the composition of a table and a toolbar.

The purpose of this taglib is to define a ui composition pattern to leverage template layout.

JSF2 - Benchmark datatable

In this article I will bench the datatables of 3 JSF2 components frameworks :

• Icefaces 2
• Primefaces
• Richfaces

I will focus on efficiency : page size, ajax request/response size, server load, and not on features.

Grails View as Spring MVC View

Introduction

The reference documentation of Spring 3 contains the following statements:

One of the areas in which Spring excels is in the separation of view technologies from the rest of the MVC framework. For example, deciding to use Velocity or XSLT in place of an existing JSP is primarily a matter of configuration. This chapter covers the major view technologies that work with Spring and touches briefly on how to add new ones.


The supported views are "JSP & JSTL", "Tiles", "Velocity & FreeMarker", "XSLT". Those are the major view technologies that work with Spring. The Spring MVC stack is usually : Spring MVC + JSP/JSTL + Tiles or SiteMesh. All these tools sound outdated, always usefull but outdated. On the other side there are frameworks like JSF, Grails, Play! (not exhaustive list) which come with great views more up to date.

Grails is the most logical choice because it uses Spring MVC internally. The task should be easier. To be honest this choice is not a very hard one because Grails view is elegant.

The Path to Management

From Esther Derby :

• For Managers: 8 Ways to Build Trust, 3 to Break It
• Real leaders make space for others to shine. So true and the word "space" is quite meaningful.
• Team Trap #5: Withholding Information
• The Blame Game

From Christopher Avery :

• The Difference Between Accountable and Responsible Leadership
  

About Estimation

Scrum Project Estimation Beyond the Near-Term?

This sort of article (that summarize ML thread) is very very valuable. Thanks to Dan Puckett.

JSF beans getter with Spring AOP

Introduction

JSF can call a getter more than once per request.

For example in the following JSF file :

<html>
<body>
<h:dataTable var="car" value="#{carService.cars}">
<h:column>
<f:facet name="header">
Model
</f:facet>
<h:outputText value="#{car.model}"/>
</h:column>

<h:column>
<f:facet name="header">
Year
</f:facet>
<h:outputText value="#{car.year}"/>
</h:column>

<h:column>
<f:facet name="header">
Manufacturer
</f:facet>
<h:outputText value="#{car.manufacturer}"/>
</h:column>
</h:dataTable>
</body>
</html>

JSF will call the carService.cars getter more than once inside the same request.

In this example, JSF calls it three times :

13:39:40 DEBUG : CarService.getCars:17 - qtp17489534-18

13:39:40 DEBUG : CarService.getCars:17 - qtp17489534-18

13:39:40 DEBUG : CarService.getCars:17 - qtp17489534-18

A getter obviously returns a value. This value can be a bean property or a calculated value.

If the value is calculated, this can potentially be a problem.

I googled a bit and found some workarounds.

1. The first one was to include a check and see if it has already been calculated.
2. The second one was to use the getter only to access bean properties
3. The third one was to use Spring AOP and cache the value.

For me, the last workaround is the best one because you do not have to modify the view.

And thanks to Spring, it's quite simple to add AOP with a few annotations.

The Path to Software Quality

Here is one article Handling Bugs in an Agile Context by Elisabeth Hendrickson.

And diagram to find causes of defect : The Ishikawa diagram

Agile and Scrum

The first one : How To Complete Stories Without Leaving Bugs Behind.

The second one : Getting the Customer Involved

The third one : Does Agile Limit Financial Rewards for an Individual?

These three news summarize answers about interesting questions. They contain a lot of good links to other news, articles and books.

moreagile-manifesto

Introduction to project management with Scrum

Traps and Pitfalls of Agile Software Development

Johanna Rothman: Agile Risk Reduction for Traditional Teams

Myths of Kanban

Software craftsmanship

Smart agile by ivar jacobson

How to create a stateful Richfaces popup

This article has been published first on Javalobby

I use JSF and especially Richfaces for 1 year. During this year I had a few issues with Richfaces popups.

Richfaces popups had the following issues

• The popup component is stored in the components tree although it is not displayed. On some use cases, the complete popup sub tree can be stored in the tree.
• Because popups are usually displayed using javascript, there are not sync with the components tree and vice versa.
• So popups are display off when user reloads the page, that generates inconsistent state.
• A lot of popups on the same page, that significates a lot of rich:modalPanel components, increases file size and decreases readability.
• Popups don't stack easily (A calls B or B calls A mean different zindex for A and B).

One of my coworker said richfaces popup component doesn’t scale because each sort of popup requires a specific declaration. The team had create a JSF fragment file that contains all the popup components whatever their domains or the business logic location in package and module.

My opinion is that a popup should be part of the UI logic. It should not be a component you add like a textbox but it would rather be a window you create with a createPopup method.

Ok let's try to improve popup logic.

Initialisation

I am Nicolas Labrot, a software engineer at 4Dconcept.

I created this blog to share my tought on development and to keep and share tought of others.

I have interrest in Java, JEE (JSF, Hibernate...), Maven, Agile, etc.

Let's start with an article I have written for DZone.