I'm beginning with php, jquery and Slim PHP framework and I got stuck in making Slim handler (route) for jqeryUI autocomplete request.
jqeryui autocomplete sends data as a term GET parameter, i.e. restapi.php/test/?term=hello
with Slim I can handle requests like restapi.php/test/hello, etc.
How to solve? My own considered solution is to rewrite the URL with the mod-rewrite (anyway basically using it with the Slim), but I'm not sure if this is the right way.
I'll be glad for your revisions and suggestions and if rewriting is the best way, some references with examples will be helpful for me. Thank you.
Actually, you probably shouldn't be using /* to do what you're doing. SLIM provides a method that can get the parameters of your request.
$dataIn = $app->request()->params();
This will give you an array of request parameters. So if your get request was something like this:
restapi.php/test/?term=hello&page=1&limit=15
$dataIn = $app->request()->params();
// $dataIn['term'] = 'hello'
// $dataIn['page'] = 1
// $dataIn['term'] = 15
Furthermore, you can grab specific parameters by throwing in an arg into the param() method.
$term = $app->request()->params('term');
It'll make life easier to have that distinction between your route parameters and request parameters. ;-)
Related
I am looking for a tool(class or method or ...) in Yii that, get a string (a url) and return an array contains module, controller, action and other get_params.
I cannot use explode because it is possible that module dose not exists or can not find out that 'a/b' is module/controller or controller/action !
This is kind a weird of Yii - why I can't just do something similar to:
$this->uri->segment(1);
Many FWs have this feature, so simple and obvious.
PS Also, why I should write methods in Helpers like above to do things FW must definitely do? And yes I don't want to act like:
$request = new Request();
$request->setUrl('/site/contact');
Yii::$app->urlManager->parseRequest($request);
This is totally stupid, not after setting the url - just f***ing grab it like in old wonderful days. They should write an alternative either.
I'm working on a Pylons project using Jinja2 templating. I want to test for the request URI and/or controller inside the Jinja2 templates - is there an equivalent to a getRequestUri() call? I can set a context variable as a flag inside all the controller methods to do what I want, but that seems a bit like writing my home address on each and every one of my house keys... i.e. not quite the right way to do it.
Solution: not quite a function call, but I can test against url.environ.PATH_INFO. It only gives me the URL path, not the hostname, and I don't know that it would give me the query string, but it gives me what I need.
I have a rails 3 app and now i implementing filter for my catalog. Filters form pass data to controller through GET request. As a result i have link like this in my browser after i submit
my form (apply search):
http://localhost:3001/shoes?filter%5BShoeBottomType%5D%5B%5D=2&filter%5BShoeClassification%5D%5B%5D=1&filter%5BShoeClassification%5D%5B%5D=2&filter%5BShoeElation%5D%5B%5D=3&filter%5BShoeElation%5D%5B%5D=4&filter%5BShoeElation%5D%5B%5D=5&filter%5BShoeLiningColor%5D%5B%5D=2&filter%5BShoeLiningColor%5D%5B%5D=3&filter%5BShoeLiningColor%5D%5B%5D=4&filter%5BShoeTopColor%5D%5B%5D=1&filter%5BShoeTopColor%5D%5B%5D=2&filter%5Bonly_action%5D%5B%5D=1&page=2
Is there a way to do URL more beautiful?
PS i dont want use POST request, because I read that it is bad for SEO
TLDR: just leave it.
HTML forms serialize in a straightforward manner; the parameters are named after the HTML elements. The actual issue here is how the form elements are named. It looks like they have names like filter[ShoeBottomType][]; look into your HTML to see the name attributes. Since you're in Rails, I'm guessing you having a filter hash passed to your Rails controller method as a single argument, and since Rails expects hashes to use a certain URL format for hashes and arrays (it has to know how to deserialize it from the request), the form helper writes the form that way. And yours is especially complicated because the hash values are arrays, hence the extra set of brackets. Then it's URL encoded and you end up with an ugly mess.
You could avoid some of this problem by passing the inputs individually back to the controller instead of as a big hash. Something like:
def index
shoe_bottom_types = params[:bottom_types]
shoe_classifications = params[:classifications]
shoe_elations = params[:elations]
...
which will get you to: /shoes?bottomTypes[]=1&bottomTypes[]=2.... That doesn't seem much better, and now your controller is all gross. And I don't see how you're going to get rid of the brackets entirely if you want to have more than one of the same filter. I guess you could get crazy and do your own parsing in your controller, like breaking apart shoeBottomTypes=1|2, but then you'll have to do your own form serialization too. Again, just not worth it.
Backing up for a sec, the SEO stuff doesn't make much sense. Search engines won't fill out your form; they just follow links. The real reason you should use GET is that (presumably), submitting your form doesn't have side effects, since it's just a search. See here; it's important to use the right HTTP methods. If you use POST, you'll get weird warnings on reloads and you won't be able to bookmark the search.
Backing up even further, why do you care, especially now that SEO is out of the picture? Just as a quick demo, I did a google search for the word "thing" and this was the URL:
https://www.google.com/#hl=en&output=search&sclient=psy-ab&q=thing&pbx=1&oq=thing&aq=f&aqi=g2g-s1g1&aql=1&gs_sm=3&gs_upl=764l1877l0l1980l6l6l0l0l0l0l89l432l5l5l0&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=220ef4545fdef788&biw=1920&bih=1086
So URLs for form submissions can be long. The user won't even look at it.
The only possibility I can think of for why you'd care about the length/ugliness of your URL here is that you want, separately from the form, to create links to certain searches. There are several ways to handle that, but since I don't know whether that's relevant to you, I'll let that be a follow-up.
So bottom line, it looks like I'd expect, and trying to fix it sounds ugly and pointless.
If you do not want to use a POST request, then there is no other way then to put the form values in the URL -- they have to get to the server one way or another.
On the other hand however, I do not see why doing a POST would be bad for SEO and I would love to see the article that stated so.
My suggestion is that you could add some custom routes to beautify your urls.
For example :
http://localhost:3001/shoes/Type/2/Classification/1,2/Elation/3,4,5/LiningColor/2,3,4/TopColor/1,2/only_action/1/page/2
This is far much shorter than your initial URL ;)
The counterpart is that, as far as I know, you have to use always the same order for params in your url.
The routing rule is the following :
match "shoes/Type/:type/Classification/:classification/Elation/:elation/LiningColor/:liningcolor/TopColor/:topcolor/only_action/:only_action/page/:page" => "shoes#show"
You can retrieve the passed values in params array. You have to split the string containing , in order to retrieve the multiple values.
In my rails 3 app, if I want a request to return json data does it matter if I use
mysite/show/1.js
or
mysite/show/1.json
I know it seems obvious to use the json version but in my responses they look the same to me.
First of all: It depends on the way you implement the respond_to block.
With 1.json it should be clear that it delivers data as JSON.
1.js could return Javascript that is evaluated by the page that requested it. In the early Rails/Ajax days this used to be done with RJS templates. See http://www.codyfauser.com/2005/11/20/rails-rjs-templates
I am using a payment method which on success returns a url like mysite/payment/sucess?auth=SDX53641sSDFSDF, but since i am using codeigniter, question marks in url are not working for me.
I tried routing but it didnt work. As a final resort i created a pre system hook and unset the GET part from the url for with i had to set
$config["uri_protocol"] = "REQUEST_URI";
It worked that way but all other links in my site were not working as intended, tried changing the uri_protocol but could not make it work by any means.
So basically my problem is handling the ?auth=SDFSEFSDFXsdf5345sdf part in my url, whenever the paypment method redirects to my site with the url mentioned above, it gets redirected to homepage instead of the function inside controller.
How can i handle this, i'm using codeIgniter 1.7 version, and couldnt find any way.
Please suggest some solution.
I think I would extend the core URI class, by creating new file at application/libraries/MY_URI.php which will extend the CI_URI class, then copy the _fetch_uri_string method and here you can add your logic if the $_SERVER['QUERY_STRING'] is present:
class MY_URI extends CI_URI
{
function __construct()
{
parent::CI_URI();
}
//Whatever this method returns the router class is using to map controller and action accordingly.
function _fetch_uri_string()
{
if(isset($_SERVER['QUERY_STRING']) AND !empty($_GET['auth']))
{
//Do your logic here, For example you can do something like if you are using REQUEST_URI
$this->uri_string = 'payment/success/'.$_GET['auth'];
return;
//You will set the uri_string to controller/action/param the CI way and process further
}
//Here goes the rest of the method that you copied
}
}
Also please NOTE that you must do security check of your URL and I hope this works for you, otherwise you can try extending the CI_Router class or other methods (experiment little bit with few methods, though the _set_routing is important). These 2 classes are responsible for the intercepted urls and mapping them to controller/action/params in CI.
I believe this thread holds the answer.
Basically add
$config['enable_query_strings'] = TRUE;
to your config.php
hope this will help you ! no need to change htaccess,just change your code.
redirect(base_url()."controller_name/function_name");
Looking at the example code in the Stripe docs:
https://stripe.com/docs/payments/checkout/set-up-a-subscription
one might conclude that you can only retrieve a checkout_session_id as a named GET parameter like this:
'success_url' => 'https://example.com/success?session_id={CHECKOUT_SESSION_ID}',
After playing around with .htaccess and config settings (as in previous answers) and finally getting it to work, it suddenly dawned on me that the DEVELOPER is in control of the success_url format, not Stripe. So one can avoid all the problems with a GET parameter by specifying the success url in the normal, clean Codeigniter format, like this:
'success_url' => 'https://example.com/success/{CHECKOUT_SESSION_ID}',
In my routes file, the incoming CHECKOUT_SESSION_ID string is passed to the Subscription controller's checkout_success method with this route:
$route['success/(:any)'] = 'subscription/checkout_success/$1';
The method accepts the $checkout_session_id like this:
function checkout_success($checkout_session_id)
{
// Do something with the $checkout_session_id...
}
I'm new to Stripe Checkout but this seems to simplify the integration without breaking Codeigniter's GET processing rules.