Config "2.0" (separate settings file & JSON-based calendar map)

[derekantrican]

Let's face it - the settings area in Code.gs is getting bloated and we're still getting lots of requests for more settings. Additionally, the calendar map with the addition of ICS-specific colors (#243) could use a revamp.

One of the users suggested this and I think it's a great idea: a separate config file (eg "Config.gs" or "Settings.gs")

Details:

This would consist of 2 major changes:

1. A separate "Config.gs" or "Settings.gs" (or similarly-named) file
2. Changing the sourceCalendars mapping to be an array of JS objects (JSON) instead of the current "array of arrays" (which it really should've been from the beginning, but I was much more naïve in my programming knowledge when I wrote that)

Benefits:

1. Specific purpose
   Currently, Code.gs has the "main" syncing code with calls into Helpers.gs for augmentation/parsing/etc. But Code.gs also has settings vars and the calendar map. A "Config.gs" type file would be very obvious (from the name) what it's for.
2. Less aversion to future suggestions/additions
   In the past, we've gotten a lot of suggestions for settings, but we've been wary of adding new ones as not add clutter. With a "single purpose file" we could have a setup like below and add to the "advanced settings" section

// Calendar mappings
var sourceCalendars = [{...}];


// General settings
var howFrequent = 15;               
var onlyFutureEvents = false;       
var addEventsToCalendar = true;     
var modifyExistingEvents = true;    
var removeEventsFromCalendar = true;
var addAlerts = "yes";              
var addOrganizerToTitle = false;    
var descriptionAsTitles = false;    
var addCalToTitle = false;          
var addAttendees = false;      
...


// Advanced settings
var overrideVisibility = "";
var addTasks = false;

var emailSummary = false;
var email = ""; 
...

3. Additional settings in the sourceCalendars mapping
   Like mentioned above, we added per-ICS color support to the sourceCalendars map in Adding some color to the events #243. There have been some good suggestions for additional settings since then (eg customizing the name of the "source calendar" so that addCalToTitle works a little differently). With the JSON-based structure, it would be easy to add new optional settings without clutter (they would not need to be listed if not specified and we could just handle null in the code as an unset setting).
4. Easier upgrading to newer versions of the script
   When users update their copy of the script with the new version, I imagine they usually copy over the settings/sourceCalendars section to the new copy of the script. But, of course, that can get a bit messy. With this change, you can leave Code.gs, Helpers.gs, etc alone and only change a single file.
5. Backwards compatibility
   If users don't know about the upgrade they might keep the same "array of arrays" format that we've always been using. We should plan to keep supporting that as well.

Of course, the hope still is to one day use a "nicer for non-coders" HTML-based GUI (and there were some working prototypes for that a few years ago) but there are some small benefits to exposing the code (eg people can read the code and see what it's doing) and we never really took the time to figure out how to do final polishing, direct people to UI after "install", handling upgrading, etc.

Please share your thoughts below on what you think!

@jonas0b1011001 as FYI

[derekantrican]

Been thinking about this a bit recently. Another thought: in addition to my comments on sourceCalendars above (being an array of js objects - to allow extension) we might want to add some additional validation & custom exception messages because I think this is the hardest part of setup for "non coders". We may want to also be backwards compatible and allow the 2D array style that we currently have.

Also, from a bit of testing, when you open a Google Apps Script project, the Code.gs file will be opened by default. But if there is no Code.gs file, I believe it opens the first one. We could move the large instructions comment blocks to an "About.gs" & rename Code.gs so that this is the first thing people see when they open the script.

[jonas0b1011001]

Also, from a bit of testing, when you open a Google Apps Script project, the Code.gs file will be opened by default. But if there is no Code.gs file, I believe it opens the first one.

I don't think that's actually the case (or not anymore).
From what i tested, as long as it's the same session, the editor will reopen the file that was open on the last visit. Otherwise it will always open the first *.gs in the file list.

I do like the idea of an About.gs as an entry point with Install/Update instructions and the remainder of the comment block from code.gs.
Besides that:

• Settings.gs with settings & filters
• Main.gs with startSync(), install(), uninstall()
• Helpers.gs, ical.js.gs and tzid.gs as we have them now.