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
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -127,11 +127,11 @@ Of course, the data can be accessed directly by using $match<subject> or $match<
127
127
128
128
=head2Adding some flexibility
129
129
130
-
The REST grammar so far will handle retrieves, deletes and updates ok. However, a I<create> command doesn't have the third part (the I<data> portion). This means our grammar will fail to match if we try to parse an update URL, and everyone will scream. To avoid this, we need to make that last I<data> position match optional, along with the '/' preceding it. This is easily accomplished by adding two question marks to the TOP token, to indicate their optional nature, just like a normal regex. So now we have:
130
+
The REST grammar so far will handle retrieves, deletes and updates ok. However, a I<create> command doesn't have the third part (the I<data> portion). This means our grammar will fail to match if we try to parse a create URL, and everyone will scream. To avoid this, we need to make that last I<data> position match optional, along with the '/' preceding it. This is easily accomplished by adding a question mark for the grouped '/' and I<data> components of the TOP token, to indicate their optional nature, just like a normal regex. So now we have:
131
131
132
132
=begincode
133
133
grammar REST {
134
-
token TOP { '/' <subject> '/' <command> '/'? <data>? }
0 commit comments