Stuart Craig

Greenhorn
+ Follow
since Aug 17, 2006
Merit badge: grant badges
For More
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 Stuart Craig

Originally posted by Roy Mallard:
I mean the field types (string, date, number etc.) are not given in the data file, so you need to get the type information from somewhere.
I currently hard-code the field types in a class, although I might change this to read the field types from a .properties file.



I believe the assignment specifically states what information is allowed in properties files and that doesn't include schema details. I'd suggest that by adopting such a strategy you run the risk of being marked down or failing.

I understand the purpose of what you are suggesting. The requirements state that we should strive for a flexible implementation and that, in turn, implies that the code which does the physical reading from the file should be generic i.e. independent of type and format.

I'm currently trying to introduce this concept into my implementation by injecting into the "file reader" a strategy or strategies which encapsulate the following information:
  • The relationship between record index and the offset from the start of the file of the specified record;
  • The relationship between the record as a whole and it's individual fields, and the attributes of those fields (e.g. name, size, type).


  • This approach gives me the flexibility to vary the behaviour of my file reader by injecting a strategy which contains hardcoded rules and values (possibly of use in early prototyping), or one which expects and reads the UrlyBird schema metadata (the final submission to the examinar), or one which reads a different schema format altogether (for use in some hypothetical future datafile format).

    Unfortunately I've hit a mental brick wall whilst trying to iron out the aesthetics of my full implementation. I suspect that I'm too hung up on the style of my solution, but I can't help shaking the feeling that the examiners will mark on style (or design as they might call it).

    Originally posted by Alan Mehio:

    If "alone" mode (local)there will be a database input field which says something like that "please locate your data base on your local machine since you are running a local mode".

    If it "network" mode ( client newtwork mode) then you will not see any indication to locate a database; hence, there is no indication to any local mode



    In summary, I've interpreted the requirements thus (I've stated my reasons in previous posts):

    The user may select network mode by specifying the appropriate commmand line parameter.

    In "standalone" and "network server" modes the user is prompted to enter the details of the database file. The user will have the option of free typing the file specification or using a file manager dialogue to choose the database file (this last part is not strictly required, but creates a better user experience in my opinion).

    In addition, in "network server" mode the user is prompted to enter the details (e.g. port number) of the remote accessible service which will support database access for the "network clients".

    In "network client" mode the user is prompted to enter the connection details (e.g. IP address, port number etc.) for the "network server" which will accept and process database access requests. The user will not have the opportunity to enter a database file specification in this mode, since all access is proxied through the "network server".

    Cheers,
    Stuart

    Originally posted by Mihai Radulescu:
    The "indication" in this case is the command line parameter.

    Regards M.



    Thanks. That's the interpretation I have decided to go with.

    Stuart

    Originally posted by Anna Kafei:
    I agree with your view. However, I would state that in my choices.txt.



    Thanks. That was the answer I was hoping for.

    Cheers,
    Stuart
    Hi,

    I'm looking for some reassurance on my interpretation of the following requirement/s.

    The instructions state that standalone mode � �is selected using the single command line argument that is permitted� and also say later that the application must ��accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely�.

    Is it safe to assume that both statements actually refer to a single requirement, restated in two different ways, or are the instructions stipulating that, having selected networked mode via the setting of the correct command line parameter, the user should still be able to select standalone mode while entering the initialisation details.

    I�m currently leaning toward the former interpretation (i.e. network mode is specified via the command line and nowhere else) because I can�t see the value in allowing the user to choose �standalone� mode immediately after they have specified �network� mode at the command line.

    Does anyone else have a view on this?

    Thanks,
    Stuart