Daniel Rhoades

Personally I'd deal with the property as a boolean in the bean and depending on your persistence mechanism do the conversion from Java boolean to SQL TINYINT when persisting/updating in your DAO/persistence classes.

How about:

template.xhtml (partial):

<div class="inner"> <div class="left">LHS-menu</div> <div class="center"> <ui:insert name="body">Default content</ui:insert> </div> </div> <div class="right">RHS-menu</div>

Create a custom converter for your Employee class then register it against the select item list:

faces-config.xml

<converter> <converter-id>Employee</converter-id> <converter-class>yourpackage.Converter</converter-class> </converter>

JSP:
<h:selectItems ...(attributes) converter="Employee"> ...

Your converter class implements javax.faces.convert.Converter which has two methods:

public Object getAsObject(FacesContext context, UIComponent component, String newValue) throws ConverterException public String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException

In getAsString just cast "value" as "Employee" return employeeId from the object.

In getAsObject assume "newValue" is the employeeId and look it up in the database/persistence mechanism or however you want.

Using a converter in this way will get the Employee into assignEmployee.

Change the way you create select items to get the Employee name:

List<SelectItem> selectItems = new ArrayList(); for (Employee elem : entities) { selectItems.add( new SelectItem( elem, elem.getEmployeeName() ) ); }
[ May 16, 2007: Message edited by: Daniel Rhoades ]

You probably need to create a normal TLD in additional to the Facelets taglib file, IDE's aren't that facelets friendly!

What server are you using?

In my opinion...

1) Yes, but generally a bad idea - use a session bean facade to encapsulate access to the entity bean.

2) Dependant on the locking mechanism used by the container -> database. If you are using a facade the container will only let one thread be in a session bean method at any one time (assuming both are calling the bean from the same remote reference).

${pageContext.request.contextPath} should do the trick in a non-facelets application

I learned JSF via "Core JavaServer Faces" it got me where I am today! It doesn't cover JSF 1.2 though being published in 2004.

For JEE 1.4 apps in JBoss 4.x I use the following JARs for Facelets 1.1.11:

jsf-facelets.jar
el-api.jar
el-ri.jar

Also I've got commons-codec-1.3.jar in there for some reason - don't think its needed though. I think JBoss uses a Tomcat 5.5 container and I'm using the standard myfaces libraries that come with JBoss.

For JEE5 apps in SJAS 9.01 I just use jsf-facelets.jar.

If you Tomcat 5.5 doesn't come with a JSF implementation grab the latest one from myfaces.apache.org as I think the JSF jars in the facelets dist are broken.

immediate="true" should bypass the validation phase, adding AJAX support to your JSF application sounds cool - but that might add more complexity than you actually need.

Try just creating a standard JSF application using your container's JSF libraries (so you don't need to package any in your app), which server are you using - JBoss 4.05?

Ok, sorry I was talking about EJB 3.0

In EJB 2.x transaction management can be done with entity beans and sessions for different reasons, but since you're not using persistance I won't go into detail (though session bean transaction management is not limited to entity beans).

You make a remote call to an EJB over RMI and yes what ever you send back gets serialised in the call-back - but a DTO holds a copy of all the data, so subsequent calls to get individual properties just access the DTO in memory on the client rather than being RMI calls, for example:

User user = myBean.registerUser(email);

user.getEmail()
user.getPassword()

Any method calls on the user object have no remote overhead, the data (the serialised user object) is already with the client at that point.

I don't think performance would vary greatly puting 60Mb of data into a DTO and sending via an EJB callback or some other remote object serialisation method.

There are several other ways you could get the data back to the client without serialisation - an IO stream perhaps?

If you haven't seen the reviews on this Hoff CD you haven't lived!

The Very Best of David Hasslehoff

Also, if you are an englishman like me you'll love this Peter and Jordan CD review too

A Whole New World

Um... I've heard 12" is a good size...

Did you try an onchange="submit()" with an immediate="true" on the selectOneRadio, the form does actually need to submit back to the server to process the valueChangeListener