I am deleting a "mob" then redirecting to the index page. My problem is that if I use $this -> dispatcher -> forward() when I get to the index page (which displays all mobs) the deleted mob will still display due to forward()'s behavior of not refreshing the page.
Usually I solve this problem by using response-> redirect(), however I cannot use it here as I use dispatcher to send params like this.
return $this -> dispatcher -> forward(array('controller' => 'mob', 'action' => 'index', "params" =>array("alert" => "Mob deleted.")));
My question is, what is the best practice to send my parameters but also refresh the page so deleted objects aren't rendered after dispatching?
I get to the index page (which displays all mobs) the deleted mob will
still display due to forward()'s behavior of not refreshing the page.
That is not entirely true and this has to do with caching database calls during the request or you simply not refreshing the displayed data. I'd say more if you provided the code for both actions, but this shouldn't be hard to figure out on your own. Your index action must load the model set every time its called, so if you have deleted a model in the forwarding action, there should be no reason for that model to be present in the consecutive load in the forwarded action.
Generally forwarding would be better technique than reloading the page – you don't make another request to the server for no real reason. If you need to use redirection there's a number of ways you can pass alerts between the pages, e.g., storing the alert queue in the session or database. Phalcon has the Flash component for displaying flashing messages, which allows to use the session approach.
Related
I'm on a Production System 6.4.2.1, but had the same problem on a newer version 6.4.14
If you enter the shop for the first time with a query parameter URL for example https://shop/?affiliateCode=test&campaignCode=test, the codes will not be saved to the session to use it for example in the cart or have this flags on an order (which is standard shopware function).
After you entered the shop you have to navigate to another page than paste in the url with query parameter to get it saved to the session.
If you than delete your site data and enter the shop again with this
query parameter url its not working again.
This issue happens only in production if cache is turned on.
As far as I could investigate this issue I noticed that for the very first time symfony fires the "BeforeSendResponseEvent" which Shopware listens to but this just terminates the first request with our query parameters
So now if you navigate to another page and enter the url with query parameter again, than Symfony will trigger the KernelEvent which Shopware listens to to add the query parameters to the session.
Did anyone else had trouble with this issue before?
Yeah, I think you got it right. Looking at the listener the corresponding event isn't dispatched if the http cache is hit. The affiliate and campaign parameters become part of the cache key and therefore consecutive requests will result in cache hits, avoiding the listener.
I think your best bet might be to create a ticket on the issue tracker. Ultimately this will need to be fixed in the codebase.
For now the only way to be sure the codes are stored in the sessions would be to publicize URLs with the parameters on routes that aren't http cached, like /account/register. For workarounds you could register your own controller that avoids the http cache and redirects to the home page, just for the sake of not missing these parameters. Another option would be to listen to to HttpCacheHitEvent as described here and set the codes to the session yourself, even though you might also have to start the session at that point.
I am working on a simple PHP site that involves needing to be able to forward a request made by the user to another page (note that I said forward, and not redirect). I am aware of how to redirect by manipulating the header variable, but I do not wish to do this, as explained below.
I am trying to write a very simple MVC-patterned mailing list app in PHP, drawing from my knowledge of the same in JSP. One of the things that I appreciated about JSP was that you could both forward or redirect a request. For my purposes, I need forward as I wish to keep the request parameters (whereas redirect will drop them).
Here is a description of what I wish to accomplish:
Retrieve input from a form (ie. /add.php)
Process the input in the page called by the form's action (ie. /process.php) and add a success message to the request object
Forward to another page (ie. /display.php) to display the success message in the request object
The only way I am aware of passing the request message to display is to add it to the request object and then access it from the forwarded page. However, the only way I have had success in transitioning to another page is through using the header method, which drops the request object (from what I can tell). I want to find a way to forward the request (object) to the new page, so that I can access the request variables from the new page.
Is there actually anyway to do this in PHP? Java's getRequestDispatcher.forward() is so nice, but I can't find an equivalent through searching. I've tried several similar questions, including the following, but I've never actually found one where both the question and the answer were what I wanted. Most of the answers seem to have something to do with cURL, but I don't want to actually retrieve a file, but simply forward a request in order to access the request object from another page.
Does PHP have an equivalent of Java's getRequestDispatcher.forward()?
Let me know if I should include anything else?
I believe you can do this with include. Before submitting the form just use, as inclusion, in main page:
include ("add.php"); - where the input forms are
after processing the information, include the display.php in the same way; using this, display.php will use same parameters from header, because is included in the same main page.
briefly: add.php, process.php and display.php will be modules for the mother page, but loaded in different state of form processing.
Hope it helps!
use curl with different method get,post. it will sent a request and also get back the response.
The most common method I see of passing messages to the end user from page to page is called session flashing.
This is when you store a variable temporarily in the session until it is read.
Assuming you already have sessions in use:
On process.php:
$_SESSION['message'] = 'Your data has been saved!';
On display.php:
if (isset($_SESSION['message'])) {
echo $_SESSION['message'];
unset($_SESSION['message']);
}
You could also store the entire Request object in the session.
So if I am aware, PHP provides just basic set of tools in this case. And there is nothing like "forward" in HTTP originally. It is just frameworks' abstraction/idea. There are two ways to achieve that: copying all params from request and doing new real HTTP request (with redirect) or internal forward: so framework would create fake request and call another controller and action without issuing a new physical HTTP request.
If a user tries to log in and the login fails the page should display an error message to the user. There are two main ways I see to do this: use a form action on the HTML page and in the php script if the login information is incorrect redirect with header to the login page with a $_GET value like loginfailed. The login page would check for this value and if it exists it would display the error.
The second way I see to do this is not use a form at all and instead use JQuery to capture the submit button press and use AJAX to determine if an error occurs. The php file would echo back a status and the javascript file would interpret it and if it was loginfailed, it would use JQuery to append the error message on to the page.
Now I will go over what I feel the pros and cons of each method are.
Method 1 Pros:
Very simplistic with no need for JQuery, Javascript, and AJAX.
The error status is displayed within the URL as well.
Method 1 Cons:
Since there is a header call, a redirect is necessary. Also, the login page must be reloaded. It is a small page but it is a reload nonetheless.
The status message is displayed in the URL. This means that users can type in status messages in to the URL and receive error messages on the page for errors that did not actually occur. Is this a problem? Maybe. Maybe not.
Method 2 Pros:
Since it is using AJAX, there is no need to load another URL and thus, no extra page is loaded.
This method uses JQuery to update the page with the error message so no redirect is necessary.
The error status is not displayed in the URL.
Method 2 Cons:
Much more complex than the first solution.
An external javascript file is needed and must be loaded every time the login page is accessed regardless of whether or not it is used.
The default behavior of the submit button is overridden and annulled. Its only behavior comes from its interaction with the javascript file.
What would SO do? I would like to stay away from answers such as "it depends on how much traffic your site would have" if that would be at all possible.
Always use the simplest solution possible until/unless there's a very good reason to do otherwise. It's better to finish something that's maybe (and maybe not) less than ideal than to deliver something gold-plated eventually, maybe.
Also, I generally prefer to follow a progressive enhancement strategy, such that everything works without Javascript, and then add Javascript to make it work in an improved manner. This has the added benefit of being functional, even when/where Javascript is disabled.
I think you fail to grasp the matter.
Login is not something self-sufficient. It is used to change state of the site. But with no reload it will not be changed. So, page reload is required anyway. or user will have to do it manually to get access to the authorized section.
Is login the only site feature that uses JQuery/AJAX? If not - why you're worrying about loading this library once, when most likely it will be loaded at every page?
There are still clients with JS disabled, for various reasons. A good web application will always let these clients in, even at cost of less functionality.
The latter is the main question, most important one. Why to choose between two? Why not to use both? - one for compatibility and another for usability?
So, I'd suggest to create basic functionality using GET to pass come codes, not messages.
And optionally improve it with some AJAX bells and whistles but with JS-based reload on succesful login anyway
I am fairly new to Codeigniter and I am wondering on some Codeigniter best practices. When should i use redirect() versus using
$this->load->view
It seems that when I use redirect() then $this->session->set_flashdata works like it should but when i use
$this->load->view
the message is displayed after an additional request.
I think you really answered your own question.
Use redirect() when a simple flash message at the top of another page is an appropriate response, use $this->load->view() when you're providing an entire page worth of feedback for whatever the incoming request may be.
So for example, when a new user signs up the "Success" page would be a loaded view and perhaps when a user edits something in their account a flash message "Changes saved" or soemthing similar on the same page is sufficient.
Redirect is also useful for two other common problems:
When a resource in you app is moved (and you want clients to remember the new URI)
After POSTing a form as one step in preventing back button rePOSTs
Your observation is correct that whenever you create some flashdata it is only available the time. That is because flashdata is just a special type of session which will available for your on the next request and after the next request it will automatically be deleted. You don't have to take care of its deletion.
This can be tested with the code:
$this->session->set_flashdata( 'test', 'testing' );
echo $this->session->flashdata( 'test' );
Nothing will be printed. But now the next time execute the following code:
echo $this->session->flashdata( 'test' );
You will find the required output. Doing it one more time will not give any output. This is how they work. For details check the section Flashdata in http://codeigniter.com/user_guide/libraries/sessions.html
For the current page you don't require flashdata just pass the data to the view. Here is the code:
$data['test'] = 'testing';
$this->load->view('sample_view', $data);
Bottom line is that use flashdata with redirect() and for views you should pass variables. Hope this helps!
it's pretty simple. what url do you want the user to be on? if they are on url1 and post data back to url1 and you just load a different view, they will still be on url1. if you redirect to url2, they will go to url2.
You need to use PRG - Post/Redirect/Get pattern.
Redirect and load view aren't the same if you have the form in the content of the page.
Scenario:
There is a view, view_1 with form in it to debit money from a account. After submission of the form in the view_1 you want to jump to view_2 with a success message and you have 2 options to achieve the same. 1. load view_2 with success message or 2. redirect to view_2 with flash data carrying success message.
Option 1: load view_2 with success message
When you submit the form and refresh, it will cause resubmission and cause multiple debit from the account, which shouldn't be the case. You too can see the alert popping od "Confirmation of form resubmission".
Option 2: This is the right answer
PRG
PRG - Post/Redirect/Get
PRG is a web development design pattern that prevents some duplicate form submissions which means, Submit form (view_1) -> Redirect -> Get (view_2)
Under the hood
Redirect status code - HTTP 1.0 with HTTP 302 or HTTP 1.1 with HTTP 303
An HTTP response with redirect status code will additionally provide a URL in the location header field. The user agent (e.g. a web browser) is invited by a response with this code to make a second, otherwise identical, request to the new URL specified in the location field.
The redirect status code is to ensure that in this situation, the web user's browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted.
Source
Double Submit Problem
Post/Redirect/Get Solution
What is the difference between redirect and forward in Zend framework?
When we should use redirect and when should we use forward?
Imagine you get a phone call in the office. Someone wants to talk to sales. If you say "please call 123456" and hang up, this is redirect . If you say "wait a minute" and just transfer the call to them, this is forward. ;)
_forward() just forwards everything to another controller action, while _redirect() sends a header, meaning you create a new HTTP Request and go through the entire dispatch process with it.
For instance, if you call up http://example.com/foo/bar you'd call the foo controller and bar action. If you forward inside the bar action to the baz action, e.g. within the very same request, the browser would still be on the same URL, while when doing a redirect, ZF would instruct the browser to load http://example.com/foo/baz.
Essentially, _forward() does
$request->setActionName($action)
->setDispatched(false);
while _redirect() does
$this->_helper->redirector->gotoUrl($url, $options);
I usually do redirects when I want to prevent reload a page resulting in reposting form data.
See these:
Zend Framework, what $this->_forward is doing
http://osdir.com/ml/php.zend.framework.mvc/2007-09/msg00038.html
http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Controller/Action/Helper/Redirector.php
You would use _forward() for cases where you want the URL to stay the same - though beware, it does mean whatever base controller class you're using is called twice.
That may seem obvious or trivial, but if not kept in mind, can really screw up your application design, given that intuitive understanding of the flow is that one request calls one controller instance. E.g. it means request-scope singletons have to be declared as static, or _forward() will break them.
I would guess that a redirect sends a 301/302 back to the browser with a new URL, while a forward simply "forwards" the request to a different controller action internally but keeps the URL the same so the browser doesn't know any different.
1-redirect create a new response with header() information [302 Found or 301 == Moved permanently] and its will get to the dispatch cycle once again
2-forward change the execution flow to that new request without re enter the dispatch process again
The redirect action ends the current page process and redirects to another. All the context will change (new controller/action) as the browser receives a redirection. It connects to a new URL
Whereas the forward will stay on the same page, but will leave the context unchanged. You can see this as a function call. Your views will be loaded as usual.