Scaling config data

[Blake Gearin]

Hi, I'm struggling to understand how (or if) GM_config can be used for namespacing or dictionary-like data.

As an example, say I'm storing config for both books and their associated movies. They can have a name and genre, and also come in red or green.

(I know this isn't particularly userscript-y, but wanted to keep it simple)

With a JS object, it might be stored like this:

{
  movies: {
    green: {
      eragon: {
       name: ...,
       genre: ...,
      },
    },
    red: {
      eragon: ...,
     ...
    }
  },
  books: {
    green: {
      eragon: ...,
    },
    red: {
      eragon: ...,
     ...
    }
  },
}

Here's a couple of approaches I've considered:

1. Templates as fields

   • To make every field have a unique label, append all the attributes together, like book_red_eragon_name or movie-green-eragon-name.

   • The problem with this is you'd have a lot of fields, making it difficult to maintain. And when adding a third color, the number of fields that would need to be added is tediously high as it's multiplied.

2. JSON in Textarea Fields

   • If you choose at top-level namespace it would be relatively easy to store the rest of the data as JSON in a textarea. In this case, combining two might make sense:

     ## Green Movies
     
     {
       "eragon": {
         name: ...
       },
       ...
     }
     
     ## Red Movies
     
     {
       "eragon": {
         name: ...
       },
       ...
     }
     
     ## Green Books
     
     ...
     
     ## Red Movies
     
     ...

   • This is relatively scalable, but seems to nullify the value of GM_config (providing a user-friendly interface for non-technical folks). I could just as easily store a hard-coded object in my JS file that users could modify directly.

3. Multiple config instances

   • On first read of this section in the documentation, it doesn't seem possible to initialize multiple instances. However, I see in the unit test the "Open Translation Demo" calls a GM_configStruct() instance from GM_config.init() and this at least looks nested in nature.

   • I read through the code and sort of understand what it's doing. But I'm not sure if it quite fits the scenario I'm describing. Even if it does apply directly, I'm not sure how "deep" it could be taken.

Thoughts? Questions? Is it not built for config shapes like this? If so, that's fine, I'd just like to know.

I see nesting was talked about a looong time ago on #24.