Changes to path matching

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Changes to path matching

Paul Sandoz
Administrator
Hi,

The specification has undergone two changes (and will undergo a third,
see later) and i have implemented those two changes in the trunk:

1) Path parameters match 1 or more characters that are not '/'
    (previously it was zero or more of any character), unless the final
    parameter is unlimited, in which case it is the same as before.

2) Path parameter names are matching with the following regex:

     "\{([\w[-\w\.]*)\}"

    i.e. the name must begin with a word character then zero or more
    word characters, '-' or '.'.

I suspect and hope that such changes will not have much effect on
existing implements, although this is anecdotal based on how much i had
to change the existing unit tests.

The third change that will occur will be to support general regular
expressions. As part of this we will be removing the 'limited' parameter
as of the @Path annotation, so instead of this:

   @Path(value="contents/{path}", limited=false)

one would do this:

   @Path(value="contents/{path: .*}")

It opens up a very powerful way to match e.g.,

   @Path(value="contents/{number: \d+}")

but guns, hair triggers and feet come to mind, so it is very much user
be aware.

Paul.

--
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changes to path matching

Frank Martínez
Hi,

On Wed, Jul 23, 2008 at 8:57 AM, Paul Sandoz <[hidden email]> wrote:

> Hi,
>
> The specification has undergone two changes (and will undergo a third, see
> later) and i have implemented those two changes in the trunk:
>
> 1) Path parameters match 1 or more characters that are not '/'
>   (previously it was zero or more of any character), unless the final
>   parameter is unlimited, in which case it is the same as before.
>
> 2) Path parameter names are matching with the following regex:
>
>    "\{([\w[-\w\.]*)\}"
>
>   i.e. the name must begin with a word character then zero or more
>   word characters, '-' or '.'.
>
> I suspect and hope that such changes will not have much effect on existing
> implements, although this is anecdotal based on how much i had to change the
> existing unit tests.
>
> The third change that will occur will be to support general regular
> expressions. As part of this we will be removing the 'limited' parameter as
> of the @Path annotation, so instead of this:
>
>  @Path(value="contents/{path}", limited=false)
>
> one would do this:
>
>  @Path(value="contents/{path: .*}")
>
> It opens up a very powerful way to match e.g.,
>
>  @Path(value="contents/{number: \d+}")
>
> but guns, hair triggers and feet come to mind, so it is very much user be
> aware.
>

Will be general regexes supported only on path params or in the path itself too?

i.e. @Path(value="contents/.*/{number: \d+}"

> Paul.
>
> --
> | ? + ? = To question
> ----------------\
>   Paul Sandoz
>        x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Frank D. Martínez M.
Asimov Technologies Ltda.
Blog: http://www.ibstaff.net/fmartinez/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changes to path matching

Paul Sandoz
Administrator
Frank Martínez wrote:
>
> Will be general regexes supported only on path params or in the path itself too?
>
> i.e. @Path(value="contents/.*/{number: \d+}"
>

Only on the path params, so you could do this:

  @Path("contents/{anon: .*}/{number: \d+}")

we considered unnamed path params but concluded it easier that they
should always be named. This enables us to easily retain the same order
rules for path templates (number of params, number of literal characters).

Paul.

>> Paul.
>>
>> --
>> | ? + ? = To question
>> ----------------\
>>   Paul Sandoz
>>        x38109
>> +33-4-76188109
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>

--
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changes to path matching

Frank Martínez
Hi,

On Wed, Jul 23, 2008 at 9:30 AM, Paul Sandoz <[hidden email]> wrote:

> Frank Martínez wrote:
>>
>> Will be general regexes supported only on path params or in the path
>> itself too?
>>
>> i.e. @Path(value="contents/.*/{number: \d+}"
>>
>
> Only on the path params, so you could do this:
>
>  @Path("contents/{anon: .*}/{number: \d+}")
>
> we considered unnamed path params but concluded it easier that they should
> always be named. This enables us to easily retain the same order rules for
> path templates (number of params, number of literal characters).
>

Very good, because then maybe i can refactor the Automata matching
algorithm to support general regexes without changing the structure to
a graph.

> Paul.
>
>>> Paul.
>>>
>>> --
>>> | ? + ? = To question
>>> ----------------\
>>>  Paul Sandoz
>>>       x38109
>>> +33-4-76188109
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>
> --
> | ? + ? = To question
> ----------------\
>   Paul Sandoz
>        x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Frank D. Martínez M.
Asimov Technologies Ltda.
Blog: http://www.ibstaff.net/fmartinez/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changes to path matching

Paul Sandoz
Administrator

Frank Martínez wrote:

> Hi,
>
> On Wed, Jul 23, 2008 at 9:30 AM, Paul Sandoz <[hidden email]> wrote:
>> Frank Martínez wrote:
>>> Will be general regexes supported only on path params or in the path
>>> itself too?
>>>
>>> i.e. @Path(value="contents/.*/{number: \d+}"
>>>
>> Only on the path params, so you could do this:
>>
>>  @Path("contents/{anon: .*}/{number: \d+}")
>>
>> we considered unnamed path params but concluded it easier that they should
>> always be named. This enables us to easily retain the same order rules for
>> path templates (number of params, number of literal characters).
>>
>
> Very good, because then maybe i can refactor the Automata matching
> algorithm to support general regexes without changing the structure to
> a graph.
>

I guessed that might be the motivation behind your question :-)

Paul.

--
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...