The good news is that some of your applications—the ones that automate commodity business processes—can be bought off the shelf, and the ones that are dealing with the core processes that differentiate your company can be custom.

With the growing software market and the global economy, there are many choices when it comes to custom-built software. Overseas development and open source frameworks made the process much more affordable, but you still need the right technology partner.

Here are some of the top things to consider when looking for a custom software developer:

1. Make sure they understand your business requirements and objectives
2. Take time with the design and planning stages. This is extremely important and should have the appropriate time allotted for the task
3. Make sure you completely understand the scope of the project before starting development
4. Be involved with the entire development process and all iterations, and make sure your partner uses the latest development methods (Agile)
5. Make sure you have local support and Project Management (most projects fail because of poor project management)
6. Find out how Quality Assurance is handled and what portion of development is allocated for QA
7. Set reasonable expectations and timelines for deliverables
8. Discuss how cross-functional departments may be affected by the new application and make sure they are involved in the process.

Follow these steps and you will be off to a good start. Custom application disasters can normally be traced back to three areas: poor design and scope, poor project management and lack of stakeholder’s involvement in the process.

Sreeni Jakka of TechO2 puts it best when he says “projects evolve, not change.” It is a guarantee that projects will have many changes throughout the development process, so if we are aware of this and anticipate them, it is evolution, not change.

Ajax  is a group of interrelated web development techniques used on the client-side to create interactive web applications. With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. The use of Ajax techniques has led to an increase in interactive or dynamic interfaces on web pages.

Almost all OpenFaces components have built-in ajax functionality by using an optional attribute “render”, Example: o:commandLink; render attribute specifies what components should be reloaded after the ajax request is complete.
OpenFaces 2.0 also introduces an Ajax framework which allows adding Ajax-based interactions in cases when components’ built-in ajax capabilities are not enough. Open Faces Ajax framework addresses a common scenario where the whole page has to be submitted to perform some application-specific action and reload certain components of the page with the results. o:ajax is a non-visual component that can be used to ajaxify any JSF (or even html) component.

Here’s a simple example which demonstrates the usage of the o:ajax component:

<h:inputText id=”in” value=”#{}”/>
<h:commandButton value=”Update”>
<o:ajax execute=”in” render=”out”/>
</h:commandButton>
<h:outputText id=”out” value=”#{}”/>

Some Gotchas using o:ajax:

1. The method binding for the action that need to be executed when the event is trigger will have to implement an action listener using ActionEvent as the parameter. Frameworks such as a4j use action attributes without action listeners to achieve the same.
2. OpenFaces implementation of Ajax is strictly for in-page transitions; meaning you should use Ajax for rendering/reloading components in the same page. Other frameworks allow page transitions from the action event triggered by ajax requests; OpenFaces doesn’t. Example: if your action method returns a navigation cue for faces-config to go to another page, OpenFaces ajax request completion will not honor that. This is true for all ajax-enabled OpenFaces components as well.
3. When o:ajax is used to trigger an action on the server side (managed bean), all the components that are part of the execute attribute (explicit submission of certain components), the component that’s triggering the ajax call, and the components that are part of the render attribute (the components that need to be redrawn) get submitted to the managed bean as part of the ajax life cycle. This causes issues for a very common use case where possible values for a component are dynamically returned from the server using ajax. This use case will not work with o:ajax implementation as the target component value will also be submitted to the life cycle, and they may fail validation (if the component is subjected to a validation), and basically the action will never happen. A big shout out to the OpenFaces developers! They quickly responded to our request and added an attribute declaration for o:ajax to handle this very common use case; executeRenderedComponents, that you can use to turn off value submission of the rendered components during ajax request.
4. All components involved such as the ones triggering the ajax request, the ones specified in execute attribute, and the components specified in render attribute should be located in the same form!
5. Use of o:ajax with components from other frameworks such as RichFaces is unpredictable.

o:ajax plays well with all the other JSF components and o:defaultProgressMessage (please wait message that you may want to use to convey the user that the ajax request is in progress).

We still think that there will be use cases where the ajax request action have to result in a transition conditionally. Example, ajax request is invoked with specification of what component to be rerendered after the request is complete. The request is binded with an action method which based on a certain condition will result in a navigation to a different page. In most cases, the behavior will be to render the component(s) specified in the request. If o:ajax can support that use case, I think you can pretty much implement all variations of ajaxification using o:ajax.

JSF like several other noted web frameworks follows the MVC pattern. The managed beans ala backing beans form the model, components form the view, and the Faces Servlet forms the controller. It’s the Component that’s the subject of this post. Components are typically UI components that are factory built, and come with rich features similar to AWT/Swing components. So, one key benefit JSF offers in terms of UI design is you have rich set of UI components to build desktop-like rich user interface applications, and also reduces the presentation layer development efforts dramatically.

JSF provides two ways of binding these components to data: Component binding and Value binding. Component binding binds the view component to a Java instance of the UI component in the backing bean. Value binding binds the value of the view component to a property on the backing bean.
Example of value binding:
The view component is defined something like this

<h:inputText id value=”#{myBean.someProperty}”/>

The backing bean property is defined as something like this

public class MyBean {

String someProperty = “”;

public String getSomeProperty() {

return someProperty;
}
public void setSomeProperty(String property) {
someProperty = property;
}

}

Example of component binding:
The view component is defined something like this

<h:inputText value=”#{ myBean.someProperty}”

binding=”#{ myBean.somePropertyInputText}”/>

The backing bean definition goes something like this

public class MyBean {

HtmlInputText somePropertyInputText;

public HtmlInputText get somePropertyInputText () {
return somePropertyInputText;
}
public void set somePropertyInputText (HtmlInputText input) {
somePropertyInputText = input;
}

}

There is always a debate whether you implement value binding or component binding in JSF. Personally, if you look at the component binding example, it starts looking like more .NETish… I guess it’s a matter of philosophy; I have seen developers writing backing beans with ton of code using component APIs embedded in it.

Though, sometimes it’s easier to work with the inherent component binding at the API level (ex: populating a list box using <f:selectItem>), personally I prefer to go with value binding and minimize component binding. Here are my reasons:
1. Gives a clean separation of UI design and Java code. Also from work division perspective, this is very relevant in environments where you have dedicated UI designers that focus on the component representation in the view part (xhtml, or jsp) and Java programmers for the Java side of the equation.
2. Besides separation of development efforts, value binding also gives opportunities for interchanging UI components that front a backing bean property very easily. You may decide that you would like a Scrollable Data Table instead of a Data Table, and accomplish it with no changes on the backing bean side.
3. JSF is very extendable where you can plug in UI component libraries from third parties. Rich Faces, Facelets, Ajax4jsf, JSF Avatar, etc. are some of the component libraries you can stack up on top of JSF. Component binding in such scenario will work against pluggable functionality if you decide to swap Rich Faces with let’s say MyFaces Tomahawk. Now, you will have to plow through your backing bean code to replace the component APIs with the new ones.
4. JSF also supports custom components. The above arguments about pluggability and isolation of UI APIs vs. managed bean code also hold good here.
5. When solving a business problem you think in terms of objects, their properties, relationships and interaction; not in terms of how those objects are mapped to a specific UI component. From a philosophical perspective, that’s my biggest reason for not using component binding and the component APIs in the managed beans.

Component binding does have it’s niche in situations where you want to implement valueChangeListener, or want to dynamically change the contents of a component (of course, you can Ajax enable your view and achieve the same without component binding in most cases). But, I would like to stick with value binding for 95% of my needs.