You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/Language/grammar_tutorial.pod6
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,7 +75,7 @@ As you can see above, in TOP, the "<thingy>" token is mentioned. The <thingy> is
75
75
76
76
=head1Learning By Example - a REST Contrivance
77
77
78
-
Let's suppose we'd like to parse a URL into the component parts that make up a RESTful request. Let's decide that we want the URL's to work like this:
78
+
Let's suppose we'd like to parse a URL into the component parts that make up a RESTful request. Let's decide that we want the URLs to work like this:
79
79
80
80
81
81
=item1The first part of the URI we'll call the "subject", like a part, or a product, or a person.
@@ -140,7 +140,7 @@ The REST grammar so far will handle retrieves, deletes and updates ok. However,
140
140
# 「product」「create」
141
141
=endcode
142
142
143
-
Let's imagine, for the sake of demonstration, that we might want to allow these same URI's to be entered in by a user from the terminal. In that case, they might put spaces between the '/'s, since users are prone to break things. If we wanted to accommodate this possibility, we could replace the '/'s in TOP with another token that allowed for spaces on either side of it.
143
+
Let's imagine, for the sake of demonstration, that we might want to allow these same URIs to be entered in by a user from the terminal. In that case, they might put spaces between the '/'s, since users are prone to break things. If we wanted to accommodate this possibility, we could replace the '/'s in TOP with another token that allowed for spaces on either side of it.
144
144
145
145
=begincode
146
146
grammar REST {
@@ -217,7 +217,7 @@ This is what we've come up for processing our RESTful URIs so far:
217
217
}
218
218
=endcode
219
219
220
-
Let's look at various URI's and how they behave being passed through our grammar.
220
+
Let's look at various URIs and how they behave being passed through our grammar.
221
221
222
222
=begincode :skip-test
223
223
my @uris = ['/product/update/7/notify',
@@ -234,7 +234,7 @@ Let's look at various URI's and how they behave being passed through our grammar
234
234
# Sub: item Cmd: delete Dat: 4
235
235
=endcode
236
236
237
-
So with just this part of a grammar, we're getting almost everything we need. Our URI's get efficiently parsed and we're given a nice little data structure for the variables we need to work with.
237
+
So with just this part of a grammar, we're getting almost everything we need. Our URIs get efficiently parsed and we're given a nice little data structure for the variables we need to work with.
238
238
239
239
But look at that first line returned -- the I<data> token is returning the entire end of the URI as just one string. We need to be able to work with that 7 there. And that 4! Well, the 4 is easy... But the 7 had the extra /notify on the end, to signal the system to notify someone that a product was updated (perhaps).
0 commit comments