So I have three different ways of solving the problem here.
Here we have one pattern for capturing VCard and one for capturing standard requests. In these controllers it is very clear exactly what they do by name and they do exactly one thing. It's very simple to chain them, nest them, etc because ultimately the name of the class tells you exactly what they do. It is a little more explicit code, but not a whole lot because you don't end up with many if (vcard) { do something } else { do something else }
paths in the code base. These also can be easier to test because of that very reason.
In this example I'm creating an abstract base class MyControllerUsers
from which all of my action based controllers inherit. The base class simply has helper methods to either get a VCard model or a standard one. It could just as easily have the same thing for VCard/standard views. That's all up to how you design your system.
For the last example I've also included an extension to the RESTful router that shows how simple it would be if this is what your application requires to achieve what you are looking for. Perhaps it could be done cleaner, but it is incredibly simple.
In the controller class I've added a couple of protected helper methods similar to what we put in MyControllerUsers
in the one.pattern.atomic
example above. If you look at one.pattern.atomic and one.pattern.monolithic there is really no substantive difference in code, but the organization of that code is (IMO) better in the atomic example. From a maintenance point of view it is always better touch as few files as possible when fixing issues or enhancing things. That makes it harder to make an accidental mistake for one reason or another. Additionally we still get a nice amount of that clarity in the controller names about exactly what this controller is doing, makes them easier to chain, nest, test, etc.