Open mattstratton opened 4 years ago
I have been able to get a pretty decent POC for the initial stuff - it's using frontmatter in the program.md
file as explained above (right now it only works with .start
and .end
set as datetime; I think it will be pretty easy to add the exceptions for if ".date
is set, etc, once I have all the logic working).
Basically, there are just a couple places where the date and time stuff gets pulled/set; I can set those to use variables or something based upon if the element has .date
set or not, etc.
I will try to also get #6543 addressed in this one as well (since I have to touch ignite code anyway)
I also occurs to me that if we aren't doing any time-zone conversion stuff, we can actually turn .date
and .start_time
etc into a single constructed datetime field in the migration; we would just set everything to a standard timezone offset (this might cause some weirdness if we wanted to have the TZ conversion stuff mentioned in #9819 if, for example, all migrated events are set to -6:00 offset, etc...but this could just be some search-replace cleanup for existing events when we want to add it; we could also have an optional frontmatter flag that enables the conversion so you have to opt-into it, so you won't get caught in a weird way)
I got it all working in the template! I also handled #6543; the way it works looks a little like this:
"old-style" ignite block in schedule:
{ title = "Ignites", type = "ignite", start = 2019-08-27T13:00:00-06:00, end = 2019-08-27T13:30:00-06:00 },
ignite block that is custom/named:
{ title = "Ignites", type = "ignite", block = "ignite-1", start = 2019-08-27T13:00:00-06:00, end = 2019-08-27T13:30:00-06:00 },
inside the ignites[]
array:
ignites = [
{ title = "veronica-hanus", block = "ignite-1",date = 2019-08-27},
{ title = "jay-gordon", date = 2019-08-27},
{ title = "adam-shake", date = 2019-08-27},
{ title = "jason-yee", date = 2019-08-28},
{ title = "heidi-waterhouse", date = 2019-08-28},
]
So what ends up happening (bear in mind that you would likely not mix elements with a block
and without in the ignites[]
array, but it works if you do) is this:
So if you want to go "traditional" style of one ignite block per-day, all you need to do is set a program element of type "ignite" for that date, and put a bunch of elements in ignites[]
with that same date (that is how it works today).
If you want to have multiple ignite blocks on the same day, you use the optional block
parameter in both program_elements[]
and ignites[]
entries.
OK, so this is a pretty big improvement! Keeping in mind that my test doesn't have a full second day in the program, here are the differences in processing for the program page:
cumulative average maximum
duration duration duration count template
---------- -------- -------- ----- --------
1m1.969173719s 746.61655ms 2.321037845s 83 program/single.html
7.208317ms 7.208317ms 7.208317ms 1 new-program/single.html
Ignore "cumulative duration" as obviously it only processed 1 program vs 83.
BUT...
7 ms vs 746 ms! That's huge, especially since the program page is the heaviest thing we do. If my math checks out, we will be processing ALL the program pages in under a second, vs taking a minute to do them now.
Of course, if we end up "unarchiving", we'll have more program pages to handle, but this is a big win.
UPDATE: the program template with a full day (so basically, this was with 12 talks and 10 ignites) is 11.621999ms, so it's still pretty dang efficient.
For the Program page template, I think that the easiest thing to do (and the least impactful) is to move the YAML for program out of the data file and into the frontmatter on the
program.md
file for the event. That frontmatter will look HUGE, but it should work.If we want to make enhancements to how the program template functions (later!!), the move will be to create a new template for type
"old-program"
and then we will need to update all the existingprogram.md
files to use that type, and have new stuff use the new version.I did go back to the survey I ran years ago to see what people prefer, and data fields in a YAML file (for this purpose, TOML in frontmatter is just as fine) was the overwhelming preference.
if we migrate the YAML "as-is" to TOML, I think the frontmatter for a program page would look something like this:
and so on...the upshot of this is that we get timezone info. But we don't necessarily have that. We might have to do something where "if we don't know the timezone from another field in the main data file, we just set it to US central" because this is only for historical programs and if the time isn't right, it's probably Not the End of the World.
We could also have the following be supported:
so the template code for the program page would have to be pretty weird; it would have to check for an element that has
date
set, and if so, it works differently. This might be okay (we did this for thespeaker
page to handle the backward-compatibility with the data files; it means that in the template you have one big giant "if" statement to say "do I draw the program the new fancy way or use the old way?" and go from there.We also need to handle #6543 as long as we are here; I think it works the same way. If it detects any elements with
date
set, then it displays ignites a certain way; if not, it will do whatever magic I come up with to handle this idea of multiple ignite blocks per day (fyi, this is something that I need to solve for 2020 Chicago, so it's Kind of Important to me, lol)