-
Notifications
You must be signed in to change notification settings - Fork 70
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
Using plain methods in controller instead of actions() with closures #37
Comments
@zmeyc, thanks. Last time I checked reflection it was possible to lookup only attributes. Please open PR with your experiments, I'm open to ideas that are both easy to use (API close to Rails) and has better compile time checking than it is current implementation. |
I've experimented a bit and it seems that it's impossible to obtain method name using reflection. I've found a reference to _stdlib_getDemangledTypeName which could work, but I wasn't able to compile it: http://stackoverflow.com/questions/27912078/where-are-stdlib-gettypename-stdlib-getdemangledtypename-declared |
Most of these dynamic features are actually from ObjectiveC runtime, not from pure Swift. Swift currently is very static language with almost no dynamic features, so it's definitely not easy to build some framework that is easy to use (think Rails) and at same time offers compile time checks. Let's keep this issue opened, maybe somebody comes with great solution. |
Another more safe way I was experimenting with - assign closures to attributes and then pass those attributes to filters, but I didn't feel it was good enough. |
Well, whats seems confusing is that if you override the |
Further, as convenience methods, would pull requests be accepted adding func index (handle:(Request)->(Response) ) {
actions["index"] = body
} to allow users to write index() { req in
//response
} |
Hi @joedaniels29, thanks for comments. Looks like documentation isn't up to date , tests actually calls Also feel free to experiment with your ideas. The only issue I see with your actions suggestion is that it makes inconsistent actions - most likely an application will have more actions than those standard actions. So extra actions will still need full definition. |
Yup, Agreed. Though, in the interest of dryness, I'd recommend it. It will be easy enough to just misspell the standard CRUD routes and then have to track down what you messed up. It would make standards typesafe |
its worth noting that though other frameworks (ie. vapor) are allowing regular method names, they're adding an extra compilation step to make it all work. |
I was thinking if it's possible to map routes directly to methods of Controller. For example:
Resources can be implemented by adopting protocols. I.e. TodosController adopts Resource protocol and implements some or all of the protocol's methods. router.resources() will expect a class which adopts that protocol.
Filtering can be implemented by looking up method names via reflection.
What do you think of this approach?
The text was updated successfully, but these errors were encountered: