show file size of archived courses when unarchiving

[Alex-Jordan]

When at the Unarchive courses page, the list of courses now leaves off the ".tar.gz" and includes the size of the file to be unarchived. This will help me identify inefficiencies with how RS users are handling their courses. If I am about to unarchive a particularly large course, I will then go into it and see what can be trimmed. Usually, the faculty have put course archive files in their course. Or they are using images inefficiently. Or they copied entire folder trees for backup before editing local pg files.

I did this in a way to make it extensible. Perhaps there would be interest in also showing the date the archive file was last modified. Perhaps this is of tangential interest to @drdrew42 with #3043 in that the displayed course name could be the actual internal course name, not the file name with .tar.gz truncated off.

[Alex-Jordan]

This now has a few styling changes too, in separate commits.

[drgrice1]

I think it would be better to just update the listArchivedCourses method (instead of adding the statArchivedCourses method), and use the same format for showing archive files in the UI in the two places that is done (and the only two places where the listArchivedCourses method is used before this pull request). The two places are when unarchiving courses and on the main course admin page that lists courses and archived courses.

[drgrice1]

Just a quick note on coding. Please change this to

Suggested change

	while ($size >= 1024 && $unit_idx < @units - 1) {
	$size /= 1024;
	$unit_idx++;
	}
	while ($size >= 1024 && $unit_idx < $#units) {
	$size /= 1024;
	++$unit_idx;
	}

For an array such as @units, $#units gives the index of the last entry in the array which is equivalent to @units - 1.

As I have said many times, always use pre-incrementation rather than post-incrementation, unles post-incrementation is really needed. The only time that post-incrementation is needed is when the return value of the incrementation is used and the original value of the variable before incrementation is needed.

[drgrice1]

Part of the reason that I suggest just updating the listArchivedCourses method instead of adding the statArchivedCourses method is due to the messy structure of the created statArchivedCourses method. It first calls listArchivedCourses. That constructs a Mojo::File object representing the archive directory, lists all files in that directory with the .tar.gz extension, and returns the basename of all of those files. Then the statArchivedCourses method again creates a Mojo::File object representing the archive directory. Preprends it as a pure string (making it completely useless to construct the Mojo::File object) to the deconstructed Mojo::File basename of the listed archive files from the listArchiveCourses method. Note that if you have a Mojo::File object representing a directory, then you can get a Mojo::File object representing anything in that directory with the child method, and you can stat a file using the stat method.

If the two methods were combined much of that inefficiency and code clutter could be cleaned up. You just have to update lines 68-70 of templates/ContentGenerator/CourseAdmin.html.ep to use the updated return value.

Actually, I have put in a pull request to this branch that does the things I have mentioned.