Allow Dynamic, parameter-driven !includes

[nohorbee]

The following syntax for !includes should be allowed in resource types and traits.

#%RAML 0.8
title: My Sample API
resourceTypes:
  - collection:
      get:
      post:
        body:
          example: !include <<resourcePathName!singularize>>.json

[cybertk]

+1

[joetech]

+1

[sichvoge]

We will not add support for this feature immediately in v1.0! Don't panic, it's just for this version ;)

[aldhor]

+1 Create traits and resourceTypes for reuse commons operations and after this, rewrite the operations again for include examples it's a lot of work...

[sichvoge]

The problem is that !includes are resolved at YAML level where it does not know anything about parameters, since its a RAML construct. Unfortunately, thats not easy to solve without drastically changing how includes work.

[sichvoge]

An idea would be to bring !include one level up and introduce it as part of the RAML syntax. That would give us the advantage to do what the OP ask for and also that there is no need for a specific YAML parser anymore.

[InfopactMLoos]

Any update on this? Would be a valuable improvement for the project I am working on right now.

[sichvoge]

No direct update except that its definitely on the "idea" state and that we need to think about any implications bringing !include directly into the RAML syntax instead of a YAML extension.

I see more advantages doing that, but that's only me :)

[InfopactMLoos]

Ah YAML extension, I now understand what you meant with it being on the YAML level in the comments above. Because I could not find it in the YAML spec so did not really understand what you meant with it. Anyway, me and my company are using RAML more and more as we are turning processes into RAML microservies. And we would love to see this language evolve and become even better then it already is. Is there anything we can do to contribute to this feature request process?

[sichvoge]

For this feature request, it is important to understand different scenarios and how + when parameters should be resolved. I believe that this is not an easy change.

[alex-lairan]

This is on futur spec?

It could be very helpful ! 👍

[sichvoge]

We trying to figure out what the best way would be to do this. Most probably not a very easy task without changing some behavior.

[krodyrobi]

Any change?

Hit this as well and instead of doing resource types that are truly 'generic', had to duplicate quite a lot to get the required effect.