Fix installName vs installNameSlug references

[Martii]

There's a bunch of inconsistency on this... no wonder I was thrown off... this will take a bit of time.

[Martii]

@Zren
Do you know what the primary reasoning behind using the identifier extension of Slug is?... I reread everything we have on it here but seems it just appeared with the nomenclature at one point mid last year.

1. Is it an intermediate (temporary) variable?
2. Does it symbolize anything special compared to a non-suffixed installName ?
3. ???

[Zren]

Install name was sometimes used with .user.js tacked on at the end. I wanted to differentiate from it.

https://github.com/OpenUserJs/OpenUserJS.org/blob/e593ee2a3e7a566721c75ef877002096a83a2faa/controllers/scriptStorage.js#L28
https://github.com/OpenUserJs/OpenUserJS.org/blob/e593ee2a3e7a566721c75ef877002096a83a2faa/controllers/scriptStorage.js#L71

A slug is what Discourse used to call a normalized string in the url. Eg: /t/1234/stickied-topic From a topic with an id of 12345 and a title of Stickied Topic.

Notice how the spaces (and other non-alphanumeric characters) are converted to dashes and everything is lowercased?

My use of the word slug is probably wrong since in our case since a slug is usually used in pair with an id in the url. Since a slug can have collisions. Eg: 'A title' => 'a-title' collides with 'a-title' => 'a-title'. Also, a forum topic's title can change.

[Martii]

Install name was sometimes used with .user.js tacked on at the end.

So you wanted installName to indicate the authorname/scriptname[.user].js and installNameSlug to indicate authorname/scriptname.

I did some web research on this and WordPress also uses this nomenclature (of slugs)... They treat the url, minus the domain which is mostly true in OUJS, as the "base" and then the "slug" on the end with human readable terms... however we have the "...Slug" treated as a base too with "base/edit`, "base/source", etc... so overall I'm not sure the term slug is applicable and a bit of a stretch... however I stopped midstream of removing "... Slug" because of its use as a final intermediate. I also saw some distinction between the trailing extension too however that is inconsistent across the controllers (hence this issue)... so I got rather confused as to the reasoning.

Thank you for sharing your insights and objective on this. I'll need to ponder some more on what to do next here.

There is going to be a time soon where I probably have to split this value into it's individual components and treat them individually to work out an end-bug that I'm hunting for its root cause... this of course will make the code a little less efficient in the short term (and possibly long term) but way more readable for finding bugs e.g. I may end up either hard coding .user.js into the necessary views (and/or perhaps the routing if possible) or removing them in the applicable controllers before processing. Thanks again.

[Zren]

I'd use scriptFilename for strings with user/scriptname.user.js and scriptSlug for user/scriptname.

[Martii]

Some (ever changing possibly) notes for this issue:

• A little less of a stretch could be to use the term URI with this Euler diagram showing the overlaps/subsets ... where a full URL, again the domain is mostly assumed in our coding, so /base1/slug1|base2/slug2 would be either be not suffixed or suffixed with URL... and a fragment of the URL would be a URI. URN's are weird and they somewhat resemble the express routing tokens (named params lists to be specific) currently found here. ... (keep in mind slug1|base2 will most likely need to be split out for handling)

[Martii]

scriptFilename ... scriptSlug

I like the idea of making more unique variable names because grep'ping on installName can pose some issues... so perhaps making it more specific can be a goal here. :)

[Martii]

Doing some quoting here from MDN and confirmed:

Note that encodeURI by itself cannot form proper HTTP GET and POST requests, such as for XMLHTTPRequests, because "&", "+", and "=" are not encoded, which are treated as special characters in GET and POST requests. encodeURIComponent, however, does encode these characters.

node and express are decoding GET and POST requests which wreaks havoc if certain characters are used in a discussion/script/user.

This is the failure we have between "slug"ging and URI's just in general. e.g. we must use *URIComponent to resolve these (individually handled) no matter how ick the address bar looks... still running a test but probably won't get back to this until after the holiday.

[Martii]

Since I'm hitting this issue wall with other issues, as I expected which is why this issue is open, this has to be done first before any more new features can be added.

Adding BLOCKING to this...

This will entail a DB migration and installName will become an object in the model of strings as such:

EDITED

installName = {
  utf : 'authorname/scriptname' + '.user.js', // For DB access
  url : encodeURIComponent('authorname') + '/' +
          encodeURIComponent('scriptname') + '.user.js' // For browser access
}

... unless anyone has any other idea... I've ran most of this through @sizzlemctwizzle already and he can't think of any additional options at last chat.

Whether the naming is "slug" or not makes zero difference here other than how it is perceived... but either the utf property can be slugged e.g. GM cleaned or the url property can be slugged e.g. GM cleaned.