Jonathan Elkharrat

Ranch Hand
+ Follow
since Dec 31, 2008
Jonathan likes ...
Ubuntu
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jonathan Elkharrat

MVC
keep in mind that only searching and booking should be available as per spec...

The user interface for this assignment must satisfy the following criteria:
• It must be composed exclusively with components from the Java Foundation Classes (Swing components).
• It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
• It must present search results in a JTable.
• It must allow the user to book a selected record, updating the database file accordingly.
SEAN:

why you got 2 return statement? i think the inner one should be in a try clause..

Oladeji Oluwasayo wrote:two search field? how? but i thought criteria[n] should match field n, according to the instruction. i think all fields should be checked.



FROM THE SPECIFICATIONS:

The User Interface
The user interface for this assignment must satisfy the following criteria:
• It must be composed exclusively with components from the Java Foundation Classes (Swing components).
• It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
• It must present search results in a JTable.
• It must allow the user to book a selected record, updating the database file accordingly.

Dennis Grimbergen wrote:For the assignment you had to implement two search fields: one for searching by name and one for location.
In the near future the application may need more search fields.
So, is it easy to add some extra search fields, without having to rewrite parts of your GUI code?



that what i though but then it's not "with minimal disruption to the users" but rather "with minimal disruption to the programmers"
The specifications mentions that:
"Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs."
(notice it's a should and not a must)

now unless you do a complex runtime integration of functionality (that is, sending the logic to the client
which will make you fail the assignment since no security manager and code download is permitted in the
assignment) you'll have to change the executable at the client.

if so, then this is the only disruption the user can have (no matter if you do a minor change or write a completely
new application from scratch). I don't really get what they wanted to say in that sentence.
i used both regular expression and dateFormat..
does this function validate also 1999-3-14 ?
because i think it must be 1993-03-14 ...
i didn't read all the posts but i want to make few things clear:

1. there was not any requirement to implement a Reentrant lock!

2. yes, if someone call twice the lock he'll be deadlocked. just like the next case:



but thanks for the notice, i'll mention in my choices.txt and the javadoc that the lock
isn't re-entrant...


as you can see, even in the java SE API there's a Lock interface and a ReentrantLock
that inherit from it.

from the Lock javadoc:
A Lock class can also provide behavior and semantics that is quite different from that of the implicit monitor lock, such as guaranteed ordering, non-reentrant usage, or deadlock detection. If an implementation provides such specialized semantics then the implementation must document those semantics.

Roel De Nijs wrote:
I don't think (1) is a really big issue for the guys (and girls) who are currently working on this certification, because everybody (even those who purchased their assignment before June 1, 2011) tries to submit before August 1, 2011 so you don't have to take the mandatory course



the official date has changed to October 1, 2011... (oh my god, just noticed it's also my birthday )
REALLY? (pinching myself to make sure i'm awake)

OH... MY... GOD...

that's awesome news. it leave us enough time for the submission and re-submission

thanks a lot people..

Sean Keane wrote:

Roel De Nijs wrote:1/ no getters/setters in the transfer object


Interesting that you've no getters\setters - am I correct in thinking that means a client who receives your transfer object can modify the record number and send it back to the server? Is that not a concern?



i think he already pointed out that the record number isn't stored in the room (and it shouldn't, the room shouldn't know
about it's index in some database so this value has nothing to do in a Room Object/array.

Sean Keane wrote:
Where were your two methods to convert the transfer object to/from an array - were they in the transfer object class?

Roel De Nijs wrote:2/ String[] does not contain the record number, the record number is passed seperately


I'm not sure if you are talking about your DB API here or your conversion methods. Does that mean that:

* Your method to convert an String[] array to a Room object has two parameters - the String[] object and an integer record number?
* Your method to convert a Room object to a String[] did not contain the record number in the String[] ?



why would you need the record number for the conversion?
besides, methods in the DAO (such as update) get the data and the record number. doesn't that make obvious the
fact that the record number is not included in the String[]?
Rafal:
synchonizing the whole method make the lock/unlock useless.
the same question was asked here by Robert Benson.


so if you are afraid the record would be booked between the read and locking, how can you assure this record (and only this,
making the whole method synchronized will block the whole database) is not modified?


see also this question in the FAQ...

Sean Keane wrote:

He was suggesting that this approach was good because:

So, myDataObject can be used transparently in the client, without having to bother about the mode.



So I'm wondering where you got inspiration from this. Because this doesn't sound like a good design, where ServerImp IS-A RemoteInterface. It doesn't make sense to say that a local mode is remote.



this is the point. the server shouldn't know about whether he is a remote or local.
imagine you have a pizza store. you get orders both from local clients and by phone.
but your work is the same for both.
the worker (JVM/RMI) is the one who know where to deliver each pizza (record)..

just to emphasize, Remote interface doesn't have a method. making a class implement remote simply means its
method can now be accessed remotely (it's the equivalent of buying telephone for your pizza store).
the fact that the pizza have a telephone doesn't mean you always have to pass orders by the phone..
or simply put: Remote is just a "marker" interface (like Serializable).

by the way, implementing an interface is not exactly IS-A (as in extending a class).
it just says: "i can provide the functionality listed in that interface"...


so at startup i start a serve anyway. if it's local, nothing more to be done, just pass the reference to
the standalone client. if not specified local (not standalone mode) i'll put it in the RMI registry so it will
be visible to remote client. the type of the server shouldn't change, and the communication isn't handled
by the server anyway..
oh, sorry, i didn't notice he's synchronizing the whole server function.
i think i wasn't fully awake this morning.
my sincere apologies...