aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird 1.2.1 - validate or not validate the data Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird 1.2.1 - validate or not validate the data" Watch "URLyBird 1.2.1 - validate or not validate the data" New topic
Author

URLyBird 1.2.1 - validate or not validate the data

Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74
Hi all,

Did you validate the data at the data access level (I mean the Data class)??
Did you check if the "date" column is in the yyyy/mm/dd format or if the first character of the "Rate" is the "$" (dollar) sign, the same with the customer id - if it's exactly 8 digits long ??

I think this should be implemented in the Data class, but I believe this must be done in the business code as well. The application can't rely on error checking implemented in the data access level. If you choose to replace the Data class approach with a relational database engine, it's likely that your new data access will NOT throw an exception if the owner contains less than 8 digits.

I did it both in the Data class and in the business code. Isn't it overkill??

Thanx in advance for your oppinions.

Cheers
Krzysiek
[ October 14, 2005: Message edited by: Krzysiek Hycnar ]
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello Krzysiek.


Did you check if the "date" column is in the yyyy/mm/dd format or if the first character of the "Rate" is the "$" (dollar) sign, the same with the customer id - if it's exactly 8 digits long ??


Field formats are known at runtime and the specs say nothing about them, you only know if they are numeric/alphanumeric and their length.
So i decided validating the length but not the content. More than validating I fill or truncate the value for matching the correct length.
You can see it as a physical transformation rather than a logical
validation, necessary to mantain file integrity.

Of course this integrity has to be mantained as close as posible to the bd file, so I implement it at data layer.

Hope that helps you
Regards


SCJP, OCMJD, OCMJEA
Marcio Aun Migueis
Ranch Hand

Joined: Sep 15, 2003
Posts: 32
Krzysiek

I Read some posts where it�s common sense that the owner Id could be less then 8 digits. You may add spaces to the entry field.

M�rcio
Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74
Hi

To Marcio

An excerpt from the instructions.txt...


The id value (an 8 digit number) of the customer who has booked this.


I know that using common sense you can easily conclude that there is nothing bad if the value is less than 8 digits long, but the instructions leave no doubt about how it is expected to be.
But it is a small detail, I am asking you about the idea of data layer and business layer validation.

Krzysiek
[ October 14, 2005: Message edited by: Krzysiek Hycnar ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11277
    
  59

Hi Krzysiek,

M�rcio may have been refering to posts like this.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74
Hi,

Thanx for your replies, but I'm still not clear if I should validate in my data layer (in the Data class) the "date" field - if it's in the yyyy/mm/dd format, or the "rate" field - if it has leading "$" sign?? In my URLyBird version, I never modify those fields since the instructions say that the only field to be modified is the "owner" (on the other hand I never use the createRecord(...) method of the DBAccess interface which doesn't mean I could skip it in the Data class ), so the question remains opened... validate or not validate in the data layer??

Krzysiek
[ October 17, 2005: Message edited by: Krzysiek Hycnar ]
Marcio Aun Migueis
Ranch Hand

Joined: Sep 15, 2003
Posts: 32
Hi Krzysiek,

I believe that the data layer is not the better place to validate users data. But it�s a long discussion with no end. Choose which layer you�d validate your data and explain it in your documentation.

I�m, developing UrlYBird and I�m validating tha data in a business layer. I suggest you to use a JFormattedTextfield to recieve the owner id, because with JFormattedTextField you assure that ony numeric chars ( it�s not the unique way to do this ) would be accepted. And you can limit the number of characters typed by the user.

Hope I had help you

M�rcio
(sorry my English)

[ October 17, 2005: Message edited by: Marcio Aun Migueis ]
[ October 17, 2005: Message edited by: Marcio Aun Migueis ]
Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74
Sure Marcio, I do validation in the business layer too, and I absolutely do agree with you - the data layer is not a good place do validate the data, but to be more correct I would say "it's not a best place to validate the business aspects of the data". See what happens if you try to insert a date that is not in the correct date format into a SQL datatabase table. The database will obviously protest! The same if you try to insert a string that exceeds the max length declared for the column - the database guards its data integrity.

Don't know what software do they use in Sun to test the Data class, but I'm sure they wouldn't be impressed if we allow the "date" column to be filled with whatever instead of "yyyy/mm/dd". Or maby I'm wrong, and it's just an overkill! Think feedback from successful SCJD passers would be invaluable to see in this thread .

The Data class is the software component closest to the data, and in my oppinion it does the job of the database engine. So I believe there should be some validation mechanisms in the Data class too - not the crucial ones that the business code of the application relies on (because if you replace the persistence approach and switch to a relational database they will never be called) but kind of "last resort validation" - to keep your data integrity.


Thanx for the tip on the JFormattedTextField! I'll check it up for sure (I did it with a standard JTextField that is then examined if the typed value is a legal number).

Krzysiek
[ October 17, 2005: Message edited by: Krzysiek Hycnar ]
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello again

Some days ago i wrote:

Field formats are known at runtime and the specs say nothing about them, you only know if they are numeric/alphanumeric and their length.


and reading other post i've just noticed that the specs do say something!


Valid values are "Y" indicating a smoking room, and "N" indicating a non-smoking room ...
This field includes the currency symbol ...
Date available date 10 The single night to which this record relates, format is yyyy/mm/dd...
Customer holding this record owner 8 The id value (an 8 digit number)...


So i have to change my answer ...
With this in mind i think validation is necessary.

Krzysiek wrote:

So I believe there should be some validation mechanisms in the Data class too ...


I think so, this validation should be placed at data layer since this format is imposed for the batabase, and data layer is the lower access level to it, so this validation is guaranteed for every database client.

Krzysiek wrote:

... I know that using common sense you can easily conclude that there is nothing bad if the value is less than 8 digits long, but the instructions leave no doubt about how it is expected to be.


I agree too. I will force id to be a 8 digits number.

Regarding currency character:

Krzysiek wrote:

character of the "Rate" is the "$" (dollar) sign


I my specs nothing is said about it, so as this sign is known at runtime i will not validate it

Regarding smoking flag i will validate it's format too

Regards
Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74
Oricio,

After a few sessions of "shower thinking", and "WC thinking" I decided to implement the data checking functionality in a maner a database
engine would provide if it were used instead.

The columns of the file are validated as if they were defined with the following pesudo SQL:

small excerpt from my choices.txt


name VARCHAR(64) NOT NULL // only the length is checked
location VARCHAR(64) NOT NULL // only the length is checked
size LONG NOT NULL // length is checked, also must be valid long (Java long)
smokingCHAR NOT NULL // only the length is checked
rate MONEY NOT NULL // must be within $0.00 - $9999.99, the leading $ is required
date DATE NOT NULL // must be a valid date formated as yyyy/mm/dd
owner LONG // length is checked, must be valid long (Java long)



The smoking column - I recognize the "Y" or "N" to be a business requirement, so this should be checked in the business layer (not checked in my case since I do not change the field).

About the owner column - check the link from Andrew's reply in this thread (in short: Sun does not complain if the ids are less than 8 digit long).

Also the requirements for the owner column seem business requirements to me and are checked in the business layer - must be positive (I've never seen negative id's ), and the length must be less or equal 8.

Take Care
Krzysiek
[ October 20, 2005: Message edited by: Krzysiek Hycnar ]
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hi Krzysiek

"shower thinking", and "WC thinking"

For those people asking about the effort of SCJD: These are two factors usually forgotten!

smoking CHAR NOT NULL


what about ...?



From this point of view it would be a data requirement don't?


... not checked in my case since I do not change the field

IMHO if you are providing a "create" method you should deal with that validation

About the owner column - check the link from Andrew's reply in this thread (in short: Sun does not complain if the ids are less than 8 digit long).

Yes, i had already read it, but i thought maybe those specs were quite different... Anyway:


Also the requirements for the owner column seem business requirements


well, reading again the specs:

record owner 8 The id value (an 8 digit number)


"(an 8 digit number)" seems to be an informative note rather than a format requirement, so i agree it should be a business requirement.

Regards Ori
Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74

smoking CHAR NOT NULL

what about ...?

smoking BOOLEAN DEFAULT FALSE NOT NULL


Formally you're right, either you can smoke or not - a perfect match for BOOLEAN . I chose CHAR in my description to be as close to the provided database file as possible, the acceptable values in the file are "Y" and "N" so they belong to the domain of CHAR. BOOLEAN domain is usually TRUE or FALSE. It's possible that I rethink and change it (just give me a few more above mentioned "sessions" )

Answering your question, I of course validate against this scheme all creates and also updates (in case of updates, only the fields that are changed are validated).

Cheers
Krzysiek
[ October 20, 2005: Message edited by: Krzysiek Hycnar ]
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Ok make us know when the seed of your sessions has bloomed!

Regards
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

MWC pattern
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11277
    
  59

One quick comment guys.

The interface provided by Sun does not make any reference to the type of data it will be accessing. That is, the same interface could be used to access a table containing hotel rooms, or to access a table containing client details, or any other data you care to mention. As long as the table structure (including it's meta-data) stays the same, the Data class should be able to access it.

It seems from some of the discussions here that some of you are planning on including field-level validation within the Data class itself. This means that the Data class will then become specific to the table and will no longer be usable for any other form of Data.

Would it make more sense to create a generic Data class, then extend it to make a RoomData class (or something similar)?

Regards, Andrew
Krzysiek Hycnar
Ranch Hand

Joined: Jan 02, 2004
Posts: 74
Andrew,

That's exactly what I did . In my design I have an abstract class that is named AbstractData, it's practically database file independent - only the metadata must be in the format as in the provided file. That class implements all of the methods defined in DBAccess as well as handles the database metadata. Its direct subclass is the Data (room database file specific) class that basically adds only room specific features including validation logic.

Anyway thanx for your tip about naming!! Think this is a way better idea to rename my AbstractData to Data, and the Data to as you propose RoomData (possibly my naming at the moment is not what Sun expects).

Take Care
Krzysiek
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello guys,
i was thinking in something like:


And then in my data class:


that has several issues i i've not yet decided:
1) Where to store that field format meta information
2) How to bind it to a certain data file
3) What metalenguage to use for specifying field formats

What do you think of this?

Regards
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: URLyBird 1.2.1 - validate or not validate the data
 
Similar Threads
mandatory fields - create and update method - DBAcess Interface
recNo choice
Validation of arguments in Data class methods
Double the Complexity!
Where to verify data before writing to database?