checklist behind-the-scenes

1 Replies, 4398 Views

(10-28-2019, 02:38 PM)Pablo392 Wrote: if we were to take this over we probably would have to make some changes

If you take it over, you get to make whatever changes you want Wink

The tables you added all look fine. Just two notes about the changes:
- You removed 72 Robo Millie from 2015/4 Smile You have to be careful with stuff like that. If a user had only 73 Charlie (the next line) checked, then viewed the page after that line went missing, they'd now have 74 Chillin Sidney checked, and Charlie would be unchecked!
- There's one more thing you need to add. When I made that codepen site, I split the CSS and javascript out into some separate files. In the original .html (which you should probably be pulling from, if you're not forking from the codepen which puts the <head> somewhere else, sorry), there's a 'var table_names' near the top, and you'd need to add each of the new waves into it, to get their checkboxes saved. That comma-spearated list is how the js knows where to start parsing names.

I use emacs, so still a text editor though it gives me syntax highlighting, automatic indentation, etc.

The html is just a static list of engine names, sometimes with numbers, and organized into tables of tables for display and managing the checklists. *All* the linkages happen at run-time in the browser, with js: *nothing* is pre-defined, so there's no way to make mistakes with linkages (as long as the group/engine names all get spelled right). Even adding 'img' tags happen in the js: the js adds the img tag by parsing the text of the engine group+name and adding '.jpg' to the end (which causes problems if the page is translated, so clearly wasn't the right solution).

Linking up re-releases is handled automatically by the js. All the features based on names (like clicking on a blister pack and highlighting all that pack's engines in the blindbags section) happens by the js parsing the names in the tables. Each line in a table is expected to look like:
<optional text><space><optional theme<space>><engine name>
Where <optional text> is the bag number. So look at the unnumbered tables and you'll see a space between the input tag and the engine.
<engine name> is assumed to be one word, unless 'namelen' is set in the td (e.g. set namelen to 2 for "Diesel 10"). If there's anything left, it's assumed to be the theme name (so that can be any number of words), and then the theme name (for the purposes of the "Highlight...By theme" dropdown) can be overridden by setting class="hlgroup" and setting the hlgroup variable in the td.
TLDR, just keep copying what's already there, just like you did....

The specific function for linking the re-releases is 'findRereleaseMatches()'. It looks for the 'rerelease' tag, and builds an array of arrays of engine names (parsing like I described the lines in the previous paragraph). Then once it has that list, it goes over the entire blind bag list and pushes the element containing a matching engine onto the right sub-array (so if you have multiple re-releases of an engine, as long as any one of them gets marked with "class=rerelease" they'll all get checked appropriately for the "find matching re-releases" feature; they only all need to get that class name for the "include re-releases in total" and "hide re-releases" options to work correctly). Then highlighting just involves looping over one of those sub-arrays, after checking their checkbox states if desired (function highlightUncheckedRereleases()).

So no, there are no unique IDs: the html file itself is the master list of engines. I knew if I had to run everything through some external program and maintain separate lists of stuff I'd never be able to stick with it at all. So *all* the counting, matching, highlighting, and whatever else, just happens in the javascript. So adding a new wave *only* requires adding a new row or separator, and then the list of engines in their boilerplate "<td><input># theme name</td>" lines, and adding the wave id to the list of waves to be scanned by the js ('var table_names') at the top. (Adding a new wave on its own is pretty simple; what got to me was all the other sets, unique engines, blister pack releases before blind bags, and so on, and keeping all that organized, especially after I let 5 or 6 things accumulate before adding them to the list.)

It was a design choice, and it was mine Smile if someone else is going to maintain the list going forward, they are free to revert it Smile

Then of course the engine names are totally ignored when saving the checkbox states into Local Storage. The checkbox states are just a bitmask of the order in which the engines are listed. Which means you can never _insert_ an engine in a table or _remove_ one (if you made a mistake, you need to use NEVERDISPLAY and DONOTCOUNT, plenty of examples of that!), only _append_ to the end, but also means that if you make a typo in an engine name or need to change the group or name (like if I got Bill/Ben backward or the wrong theme) it can just be fixed in the html and everything will continue to work and users won't lose any data.
[-] The following 1 user Likes drewbenn's post:
  • Super
Thank you Drew
[Image: super-smiley-emoticon.gif]
[-] The following 1 user Likes Super's post:
  • drewbenn



Users browsing this thread: 1 Guest(s)