CSV Data Header Title

[theNerd247]

I noticed some problems involving an end programmer interface for accessing the data. First is that the programmer needs to know how the data is placed in the CSV file. Also, the names of two headers could be the same for instance you could store students in one header with the data formatted as: (String)Name,(int)Age and a header for teachers in the same way. With the current system there is no way to tell the difference between the two.

So then here are the suggested steps we take in making this change:

-CLEANUP: field names throughout all the files. The meaning of "header" seems to have changed its meaning. It should mean: a group of related data. --->see README for changes
-CLEANUP: the format of the CSVDataHeader class --> make things nice and clean: data in one field, data types in another, names of columns in another.

-ADD: field in CSVDataHeader to contain the Title for a header.

[laserswald]

We can make it all strings, which is how CSV does it- you will have to convert the strings to numbers and back eventually, and only the users of the library could possibly know what kind of data file it is anyway. I don't like the whole "including the type of data in the CSV file", since it breaks CSV (and isn't the entire point of converting to CSV the widespread compatibility of the format with spreadsheets?) and other programs will read it wrong. I propose a compromise: how about we have a CSV header file, wherein we place the specific data types that the file is. That way we can read and write to CSV files using this library and a spreadsheet program, but we can put other types of data into the CSV if we wanted.

If you don't wanna do that, then that's okay, too, but I think that having our own file format called CSV and totally not compatible with CSV is a major headache.

[theNerd247]

If you read the read me it is not Comma Seperated Values but Character Separated Values. I see the point you're making though. One of the points of this lib was to make things easier for FRC teams. This included non-programmers being able to edit data for robots to make things easier for debugging, low file sizes to leave room for other programs to save data on the cRIO (only a few megabytes are available) that teams write, and to allow for team programmers to use this lib as config data for the robots.

This brought up the problems: how to save the data in an easy to interpret format, allowing as much types of data in the file as possible, keeping as much data as possible in one file, and allowing for non-programmers (or newbies) to work with this lib quickly and efficiently.
The solutions: 1. create a CSV similar format that contains both data and metadata. --> this solves the first two issues
2. creating a GUI interface for editing a CSV file that will read/write data in the proper format.

I can see where the confusion with CSV and the this program come in. I like the idea of leaving it up to the end programmer to determine which data types they will be working with and just using strings as the base format. We can erase the conversion code in CSVDataHeader and stick to strings. We can also work on a universal CSV style writer/reader to allow the use of spreadsheets. I do see a collision with this though, and that is with the objective of this issue.

[laserswald]

Good deal, but I never said anything about commas. If I did, I was thinking you meant comma, since I use the term "Delimiter Separated Values" when referring to the filetype. It really doesn't matter, since it means the same thing. I definitely like the idea of making a normal CSV file importer/exporter. I can get started on that if you want.

[theNerd247]

Yes, please do. I'm running into issues with the GUI side. Go ahead and make a branch and push to my origin.

[laserswald]

Sounds good!

[theNerd247]

OK so:: TODO::

-CLEAN: CSVDataHeader.java to deal only with String data types. Also cleanup variable names and formatting.
-CLEAN: CSVFile.java -parser method (REFACTOR).
-change code to parse string data, change the header parser to allow for header titles
-ADD: -universal CSV read/write file structure.

QUESTION: is it faster to work with a 2-d String array or working with a 2-d Vector?

branch iss8 was allocated for this

[laserswald]

String arrays have to be resized, which means that the entire array must be reallocated and moved over, which takes a lot of time.

[theNerd247]

Thanks for the confirmation. That crossed my mind but I wanted to be sure.

[laserswald]

I am working on a 2D array, so hold your jets.

[theNerd247]

I got it. I just wanted to know if i needed to re-right things. I stuck with Vectors....will be pushing soon.

[theNerd247]

OK, current pull request for branch iss8 contains the solution for this issue. Send a personal message if you feel this issue needs to be re-opened