Symbol route matchers

[CrowdHailer]

This perhaps belongs as a plugin rather than as a core feature. However I don't think it would conflict with any existing thinking. Simply it is symbol matchers as available in Roda, http://roda.jeremyevans.net/rdoc/classes/Roda/RodaPlugins/SymbolMatchers.html.

Somewhere is set up a regular expression for a particular symbol

match :integer, /\d+/

Then when routing some of the ordering is no longer important

get '/users/:integer' do |id|
  # Stuff
end

get '/users/something' do
  # This route also works
end

This is particularly useful if you want to mix in routes

class App < Scorched::Controller
   include Scorched::Rest(:identifier => /ID\d{3}/)
  get (/terms) { send :terms }
end

[Wardrop]

I've never seen Roda before. It looks interesting and seems to have similar goals to Scorched.

As for the predefined regular expressions, they're kind of nice I suppose. It shouldn't be too much effort to implement. Just another Scorched::Options object like we use for conditions, which define a symbol and a pattern. When the pattern is parsed, it'll just involve adding a little bit of additional logic to the compile method.

I'll keep this issue open and have a go at implementing it when I got a moment.

[Wardrop]

What would some default symbol matchers be if I was to implement this? The only two obvious examples I can think of are:

numeric: /(\d+)/
alpha_numeric: /([a-z\d]+)/i

[CrowdHailer]

I think those are the main ones. My main usecase is to separate resource id's from other routes. They are most likely to be numeric or user defined.

My last project had

/UM123 -> see item 123
/123 -> see item 123
/other -> can't remeber what exactly.

So mostly it was about defining my own in a slightly more manageable way.

Possibly file types if people are working that way

:pdf => /(\w).pdf/

I also wondered but might be a bit much about handing over a coersion block. Might be a bit much and errors could be annoying

integer: /(\d+)/, ->(str){ str.to_i}
# or
float  /(\d*\.?\d*)/, &:to_f

[Wardrop]

Yeah it's going to be mostly project specific, but I can see it being useful where you may otherwise need to repeat an ugly regex. I do like the optional coercion block idea. As far as error handling, we'd just make sure that any exception raised in the coercion block is handled as if it occurred in the target proc. It'll be handled in an error filter up the chain.

[Wardrop]

This has been added in v0.25.