Recommended Jsf 2.0 Crud Frameworks

Recommended JSF 2.0 CRUD frameworks

CRUD is indeed a piece of cake using JSF 2.0 provided standard facility: a @ViewScoped bean in combination with a <h:dataTable> basically already suffices. Here's a code example which is shamelessly copied from this article.

Bean:

package com.example;

import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;

import javax.annotation.PostConstruct;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;

@ManagedBean
@ViewScoped
public class Bean implements Serializable {

private List<Item> list;
private Item item = new Item();
private boolean edit;

@PostConstruct
public void init() {
// list = dao.list();
// Actually, you should retrieve the list from DAO. This is just for demo.
list = new ArrayList<Item>();
list.add(new Item(1L, "item1"));
list.add(new Item(2L, "item2"));
list.add(new Item(3L, "item3"));
}

public void add() {
// dao.create(item);
// Actually, the DAO should already have set the ID from DB. This is just for demo.
item.setId(list.isEmpty() ? 1 : list.get(list.size() - 1).getId() + 1);
list.add(item);
item = new Item(); // Reset placeholder.
}

public void edit(Item item) {
this.item = item;
edit = true;
}

public void save() {
// dao.update(item);
item = new Item(); // Reset placeholder.
edit = false;
}

public void delete(Item item) {
// dao.delete(item);
list.remove(item);
}

public List<Item> getList() {
return list;
}

public Item getItem() {
return item;
}

public boolean isEdit() {
return edit;
}

// Other getters/setters are actually unnecessary. Feel free to add them though.

}

Page:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:head>
<title>Really simple CRUD</title>
</h:head>
<h:body>
<h3>List items</h3>
<h:form rendered="#{not empty bean.list}">
<h:dataTable value="#{bean.list}" var="item">
<h:column><f:facet name="header">ID</f:facet>#{item.id}</h:column>
<h:column><f:facet name="header">Value</f:facet>#{item.value}</h:column>
<h:column><h:commandButton value="edit" action="#{bean.edit(item)}" /></h:column>
<h:column><h:commandButton value="delete" action="#{bean.delete(item)}" /></h:column>
</h:dataTable>
</h:form>
<h:panelGroup rendered="#{empty bean.list}">
<p>Table is empty! Please add new items.</p>
</h:panelGroup>
<h:panelGroup rendered="#{!bean.edit}">
<h3>Add item</h3>
<h:form>
<p>Value: <h:inputText value="#{bean.item.value}" /></p>
<p><h:commandButton value="add" action="#{bean.add}" /></p>
</h:form>
</h:panelGroup>
<h:panelGroup rendered="#{bean.edit}">
<h3>Edit item #{bean.item.id}</h3>
<h:form>
<p>Value: <h:inputText value="#{bean.item.value}" /></p>
<p><h:commandButton value="save" action="#{bean.save}" /></p>
</h:form>
</h:panelGroup>
</h:body>
</html>

Further, Netbeans has some useful wizards to genreate a CRUD application based on a datamodel.

What's the recommended JSF 2.0 scope for a CRUD application?

Right, you want the scope there in between: @ViewScoped. This scope lives as long as you're submitting and navigating to the same view.

See also:

  • JSF 2.0 new features, View Scope
  • CRUD in JSF 2.0 (with code example)

Best strategy to multiple CRUD with jsf

You might consider codegenerating those 20 screens, much like scaffolding in Ruby does. As far as DAO is concerned, you might pull CUD operations to some generic IBusinessObjectDao, leaving specific R operations (querying by various parameters) to concrete DAO implementations.

JSF single controller and Different View ,Edit ,Update page

Using the same controller for multiple Views is OK IMHO, if it prevents code duplication and the usability is improved by using separate views.

Unfortunately, you cannot continue using the View scope. There are several alternatives though. You could either use the new custom Conversation scope, or fall back to Session scope. Both have pros and cons - with the conversation scope you will have to do the scope handling yourself. With the Session scope, you may unnecessarily put too much data in the session.

So if I had to choose, I would rather use the conversation scope over session scope as the more tedious but more clean solution.

EDIT: Please note that the conversation scope is not a JSF feature, it comes from CDI, meaning that you would have to change the annotation on your bean from @ManagedBean to @Named

EDIT2: To use CDI on tomcat, you need to have it in your classpath. If you are using maven, add this to your .pom, otherwide, download and use the jar "manually".

<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet</artifactId>
<version>1.1.9-Final</version>
</dependency>

Additionally, you would have to add this to your web.xml:

<listener>
<listener-class>
org.jboss.weld.environment.servlet.Listener
</listener-class>
</listener>

You may also need an empty beans.xml. Im not sure about that though.

Is there a CRUD generator utility in Java(any framework) like Scaffolding in Rails?

Spring Roo seems to be exactly what you're looking for: CRUD code generation, spits out pure Java code that can be made tun run entirely independant from the framework.

CRUD Application in one controller (servlet)

Frankly, the common practice is to adopt a MVC framework. Java EE 6 offers JSF 2.0 out the box as a component based MVC framework. CRUD is possible with a single bean and a single view. You can find a basic example in this answer. The sole controller is provided by JSF itself, the FacesServlet. Other MVC frameworks follows less or more the same ideology.

If you don't want to adopt a MVC framework because you would like to learn JSP/Servlets first and/or your project won't go beyond a CRUD form, then it is hard to point out the "right" approach. At least, the use of multiple URL patterns and if/else statements is a poor sign. You have basically 2 options.

  1. Just use 4 separate servlets. With Servlet 3.0 you don't need to fiddle with web.xml anymore and it's really easy to add another servlet class. Each servlet class functions as an "action" class and each one has a clear responsibility.

  2. Use a single servlet, but don't use multiple URL patterns and don't use if/else blocks to determine the actions. Map it on a single URL pattern such as /action/* or *.do so that you can invoke it by URLs like action/create, action/read, etc or by create.do, read.do, etc. Then create an interface like follows

    public interface Action {
    void execute(HttpServletRequest request, HttpServletResponse response);
    }

    Implement all actions based on this interface, CreateAction, ReadAction, etc and have in your servlet a Map<String, Action> which you fill as follows during init() method:

    actions.put("create", new CreateAction());
    actions.put("read", new ReadAction());
    // ...

    And invoke it as follows (assuming an URL pattern of /action/* is been used)

    actions.get(request.getPathInfo().substring(1)).execute(request, response);

    That's also how the average MVC framework works deep under the covers.

See also:

  • Design patterns web based applications

Which framework should I choose - Seam, Wicket, JSF or GWT?

The only one of those I've used is JSF, so I won't be able to give you feedback on the others, but here's my take on JSF. In my experience, the minute we converted from JSF in JSP to JSF in facelets, life got MUCH easier, so I'll focus around facelets. Also, It looks like Seam and JSF are not mutually exclusive.

Pros:

  • Creating facelets xhtml components is simple, which promotes re-use.
  • Decent templating abilities using built in tags like ui:insert, ui:include, and ui:decorate
  • Simple access to Spring beans through faces-config
  • XHTML based so web developers unfamiliar with java can still be effective
  • Good widget library available in tomahawk/trinidad

Cons:

  • Post requests only. This can make bookmarking difficult.
  • Not as built-in ajax-y as GWT, but this may be fixed if used with Seam

I'm by no means an expert in JSF/Facelets, so I'm sure there are others I've missed. Hopefully someone else will also elaborate.

Update for JSF 2.0:

  • Has even better re-use capabilities with composite components
  • Widget libraries for 2.0 include primefaces and mojarra scales
  • Allows get requests and bookmarking
  • Has built in Ajax support
  • See http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ for more on JSF 2


Related Topics



Leave a reply



Submit