event templates functionality, for sessions and session messages.

[thehunmonkgroup]

check out the detailed description of this feature in views/event-templates.ejs.

basically, it provides the ability to pre-configure sessions and session messages via templates hosted on google spreadsheets, which can then be used for quick session creation and message sending.

i needed this for my personal install, as we create/destroy a lot of standard sessions in one event.

i'd also like to add the ability to clear all current sessions, and will probably do so in another pull request.

i could have gone the route of creating forms for the CRUD functionality, and, instead decided to model it loosely on the current implementation of the events page.

couple of things worth noting that aren't perfect:

• could probably reduce some code duplication on server vs. client side validation
• the current implementation is a clickjacking security hole i believe, but since it only reloads the templates already in the spreadsheets, i decided to forgo the warning dialog for ease of use.

[yourcelf]

This is pretty cool. A couple questions on the implementation:

In a sense, there is already CRUD for an event structure: the normal controls for building an event. So rather than encoding lists of sessions and so forth in spreadsheets, would it make sense to just have a "save this as a template" button in the admin menu on an event, and persisting them that way? Similarly, there could be a button in the modal for authoring a message to sessions to persist that message as a template. This could eliminate the complexity and duplication of validating all of the fields and fetching and parsing spreadsheets.

On the other hand, if we stuck with spreadsheets as the data backend for a template, does it make sense to persist the spreadsheet data to redis? It seems like for the session message templates this might be ideal (though those are also much simpler to encode), but since event creation is something that happens only once in the lifecycle of an event, you could just fetch and parse the spreadsheet locally.

It sounds like for your installation, you're not likely to have a large number of disparate admins who manage their own separate events; but that's what we face on our installation. Does it make sense to have a single set of templates for all admins, or to associate templates with particular admins? I could see advantages to both ways; the one thing that doesn't seem awesome would be admins creating too many not-very-generally-useful templates that would just get in the way for other admins running completely different sorts of events.

[thehunmonkgroup]

i like all these questions.

using the existing forms to save templates did occur to me, but it was fairly late in the development cycle when it did. i can say that you'd still need to build functionality for editing and deleting templates, while the current approach handles all CRUD (albeit a bit on the heavy-handed side with completely reloading stuff). this approach also makes it a lot faster to add/edit/delete multiple templates, vs. lumbering through a bunch of web forms.

couple of thoughts on storing locally vs. parsing on event creation, and on global vs. per-event/admin templates:

• one more advanced feature i already considered was listing all the loaded templates on the event creation page, and letting the event creator choose which templates to 'import' into that event. this would certainly help us more, as we will have many session templates, and only need a few active for each event we create.
• it also seems possible to add another column to the spreadsheet to declare who 'owns' the template (gmail email address?), and only pull those templates when that admin is hosting an event, and ones that have no owner are global and always get pulled in. my assumption is that event admins know what they're doing, and can handle the extra complexity of working with the spreadsheet properly.
• if one or both of the above were added, then i think it would make more sense to store the event templates with the event, and not globally.

happy to further clarify or answer any other questions you have.