Skip to content

Commit b3cca33

Browse files
committed
group optional slash(/) and data so data does not parse without slash (/)
1 parent bbb9dec commit b3cca33

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

doc/Language/grammar_tutorial.pod6

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -127,11 +127,11 @@ Of course, the data can be accessed directly by using $match<subject> or $match<
127127
128128
=head2 Adding some flexibility
129129
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:
131131
132132
=begin code
133133
grammar REST {
134-
token TOP { '/' <subject> '/' <command> '/'? <data>? }
134+
token TOP { '/' <subject> '/' <command> [ '/' <data> ]? }
135135
token subject { \w+ }
136136
token command { \w+ }
137137
token data { .* }
@@ -147,7 +147,7 @@ Let's imagine, for the sake of demonstration, that we might want to allow these
147147
148148
=begin code
149149
grammar REST {
150-
token TOP { <slash><subject><slash><command><slash>?<data>? }
150+
token TOP { <slash><subject><slash><command>[<slash><data>]? }
151151
token subject { \w+ }
152152
token command { \w+ }
153153
token data { .* }
@@ -222,7 +222,7 @@ This is what we've come up for processing our RESTful URIs so far:
222222
=begin code
223223
grammar REST
224224
{
225-
token TOP { <slash><subject><slash><command><slash>?<data>? }
225+
token TOP { <slash><subject><slash><command>[<slash><data>]? }
226226
227227
proto token command {*}
228228
token command:sym<create> { <sym> }
@@ -290,7 +290,7 @@ Here we are back to our grammar, as we left it.
290290
=begin code
291291
grammar REST
292292
{
293-
token TOP { <slash><subject><slash><command><slash>?<data>? }
293+
token TOP { <slash><subject><slash><command>[<slash><data>]? }
294294
295295
proto token command {*}
296296
token command:sym<create> { <sym> }
@@ -428,7 +428,7 @@ And this is the grammar and grammar actions that got us there, to recap:
428428
=begin code
429429
grammar REST
430430
{
431-
token TOP { <slash><subject><slash><command><slash>?<data>? }
431+
token TOP { <slash><subject><slash><command>[<slash><data>]? }
432432
433433
proto token command {*}
434434
token command:sym<create> { <sym> }

0 commit comments

Comments
 (0)