Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Controller name selection direction #217

Open
yuranos opened this issue Dec 13, 2017 · 3 comments
Open

Controller name selection direction #217

yuranos opened this issue Dec 13, 2017 · 3 comments
Labels
bug v2 Feature will be implemented in v2.0 only (master branch)

Comments

@yuranos
Copy link
Contributor

yuranos commented Dec 13, 2017

At the moment, the very last segment inside the root path is taken as a basis for controller name:
RAML:

/errors/{errorId}:
  get:
    description: Get all supported errors
    responses:
      200:
        body:
           application/json:
             type: ErrorInfo[]

would generate controller named:
ErrorIdController(it was actually errorIdController, just a couple of days ago before #215 fix).
While it's not critical and can easily be circumvented with:

/errors:
  /{errorId};

wouldn't it be nice to be able to set a flag inside a plugin that will use a reverse traversal for Controller naming?
What do you think, guys?

@stojsavljevic
Copy link
Contributor

Just to make something clear:

/errors/{errorId}:

produces ErrorIdErrorController while

/errors:
	/{errorId}:

produces ErrorController.
Am I correct @yuranos?

Bear in mind that path variable influences this behavior since for:

/abc:
  /efg:

and

/abc/efg: 

it's always the same - EfgAbcController.

So I'm not sure what kind of 'reverse traversal' you have in mind.
There is already reverseOrderInClassNames config option which can control the way controller names are generated. With <reverseOrderInClassNames>false</reverseOrderInClassNames> you'll get AbcEfgController instead.

@yuranos
Copy link
Contributor Author

yuranos commented Dec 14, 2017

@stojsavljevic , are you talking about RAML 1.0?
I have just tried reverseOrderInClassNames option for both:

/errors:
  /mycontroller:
    post:
       description: Checks and adds booking to customer
       queryParameters:
            siteKey : SiteKey
       body:
           application/json:
              type: AddBookingRequest
       responses:
            201:
              body:
                application/json:
                  type: BookingDetailsDto

and

/errors/mycontroller:
    post:
       description: Checks and adds booking to customer
       queryParameters:
            siteKey : SiteKey
       body:
           application/json:
              type: AddBookingRequest
       responses:
            201:
              body:
                application/json:
                  type: BookingDetailsDto

and the resulting name is always the same:
MycontrollerController

To be honest, I was not aware of that option, but it seems not to work as expected, or my expectation is different to the designed one.
I also haven't seen anything like EfgAbcController. As you can see in my example, class name always contains only one segment. What are we doing differently?

@stojsavljevic
Copy link
Contributor

Sorry I didn't explain it well.

So there are 2 config options:

  • resourceDepthInClassNames - number of resource levels used for controller name generation; default is 1
  • reverseOrderInClassNames - option to reverse the order of resource levels used for name generation. Obviously, you need to have resourceDepthInClassNames > 1 for this option to have impact; default is false

I was using resourceDepthInClassNames=2 and reverseOrderInClassNames=true in my abc/efg example. Sorry for the confusion.

To get back to your original question - we can consider ErrorIdController name a bug. It should be ErrorController like with:

/errors:
  /{errorId}

@stojsavljevic stojsavljevic added the v2 Feature will be implemented in v2.0 only (master branch) label Sep 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug v2 Feature will be implemented in v2.0 only (master branch)
Projects
None yet
Development

No branches or pull requests

2 participants