Re: [PHP] Using require instead of redirect architecture
On Wed, December 19, 2007 1:37 pm, Robert Erbaron wrote: Problems: - hitting back on p2.php shows the dreaded The page you are trying to view contains POST... If you dread seeing this, then play pinball with the user... -- OK and Cancel both generated unsatisfactory results Unsatisfactory in what way? - hitting refresh on p2.php runs the validation again, which means the validation code now has to be that much more complicated to trap for a second attempt, blah blah blah. Do you care that it's a second attempt? It's either valid input or it's not. If you really do care, then put an md5 token as a hidden input in the form, and store it in the db (or session) and mark it used after the first attempt. If that token is used then you know it's the 2nd (or more) attempt. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Using require instead of redirect architecture
Maybe I'm too old a dog to teach a new trick to. I've got the redirect example discussed a couple days ago working nicely. Back, Refresh, 'wrong username' - all work nicely. But I like the idea of reducing the load on the server, maybe alleviating some redirect pinball. So been trying to use require instead, and all hell has broken loose. Clearly I'm not structuring these pages correctly, but I've run into a conceptual wall of what I should be doing. p1.php: - display form - post to p2.php p2. php - grab and validate input - if good, require p3.php (which says congrats!) - if bad, set error message and require p1.php (which displays error msg and displays form again) Problems: - hitting back on p2.php shows the dreaded The page you are trying to view contains POST... -- OK and Cancel both generated unsatisfactory results - hitting refresh on p2.php runs the validation again, which means the validation code now has to be that much more complicated to trap for a second attempt, blah blah blah. So the architecture needs to look different. Been hitting my head against a wall - I'll be darned if I can figure out what it is. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using require instead of redirect architecture
Robert Erbaron wrote: Maybe I'm too old a dog to teach a new trick to. I've got the redirect example discussed a couple days ago working nicely. Back, Refresh, 'wrong username' - all work nicely. But I like the idea of reducing the load on the server, maybe alleviating some redirect pinball. So been trying to use require instead, and all hell has broken loose. Clearly I'm not structuring these pages correctly, but I've run into a conceptual wall of what I should be doing. p1.php: - display form - post to p2.php p2. php - grab and validate input - if good, require p3.php (which says congrats!) - if bad, set error message and require p1.php (which displays error msg and displays form again) Problems: - hitting back on p2.php shows the dreaded The page you are trying to view contains POST... -- OK and Cancel both generated unsatisfactory results - hitting refresh on p2.php runs the validation again, which means the validation code now has to be that much more complicated to trap for a second attempt, blah blah blah. So the architecture needs to look different. Been hitting my head against a wall - I'll be darned if I can figure out what it is. Personally, I could see two solutions. 1. p1.php would post to itself. Do data validation. After data validation upon error, include p1.php again with included error messages upon success, redirect to p3.php with congrats. 2. p1.php would post to p2. perform data validation. upon error, save data into session variable, redirect back to p1.php, display error messages inline upon success, redirect to p3.php, display congrats I personally like the second option. It is cleaner. Each page/script has a single purpose in life. It just makes better sense to my small little mind. -- Jim Lucas Some men are born to greatness, some achieve greatness, and some have greatness thrust upon them. Twelfth Night, Act II, Scene V by William Shakespeare -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using require instead of redirect architecture
1. p1.php would post to itself. Do data validation. After data validation upon error, include p1.php again with included error messages upon success, redirect to p3.php with congrats. Yeah, I could do this, but it uses a redirect, and like you said, it's gnarly. 2. p1.php would post to p2. perform data validation. upon error, save data into session variable, redirect back to p1.php, display error messages inline upon success, redirect to p3.php, display congrats I've already got this working, per thread of a couple days ago. But it uses a redirect. I personally like the second option. It is cleaner. Each page/script has a single purpose in life. It just makes better sense to my small little mind. I agree as well. But I'm trying to get away from multiple trips to the server for simple page calls, per some pundits on the list. :) So I'm trying to learn a different architecture, and I'm not getting it yet. -- RE, Chicago -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using require instead of redirect architecture
Robert Erbaron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 1. p1.php would post to itself. Do data validation. After data validation upon error, include p1.php again with included error messages upon success, redirect to p3.php with congrats. Yeah, I could do this, but it uses a redirect, and like you said, it's gnarly. 2. p1.php would post to p2. perform data validation. upon error, save data into session variable, redirect back to p1.php, display error messages inline upon success, redirect to p3.php, display congrats I've already got this working, per thread of a couple days ago. But it uses a redirect. I personally like the second option. It is cleaner. Each page/script has a single purpose in life. It just makes better sense to my small little mind. I agree as well. But I'm trying to get away from multiple trips to the server for simple page calls, per some pundits on the list. :) So I'm trying to learn a different architecture, and I'm not getting it yet. -- RE, Chicago Well, I would tend to agree with Jim, the second suggestion he had is the way I've seen this problem done the most. It works, it's simple and this way you have one less PHP file, just enter your data and congratulations. The load to the server shouldn't be any different if you did it the way you suggested. Oh, well just my opinion. - Dan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Using require instead of redirect architecture
On Dec 19, 2007 3:55 PM, Robert Erbaron [EMAIL PROTECTED] wrote:
1. p1.php would post to itself. Do data validation. After data
validation
upon error, include p1.php again with included error messages
upon success, redirect to p3.php with congrats.
Yeah, I could do this, but it uses a redirect, and like you said, it's
gnarly.
the post to itself is a good idea; and there is nothing wrong with having
another
script as the 'welcome' script or w/e. in order to avoid a redirect in this
case
you could simply have an include directive.
eg.
if($wasLoginSuccessul) {
include('welcome.php');
die;
}
not something i would do in a complex system, but in a simple system,
for-sure.
I agree as well. But I'm trying to get away from multiple trips to the
server for simple page calls, per some pundits on the list. :) So I'm
trying to learn a different architecture, and I'm not getting it yet.
one thing i think of to mention is that each php script does not have to be
one that
is accessible by an end user. you can have 'back-end' scripts that do all
sorts of
stuff. validation for example.. you might have a class, something roughly
like
?php
class DataValidator {
public static function isEmailAddress($potentialEmailAddress) {
// regex to determine if $potentialEmailAddress is valid
return $isEmailAddressValid;
}
public static function isUsernameAcceptable($potentialUsername) {
// etc..
return $isUsernameAcceptable;
}
}
?
clearly this is not a script a user will access through the browser. in
fact these are the
sort of scripts i usually stash away in /usr/share/php5/someProject
anyway, this is the best sort of generic advice i can give you on a solid
'architecture'. if
all your scripts are designed with the premise of being accessed directly
from a client
browser youll be building a house of cards.
-nathan
Re: [PHP] Using require instead of redirect architecture
On Wed, 2007-12-19 at 14:23 -0700, Dan wrote: Robert Erbaron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 1. p1.php would post to itself. Do data validation. After data validation upon error, include p1.php again with included error messages upon success, redirect to p3.php with congrats. Yeah, I could do this, but it uses a redirect, and like you said, it's gnarly. 2. p1.php would post to p2. perform data validation. upon error, save data into session variable, redirect back to p1.php, display error messages inline upon success, redirect to p3.php, display congrats I've already got this working, per thread of a couple days ago. But it uses a redirect. I personally like the second option. It is cleaner. Each page/script has a single purpose in life. It just makes better sense to my small little mind. I agree as well. But I'm trying to get away from multiple trips to the server for simple page calls, per some pundits on the list. :) So I'm trying to learn a different architecture, and I'm not getting it yet. -- RE, Chicago Well, I would tend to agree with Jim, the second suggestion he had is the way I've seen this problem done the most. It works, it's simple and this way you have one less PHP file, just enter your data and congratulations. The load to the server shouldn't be any different if you did it the way you suggested. Oh, well just my opinion. Sorry, but option one is superior YMMV :B Page posts to itself, everything is already there, all the values posted, the form description, associated validation etc. Then if successful you redirect to the next logical page. Mind you, I assign predefined validation routines, or custom handlers to the form before it is rendered so it all makes sense to be in one place. Custom validators are pulled in as needed from their own separate controller. I used the other technique many years ago and I found it to be a hassle. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
