Valid Record Fields

[Mark O' Sullivan]

Hi,
I presume since Sun valid the interface methods themselves seperately I presume one needs to facilitate validating the record fields. Is this right? For example, the update method I have takes a String[] data array so I presume before a record can be updated, all fields within this array need to be validated? Would following be correct for the URLYbird assignement;
HotelName: can contain any US ASCII character
HotelCity: Can contain any US ASCII character
Max Occupancy: only contain integers
Smoking: Only characters N,Y,n,y accepted
Price: First character is valid currency symbol, rest is double
Date Available: use format given for date
CSR: valid 8 digit number
Is this correct? Any advice must appreciated.

[Fernando Franzini]

Hi Mark

You are rigth.
There 2 kinds of validation in this list: bussines and database.
The point of SCJD is 'how' and 'where' you'll deal with that !
There are a lot o option.....I'll tell you what was mine:
I've decided implement 3-tier designer where all this bussines validation was implemented in bussines tier.
Database validation was implement in persistence layer.
You can decide it based on how it yours design.
Regards

[Yucca Nel]

I chose to do the following validations.
magic cookie = correct file
each field length= as the database is shared with a legacy system and the format must be compatible
CSR number as this was a MUST
Locking is done in business layer and validated in data layer.

[Roberto Perillo]

Howdy, Mark!

In the Data class, the validation I provided was just to verify if the arguments were not null, and if the objects in the String arrays were not null. I'd say that a validation more related to business should be put in the business layer. For instance, before booking a room, I verify if the customer ID is a valid 8-digit number. And since the only business behavior that deals with persistence we must implement is booking a room (via update() method), then I'd say that verifying if the user provided a valid 8-digit number is the only validation that you really have to do in the business layer (regarding persistence).

[Roel De Nijs]

Hi Mark,

I followed a bit the same approach as the Great SCJD-master of Brasil. So my Data class takes care of validation against the database schema: I only checked for field length and if data can be converted to the allowed charset, so didn't apply already a check to see if smoking is one of [YyNn] (because it's not changed in application). And in my business service I validated the customer-id.

Kind regards,
Roel

[Mark O' Sullivan]

Hi,
Thanks for your kind responses. Is this associated with checking the character set "UTF-8" when creating a new String from the String class and if encoding is not "UTF-8" throw UnsupportedEncodingException? I presume this line from the requirements "The character encoding is 8 bit US ASCII", therefore is not a business rule but a requirement? I presume when I'm writing out in the Data class, i check 2 things in the String[] data array, each elements length and whether a new String can be created for each element in the "UTF-8" format, if not UnsupportedEncodingException occurs? Thanks very much. I'm only talking about the data layer here.

[Roel De Nijs]

Hi Mark,

I execute following check per field value:

try {
    byte[] array = field.trim().getBytes(CHARSET_NAME);
} catch (final UnsupportedEncodingException e) {
    throw new IllegalArgumentException(..., e);
}

As a charset I use the ISO-8859-1 one.

Kind regards,
Roel

[Mark O' Sullivan]

Hi,
Thanks for your replies. I tried the code below for reading and writing to file.

byte[] array = field.trim().getBytes(CHARSET_NAME);

and used the below charset_name. The field string I'm using contains the euro symbol. I thought this may raise an exception when writing but it didn't. Also when I read in the euro symbol after writing, I get a ? symbol instead of the euro. Any ideas? Does the getBytes() create its own interpretation of the euro symbol.

[Roel De Nijs]

Hi Mark,

Didn't do any tests with the euro symbol. But ISO 8859-1 does not declare the euro symbol. From the wiki-page:

Although ISO/IEC 8859-1 has enough characters for most French text, it is missing a few letters that are less common. It is also missing a single-glyph representation for the letter IJ, two Finnish letters used for transcription of some foreign names and in a few loanwords (Š and Ž), typographic quotation marks and dashes, and common symbols such as the euro sign (€) and dagger (†).

This one does.

Kind regards,
Roel