[RFC] vibe.web.web: Map _underscored variables without UDAs or injections to req.params

[wilzbach]

Here's another idea if mine.

In vibe.web.web, there's already support for injection of route parameters based on variables starting with _. This RFC takes this behavior and makes it auto-magically the default when a variable starts with an underscore and no UDA attached to it or no other injection method attached.
Of course the user can still manually define paths.

An example for this convenient style:

// /:id/
void getBook(string _id) {
   // get the book & return it
}
// /:parent/:id
void getBooks(string _parent, int _id) {
   // get the book & return it
}

[s-ludwig]

I didn't look at the code yet, but in the example above, should the "Book(s)" part of the method names really be ignored, or would it be something like /book/:id?

What I mainly wonder is how this maps to the REST generator and its collection feature. On the plus side, we already have an opt-out with @queryParam etc. But on the other hand, the usual silent breaking change topic may apply here, when _ parameters were used to read .params that were generated by other sources.

[wilzbach]

I didn't look at the code yet, but in the example above, should the "Book(s)" part of the method names really be ignored, or would it be something like /book/:id?

Oh yes. The idea is to avoid the redundant information in:

@path("/book/:id")
void getBook(string id) {
   // get the book & return it
}
@path("/book/:parent/:id")
void getBooks(string parent, int id) {
   // get the books & return it
}

and use underscored parameters as path of the path (if they aren't part of another feature of course):

// /book/:id/
void getBook(string _id) {
   // get the book & return it
}
// /book/:parent/:id
void getBooks(string _parent, int _id) {
   // get the books & return it
}

What I mainly wonder is how this maps to the REST generator and its collection feature. On the plus side, we already have an opt-out with @QueryParam etc. But on the other hand, the usual silent breaking change topic may apply here, when _ parameters were used to read .params that were generated by other sources.

Aren't the REST generator and the web interface completely different? AFAICT parameters that don't have a mapping or default value are currently not allowed for web interfaces, i.e. they result in an error.

Looking at Travis this seems to require a bit of work for older compilers, I am happy to invest this if you agree that this would be a useful feature. If you are still worried about breakage, we could hide it as config parameter or attribute that can be applied to everything (e.g. @autopath:)