Core JavaServer Faces (3rd Edition)

Currently, Java Server Faces (JSF), which represents the evolution of Java Server Pages (JSP), is a very good option for getting data displayed as web pages.

There are plenty advantages of using it, like: auto validation, using directly your java objects when displaying a page or receiving a request from a user, code completion (best in latest NetBeans 7.4 RC1), an abundant collection of already made professional components (see PrimeFaces) and so on.

There are much more things to say. Of course, there is no perfect technology. It always depends on what do you actually need. Based on your description, JSF might be a good candidate for you.

There are plenty of books (Core JavaServer Faces) and tutorials about this.
If you combine JSF + ObjectDB (see manual) + Apache Tomcat or Apache Tomee (in case you want to try out some other technologies part of Java Enterprise Edition (Java EE)), you'll realize how efficient can a developer be. It's just unbelievable, yet not so many know about.

Moreover, for even greater flexibility, some like to add Groovy in this combination as well. There are even more options, but I think it might be enough for you at the moment.

In conclusion, JSF with PrimeFaces might be a good start for you. Later on you can check the other things I've mentioned, but take it step by step. I hope this gave you enough info to start with.

One i thing i would definitely recommend is this book:

Core Java Server Faces

http://www.amazon.com/Core-JavaServer-Faces-David-Geary/dp/0137012896/ref=sr_1_1?ie=UTF8&qid=1322777640&sr=8-1

I actually just finished reading the newest edition and the book is so thorough. Everything from setting up your workbench to sending emails, persistence and Web Services. The authors use Eclipse as their IDE choice (cant recall which version though). Highly recommended read for a JSF dev!

Lets say you have following two messages files

    messages.properties
    messages_de.properties

Setting the Application Locale
There are three ways of setting the Application Locale and I think you need the first one here.

1-You can let the browser choose the locale.

Set the default and supported locales in WEB-INF/faces-config.xml:

<faces-config>
   <application>
      <locale-config>
         <default-locale>en</default-locale>
         <supported-locale>de</supported-locale>
      </locale-config>
  </application>
</faces-config>

When a browser connects to your application, it usually includes an Accept-Language value in the HTTP header

2-You can set the locale programatically.

Call the setLocale method of the UIViewRoot object:

UIViewRoot viewRoot = FacesContext.getCurrentInstance().getViewRoot();
viewRoot.setLocale(new Locale("de"));

3-You can set the locale for an individual page
By using the f:view element with a locale attribute—for example:

<f:view locale="de">

The locale can be dynamically set:

<f:view locale="#{user.locale}"/>

Declaring message bundles
Now that the Locale is set you can use one of the following two ways to declare message bundles

1-Via faces-config The simplest way is to supply a file named faces-config.xml in the WEB-INF directory of your application, with the following contents:

<?xml version="1.0"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
      http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
   version="2.0">
   <application>
      <resource-bundle>
         <base-name>com.corejsf.messages</base-name>
         <var>msgs</var>
      </resource-bundle>
   </application>
</faces-config>

2-At each JSF page that needs access it. Instead of using a global resource bundle declaration, you can add the f:loadBundle element to each JSF page that needs access to the bundle, like this:

<f:loadBundle basename="com.corejsf.messages" var="msgs"/>

In either case, the messages in the bundle are accessible through a map variable with the name msgs.

Showing appropriate label on button Now lets say default properties file i.e english has property

next=Next

and German has equivallent i.e

next=Weiter

And you have set the locale and declared mesg bundle you can access it to put the label on a command button like

<h:commandButton value="#{msgs.next}"/>

Above Answer is extracted and modified from Hortsmen Core Java Server Faces book.

There is a lot of work involved in not allowing you to do this.

As Luiggi mentioned - take some time learning JSF basics and see what it can give you. Another good source of knowledge is Core JavaServer Faces book by D. Geary and C. Horstmann.

If you still can't achieve what you want using JSF core libraries (or some additional, widely available ones), then any Java code related with front-end should be in your controller classes like JSF managed beans. It will make your code easier to maintain and will allow you to test it.

There is nothing worse than putting scriptlets in your JSP/JSF/whatever view technology.

These are frameworks for different layers.

• JSF is for the view (web) layer, it's a component oriented framework (every part of a page is a component, it has state) like Wicket or Tapestry, and unlike Action frameworks like Spring MVC, Struts or Stripes

  Books: Core JavaServer Faces (3rd Edition)
  Tutorials: CoreServlets.com

• EJB 3.x is a container that's part of the JavaEE stack. It does things like dependency injection and bean lifecycle management. You usually need a full JavaEE application server for EJB3

  Tutorials: JavaEE 6 Tutorial: EJB
  Books: EJB 3 in Action

• Spring is also a container, but Spring can run in any java code (a simple main class, an applet, a web app or a JavaEE enterprise app). Spring can do almost everything EJB can do and a lot more, but I'd say it's most famous for dependency injection and non-intrusive transaction management

  Online Reference (excellent)
  Books: I couldn't find a good english book on Spring 3.x, although several are in the making

• Hibernate was the first big ORM (Object relational mapper) on the Java Platform, and as such has greatly inspired JPA (which is part of the EJB3 standard but can be used without an EJB container). I would suggest coding against JPA and only using hibernate as a provider, that way you can easily switch to EclipseLink etc.

  Books: Pro JPA 2: Mastering the Java™ Persistence API (not hibernate-specific),
  Java Persistence with Hibernate (getting a bit old)