Changes references to api.parse.com and /1/ #458

montymxb · 2017-07-28T18:03:41Z

The current REST Guide and parts of the other guides contain numerous references to the now inactive api.parse.com, and the old /1/ version 1 mount path. As it stands this is misdirecting some individuals, as seen in #694 over in the Android sdk.

This proposes to change those old links into YOUR.PARSE-SERVER.HERE and /parse/ respectively. This also adjusts the initial wording for the REST Quick Reference section to remind the user that in the examples provided they should add their own domain, their own mount path and to consider whether they should be accessing over HTTP/HTTPS.

flovilmart · 2017-07-28T19:12:52Z

Would it be insane to make it dynamic?

montymxb · 2017-07-28T22:03:29Z

Umm possibly. Do you mean as in they would enter their own domain/mount path and all of the examples would populate as such?

montymxb · 2017-07-29T01:04:48Z

@flovilmart looking back at it there's a few hundred references roughly, primarily in the REST guide but also dotted in the other sdk guides as well. Adding in a feature to set their own server url & mount path would require tracking all of those, in addition to setting up the JS to update and editable fields to track those updates.

It could be done if there's an interest in it. But I'll have to go back and set something up.

montymxb · 2017-07-29T04:47:55Z

Added in the ability to set your own server/mount shown on the page. For the other guides they just contain a handful of references, and the server settings takes up space on the side nav bar, so I'm just leaving it out from everything besides the REST guide. Makes sense to have it there anyways since all the refs there were changed primarily.

This also makes a quick change to some css that wasn't quite right from #457. Just adds a float: left to account for some elements which were breaking down a bit more than they should. Case in point the getting started in the ios guide, the + should be level rather than breaking down.

Additionally I moved a change for platform extraction from #443 into _app/main.js. I missed it the first time around but that change was made in assets/js/bundle.js, which is built up from the former file. If the site were to be rebuilt before it was republished those changes would be erased.

@flovilmart can you take a look at this and give me your thoughts on it? It's tinkering with the sidebar, so I want to be sure this is acceptable before we move this along.

flovilmart

A few missing spots but I believe this should work on paper! That’s wonderful otherwise :)

I’ll try it today :)

flovilmart · 2017-07-29T09:21:36Z

_includes/android/push-notifications.md

@@ -480,7 +480,7 @@ curl -X GET \
 -G \
 --data-urlencode 'limit=1000' \
 --data-urlencode 'where={ "city": "San Francisco", "deviceType": { "$in": [ "ios", "android", "winphone", "embedded" ] } }' \
-https://api.parse.com/1/installations
+https://YOUR.PARSE-SERVER.HERE/parse/installations


flovilmart · 2017-07-29T09:21:47Z

_includes/android/push-notifications.md

@@ -493,7 +493,7 @@ curl -X GET \
 -G \
 --data-urlencode 'limit=1' \
 --data-urlencode 'where={ “objectId”: {YOUR_INSTALLATION_OBJECT_ID}, "city": "San Francisco", "deviceType": { "$in": [ "ios", "android", "winphone", "embedded" ] } }' \
-https://api.parse.com/1/installations
+https://YOUR.PARSE-SERVER.HERE/parse/installations


flovilmart · 2017-07-29T09:22:00Z

_includes/arduino/other.md

@@ -5,7 +5,7 @@ Because the Arduino SDK was designed to minimize memory footprint, it doesn't pr
 For example, you could sign up a user from Arduino through a REST call:

 ```cpp
-ParseResponse response = Parse.sendRequest("POST", "/1/users", "{\"username\":\"cooldude6\",\"password\":\"p_n7!-e8\"}", "");
+ParseResponse response = Parse.sendRequest("POST", "/parse/users", "{\"username\":\"cooldude6\",\"password\":\"p_n7!-e8\"}", "");


montymxb · 2017-07-29T16:50:10Z

Thought I initially missed some find and replaces or something, but yeah those spots have been left out of the 'switching' intentionally. In the other guides there was only sparing use of api.parse.com and using /1/. Adding in the custom server/mount functionality there would be taking up that extra navbar space for only changing a handful of lines in an entire guide :/. Not sure how assistive it would be if the user would have to hunt just to find the few references it changes.

I'm figuring with it just on the REST guide that's about 90% of our api references using a url & mount, everything else is just a sprinkling of curl refs and the one mention per guide for initializing that sdk (usually localhost). For the extra space it takes up on the left it would seem to have the most direct benefit there.

Just for reference the current platform limiting check is pretty simple, if we do wish to push this onto the other guides as well:

if(this.platform !== 'rest') {
    // only customizes for rest currently
    return;
}

montymxb · 2017-07-29T16:56:39Z

This just occurred to me, should we add a toggle for protocol, i.e. a drop down for http/https to further adjust the relevant examples? In quite a few cases where someone is learning it's likely they may just be testing on localhost.

montymxb · 2017-07-29T17:15:23Z

Okay this is a bit of a jump, but perhaps we can get this on all pages, and in a less intrusive fashion, by making it an expanding section of sorts. If sidebar space is of no consequence then maybe we look into fleshing this out to fully configure with that http/https toggling.

It would be even cooler to have additional substitution for keys too, like appId, masterKey, etc. Normally this would be ok as the JS is client side, so no information would be sent across the wire. However the docs are not served securely, so there's no guaranteeing the content on the page hasn't been modified in a malicious fashion, i.e. malicious JS injected by a MITM scraping inserted keys or something like that :/. Still it's food for thought, if we ever got a cert somehow via letsencrypt or something we could get a little bit fancier with this.

flovilmart · 2017-07-29T17:59:00Z

If we put the selection in a reusable section in the header that could work as well? AppIiD and client key would be ok to inject as public, perhaps we could store those in the local data store for reuse. I like that it’s JS dépendant and still renders OK without JS

montymxb · 2017-07-29T18:49:10Z

We can do that. I also realized that the mobile version for smaller screens won't have the sidebar as it becomes a drop down instead, which is just a <select> element. To make sure this shows up on mobile (and is reusable) I went ahead and modified it to be a separate section under common, which can be added right before the Get Started section. A bit cleaner and more manageable that way, and we can add as many customizable fields as we like.

I'll see what I can do about those public key fields, now that this is moving into it's own 'customization' section we can expand it however we like without filling up the sidebar 👍 .

And yeah I can toss those into the local storage to persist across page loads, that would be much more convenient.

…pId/clientKey. Fixes some raw html spitting out in replacement.

montymxb · 2017-09-27T15:11:35Z

@flovilmart are we still interested in pursuing this? If we don't want the hassle for setting up fancy server value substitution we should at least replace all the old refs.

flovilmart · 2017-09-27T15:19:07Z

Sorry, I need to jump back on that!

montymxb · 2017-09-27T15:22:52Z

No rush, just should make a note to get back to this at some point.

flovilmart · 2017-10-08T19:07:21Z

It's beautiful!

montymxb · 2017-10-11T18:53:08Z

@flovilmart just wanted to say now that this in now we can see what people think of the fields customization in the REST Guide. The other /1/ marks are changed, but just the REST guide has the new customization feature. I imagine if it's working okay I can add a PR later on to add it to other guides, if anyone calls for it.

flovilmart · 2017-10-11T19:10:12Z

that's good for the rest, perhaps we need a reset, button, I had trouble reverting to the original values

montymxb · 2017-10-11T19:13:32Z

Oh, that would be nice. I'll make a note to put up a PR for a reset button.

flovilmart · 2017-10-11T19:37:09Z

Haha thanks!

Benjamin Friedman added 2 commits July 28, 2017 10:51

Changes references to api.parse.com and /1/

5069287

Mention we use https in our examples

fff1b4e

Adds ability to set url/mount shown on page

6c1cd68

flovilmart suggested changes Jul 29, 2017

View reviewed changes

Benjamin Friedman added 4 commits July 29, 2017 12:37

Moves customization into a section on the main page. Adds protocol/ap…

3b36405

…pId/clientKey. Fixes some raw html spitting out in replacement.

Updated with some additional validation on the user provided fields

b729d1e

Disabled autocorrect on all fields

6a3f0e2

Remove spellcheck

8a674f1

flovilmart self-assigned this Sep 27, 2017

flovilmart approved these changes Oct 8, 2017

View reviewed changes

flovilmart merged commit b58e1f7 into parse-community:gh-pages Oct 8, 2017

montymxb deleted the remove-api.parse.com-refs branch October 11, 2017 18:50

Uh oh!

Changes references to api.parse.com and /1/ #458

Changes references to api.parse.com and /1/ #458

Uh oh!

Conversation

montymxb commented Jul 28, 2017

Uh oh!

flovilmart commented Jul 28, 2017

Uh oh!

montymxb commented Jul 28, 2017

Uh oh!

montymxb commented Jul 29, 2017

Uh oh!

montymxb commented Jul 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

flovilmart left a comment

Choose a reason for hiding this comment

Uh oh!

flovilmart Jul 29, 2017

Choose a reason for hiding this comment

Uh oh!

flovilmart Jul 29, 2017

Choose a reason for hiding this comment

Uh oh!

flovilmart Jul 29, 2017

Choose a reason for hiding this comment

Uh oh!

montymxb commented Jul 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

montymxb commented Jul 29, 2017

Uh oh!

montymxb commented Jul 29, 2017

Uh oh!

flovilmart commented Jul 29, 2017

Uh oh!

montymxb commented Jul 29, 2017

Uh oh!

montymxb commented Sep 27, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

flovilmart commented Sep 27, 2017

Uh oh!

montymxb commented Sep 27, 2017

Uh oh!

flovilmart commented Oct 8, 2017

Uh oh!

montymxb commented Oct 11, 2017

Uh oh!

flovilmart commented Oct 11, 2017

Uh oh!

montymxb commented Oct 11, 2017

Uh oh!

flovilmart commented Oct 11, 2017

Uh oh!

Uh oh!

montymxb commented Jul 29, 2017 •

edited

Loading

montymxb commented Jul 29, 2017 •

edited

Loading

montymxb commented Sep 27, 2017 •

edited

Loading