Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: Customer ID Number

 
Michael Vargenstien
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I noticed that the instructions.html indicate that the owner field is an 8 digit number. However, when I do the math, that's one number too long in the database record field length. My length is at 183 which translates to about 7 digits for a customer ID number. Like everyone doing this thing, I'm a bit confused on the instructions...should I force the user to enter an 8 digit number? or restrict him to enter a shorter one? Also, if I do make them have 8 digit numbers, then what do I do in regards to the database record? truncate it? If that's the case, how do I validate that a current user should be able to "unlock" the booked record? Any help would be greatly appreciated!
 
chris bajada
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you sure it's one 183?? I think you re one short...
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Michael,

As mentioned in the topic Update Method, Validation, RuntimeException this week, I think that how and if we check the length of an attribute value is part of the implementation/design decision we have to do for SCJD.

I decided to do not ignore the length. In case the attribute value is longer an java.lang.IllegalArgumentException is thrown.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Michael

Hmmm, very strange. How you come to this value ?
If you open the database file with an hex editor you can see if your field has 7 or 8 digits.

Hi Lucy,
I don't know if the IllegalArgumentException is the right way to signal a malformed record, specially if this exception is a runtime one.
What I mean here is the runtime exception represents programming failures, that means the user must have the possibility to know how to test its actions - in your case the parameters.

Where you throw the IllegalArgumentException ? on your FileHandler or on your Data class ?

I choose the simplest solution - if the field is to short I pad it (with the specified value - see specs + db file) if is to long I trim it (on the allowed size).

What you think about this.

Regards M
[ April 03, 2007: Message edited by: Mihai Radulescu ]
 
Romeo Son
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I did exactly the same thing in my assignment. I pad with white spaces to the field length if the supplied parameter string is too short (because that's how they are already in original file), or trim it if it is too long to fit the field length. I will explain my decision in choices.txt
and I think it is a good choice (or not ?).

Regarding the owner id I'm a bit confused. First Sun says in instructions.html:
All numeric values are stored in the header information... All text values, and all fields (which are text only), contain only 8 bit characters... bla bla
so I think that owner id can be a string made up of 8 digits, am I right or not?

Another question I would like to put if in GUI I can generate this owner id transparently to the user or should I get it from him by GUI input?

Michael,

I don't understand how would you like that a customer should "unlock" a booked record. Lock/unlock are not performed at the presentation layer, see other database topics on this forum.

Thanks & Regards,

Romeo

[ April 04, 2007: Message edited by: Romeo Son ]
[ April 04, 2007: Message edited by: Romeo Son ]
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Romeo

The values from the header are numeric information and you can load (and interpret) them like with in the DataInput(Output)Stream, e.g. readByte():byte.
The rest is just text and you don't need to interpret it. By example the customer id can be 00120012 - you need to see this like a string and not like a numeric value.


can generate this owner id transparently to the user or should I get it from him by GUI input?


You need to let the user to specify the owner id (via your GUI), is up to you how you do it.

Regards M.
[ April 04, 2007: Message edited by: Mihai Radulescu ]
 
Romeo Son
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply Mihai.
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

Originally posted by Mihai Radulescu:

Hi Lucy,
I don't know if the IllegalArgumentException is the right way to signal a malformed record, specially if this exception is a runtime one.
What I mean here is the runtime exception represents programming failures, that means the user must have the possibility to know how to test its actions - in your case the parameters.

Where you throw the IllegalArgumentException ? on your FileHandler or on your Data class ?


Here my reasons for throwing an exception:

Customer A who calls the method wants to store her owner value like 1001001001000. Since there are no exception, she thinks: my owner value is stored. Then she reads the entry got back in your case 100100100. So she might asks what went wrong.

The next customer B stores let say 1001001001001. In your case both are going to have the same owner id: 100100100

I do not think that this is very customer friendly.

I prefer that the solution that the customer A and B get aware that their input parameter 1001001001000 and 1001001001001 are invalid.

Br, Lucy
 
Romeo Son
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Hummel,

You are right if you look beyond what the assignment asks. Here is what Sun says:
The system you are writing does not interact with these numbers, rather it simply records them. If this field is all blanks, the record is available for sale.

So in our situation, it really doesn't matter if two, or three or all the customers use the same customer id. It is just an exercise, not a real application.
What really matters is if that field is all blank or it is filled. At least this is my interpretation.

Regards,

Romeo
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lucy

You are right the user can use a book method with a wrong parameter (format) - and we need to prevent this. That why an RunTimeException is inappropriate here - you can not constrain the user to handle it, so the error can be detected only on run time - where with some luck the entire application crush.
A checkable exception force the user to take care - and this on compile time. Is like you try to handle an error or you try to prevent it.

Regards M
[ April 05, 2007: Message edited by: Mihai Radulescu ]
 
Michael Vargenstien
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow!! Thanks for all of your responses. I agree with you regarding the pad spacing and triming. As for locking and unlocking, this is not related to what I am proposing. That is currently being handled by the backend logic. I am following the MVC model for the GUI. This is the customer ID which is repainted when a booking action or a release action is performed, the internal cookies are handled just as that internally. The view only models the booking. I decided to use a combination of the regex with the padding and trimming idea so that a record can only be unlock if the customer knows his own id. I forced the user with the maskformmater to comply with the instructions.html and will defend it as Lucy has in the choices.txt.

Thanks for all of your replies!!

Best of luck!!

 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

My idea is that the gui part checks that the owner id is correct. I do it as Michael does. I invented an TextField that allows only digit as input values.

That means that the database layer should get only valid owner id entries.

But if some third party client, like a test client by Sun invokes the data/tier 3 layer dicrectly and gives as input an invalid owner id, the java.lang.IllegalArgumentException is thrown.

The behaviour is similar to real databases: If you invoke sql directly and pass in a to long char-string, you got an exception and no new record.

My goal is to mention the throwing of the java.lang.IllegalArgumentException in my choices.txt and in my JavaDoc. Since I have not started to document I have not done that part.

I hope that I start documentation this weekend.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lucy,



I invented an TextField that allows only digit as input values.


take a look on javax.swing.JFormattedTextField
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

I extendes javax.swing.text.PlainDocument and add a pattern matcher to it.

Thanks for telling, tomorrow I am going to check if I change my implementaton.
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

I have not checked your proposal.

But at least at the weekend I started the JavaDoc and found a lot of points that can be improved.

To think positiv, better I found the points than Sun
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lucy

You don't need to extend the document to filter the input, if you choose this way (instead of JFormattedTextField) you can use a javax.swing.text.DocumentFilter this calss was created with this purpose.

Regards M.
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mihai,

Thanks for telling. So I must look to it and change my implementation.
 
Erkin Kanlioglu
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi People

Should system which we are developing for B&S allow "CSR A" to update or delete a record belongs to "CSR B" ? (Does not make sense in real world for same level users)

What I understood from given API is there is no need for authorization for anything at all.


Thanks
 
chris bajada
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Erkin, I don't really think you need to cater for that scenario... look out as if you do something like that, it might fail their automatic test
 
Jeremy Botha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This raises an interesting point.

Two separate ways of handing out-of-bounds data have been presented. One is to throw a runtime exception, another to do validation on the data.

I personally prefer the second method. I put input validation on any methods which capture user-entered data. If I'm especially paranoid and believe that my data layer will be accessed by other means further along the product lifecycle I will put validation in the data layer as well.

Does anyone else do this? Or is it more 'correct' to throw IllegalArgumentException and other runtime exceptions? I look at these as indications that something has gone VERY wrong; I don't believe that Exceptions should be used for general data validation etc.

comments? thoughts? Should this be split to a new thread?
J
 
Mark Smyth
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeremy Botha:
This raises an interesting point.

Two separate ways of handing out-of-bounds data have been presented. One is to throw a runtime exception, another to do validation on the data.

I personally prefer the second method. I put input validation on any methods which capture user-entered data. If I'm especially paranoid and believe that my data layer will be accessed by other means further along the product lifecycle I will put validation in the data layer as well.

Does anyone else do this? Or is it more 'correct' to throw IllegalArgumentException and other runtime exceptions? I look at these as indications that something has gone VERY wrong; I don't believe that Exceptions should be used for general data validation etc.

comments? thoughts? Should this be split to a new thread?
J



I did both of these things. In my facade class I validate the customer id in the book method and throw a checked exception if it does not match.

However in the data class if there is an attempt to update a records using a String[] array with too many or too few fields, or with a field String that is too long or not ascii data then an IllegalArguementException is thrown.

It would be just as acceptable to trim the excess data in a String or ignore the extra fields. The important thing is not so much how you handle invalid data, but rather that you do not let it corrupt the data file.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic