tags:

views:

42

answers:

1

I am creating a form in JSF to save a new entity bean. I binding the properties of the new entity to input elements use the value property e.g. , where backing bean is JSF managed mean and newEntity is filed of the backing bean whcih contains a new instance of my entity. For properties which are value types (like numbers), the input fields will be populated with default values (e.g. 0). I want all the fields to be blank initially and saved back the new entity instance when the page is submitted. I suppose I could make all the properties null able by using types such as Integer but the values aren't null able in the database and it doesn't seem right that the requirements of my user interface should dictate the form of by business layer. I am looking at this the wrong way?

+1  A: 

I assume that if the fields aren't nullable, then they are required. If you put required="true" on the field, then validation should fail before the value can be assigned. This means it won't try to assign null values to your attribute. You may have to write a custom validator to do this for some types of fields.

Alternatively, you can write a converter. This converter would have to convert empty values to some predetermined constant such as -1 that you know is invalid. And vice versa, it would have to convert -1 to empty value for display. Then you have to deal with all the invalid values before sending it to the business layer.

I've used both of these methods, but I much prefer the first. If the fields are not required, they should be nullable in the business layer.

Colin Gislason
The second method is not option for me as in general there isn't always a value which can reserved to represent an invalid state. The first method works and as mentioned validation can be added to the ui but in contexts other than data entry such when existing objects are loaded out of the database for reference purposes the properties can never be null so seems the fields which are not null in the database should be not be nullable types so that it clear which fields are nullable and which aren't.
Shane
My idea was that in the case that new record is being edited we can use the fact that we know that it the record is new and not synchronise ui controls to the entity before presenting to the user. Maybe this can be done with custom converters which somehow receive a flag that tells them to only move the data one way from the control to the entity. But maybe this is too complicated and it one should just use nullable fields and be done with it.
Shane
A custom converter that takes a flag would work. The main downside is that you'd have to put it on every input component.
Colin Gislason
I believe the new composite tags in JSF 2.0 would enable you create a custom input tag that uses the custom converter. The composite tags are worth checking out if you haven't already. Before JSF 2 I think you had to create a few different files including some java to make a reusable component, now you can do in all with facelets mark up in one fie.
Shane