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

Command line routing and routines #13

Open
alganet opened this issue Oct 24, 2011 · 3 comments
Open

Command line routing and routines #13

alganet opened this issue Oct 24, 2011 · 3 comments
Milestone

Comments

@alganet
Copy link
Member

alganet commented Oct 24, 2011

We could create a CliRequest that when injected into the Router instead of the traditional Request could route things via Cli calls. Bash and linux are somewhat RESTful. An experimental mocked cli request is in the Router test suite for a long time now, but it isn't very friendly for users.

Considering a $r->get('/users/*', 'MyUsersController') sample route, both a HTTP GET /users/alganet and a php application.php get users alganet cli route should route to the same point. Custom route verbs could be used, such as $r->install('/', 'MyInstallController');.

Much of the code from the current Request class would be moved to an AbstractRequest that would be extended to both Request and CliRequest.

@augustohp
Copy link
Member

This should be moved/mentioned in the Cli component and closed here, should't it?!

@alganet
Copy link
Member Author

alganet commented Mar 29, 2012

I don't know yet. I've always though on Cli as a command line interface for Config. Maybe we should move Cli to Config or Foundation.

Cli responsibility is spread, hard to tell where things must go.

@alganet
Copy link
Member Author

alganet commented May 24, 2012

I'm willing to do this. There are a couple of things to figure out before then:

  • The path and method can be abstracted as words: get users alganet == GET /users/alganet
  • Query string options can be abstracted as getopts get users --since=2009 == GET /users/?since=2009, though Respect\Rest will not abstract that for you. You'll need to do that on the route implementation. Additional ->env("cli"), ->env("http" and ->env("cgi" can be added as routines to improve abstraction without increasing coupling.
  • Mime negotiation could be abstracted to bash negotiation or something like this. Language negotiation can be done using env vars. A lot of thinking on how that could work is needed.

Just to make clear: this issue doesn't cover transparent HTTP/bash mapping. It allows developers to do that by providing tools to serve content in both HTTP and bash, as they're both RESTful.

@augustohp augustohp modified the milestone: Ideas May 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants