#6 - timestamp playlist inserts when adding to a live showEndTime

[eric-gilbertson]

add timestamp to track inserts on playlist if show is realtime, eg
insert is done during the user specified begin/end times. also simplify
markup generation by breaking large functions up and by using CSS to
reduce the amount of required markup. other changes include:

• show time in 12 hour format
• show album & artist names as 'first last' (was 'last, first')
• remove the butt ugly heart logo
• simplify playlist banner
• add playlist CSS classes
• normailize border width
• add border between playlist header and body
• improved track edit glyphs
• replace " with ' for readability
• update zkdbSchema.sql and provide an upgrade script
• protect against empty arrays in for loops (generate ugly warning messages)
• make album link clickable in playlist edit mode (now matches view mode markup)
• added 'created' to tracks query (as last column in the select statement)
• added function to check if insert is within show start/end times

[RocketMan]

Hello Eric,

Thank you, all of the issues named previous have been addressed; I have merged the PR.

As promised, I do have a couple functional comments for your consideration. None of these needs to be addressed before we deploy (if ever), but I did want to share:

• As a DJ moves spins up or down in the playlist editor, can zk really know the specific times of those spins anymore? As it stands now, the timestamp does not move with the spin, which seems correct... one would not want to move the timestamp, as the times in the playlist would then be out of temporal order. However, one other solution would be to clear the timestamps of the two tracks involved the move, since moving the spins suggests we can't reasonably guess times anymore. I am not fussed about this and it seems fine either way; it is just that I have some doubts about what the correct/expected behaviour should be.

• Right now, Import Playlist is timestamping the playlist if it is imported within the window of the show. There is at least one DJ who does this sometimes. The result is that the moment of import is getting timestamped onto every spin in the playlist. This is a somewhat rare edge case, but it does happen. One suggestion is the following: Keep the time test logic in insertTrack the same, but add a new parameter to insertTrack (both on the implementation and the prototype class IPlaylist) to force automatic timestamps off. This parameter would override timestamping, so that even if insertTrack's time window test would otherwise succeed, no timestamp would be applied. There is only one vector where timestamps are applicable (ui/Playlists.php and any possible future JSON API playlist code in support of Angular/client-side playlist editing). Those invocations could set the parameter to apply the automatic timestamp logic.

Thank you again for this contribution, and for your suggestions to unify the branches and to enhance the installation instructions. Your contributions are making zookeeper even better!