Implementing POSTBACK
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Implementing POSTBACK
How do you do it?
1) Check the $_POST variable
2) Set a value in a registry
Originally I had a member variable in my front controller. However after some consideration, I think it would actually make more sense inside the Response object - basically I set the member in the front whenever a POST was submitted.
What are you opinions/ideas???
1) Check the $_POST variable
2) Set a value in a registry
Originally I had a member variable in my front controller. However after some consideration, I think it would actually make more sense inside the Response object - basically I set the member in the front whenever a POST was submitted.
What are you opinions/ideas???
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
I use a form handler that creates the objects which are defined as having a 'sticky' value or not and it keeps the same values that were posted when the validator fails.
If you don't post to the same page that the form is on though, that's a different story. My form handler only works when the form handling and creation are done together. I think you can use sockets to send a POST request back, but I'm not exactly sure how. Something like "POST HTTP/1.0" or something...
If you don't post to the same page that the form is on though, that's a different story. My form handler only works when the form handling and creation are done together. I think you can use sockets to send a POST request back, but I'm not exactly sure how. Something like "POST HTTP/1.0" or something...
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I'm not sure I follow? Why not just let the browser keep hold of the POST data it sent (i.e. don't redirect) until validation passes? Usually I'll take form data, validate it in the controller, if validation fails, dump the form back out with the POST data pre-filled, then when it finally validates redirect elsewhere to avoid duplicated input.
Do you mean you don't display any fields which did validate and you only display ones that need re-completing? I'd never thought about that but yeah, I guess I'd use a registry or just swap the field out to hidden fields with the POST data in.
EDIT | Erm, I meant session.
Do you mean you don't display any fields which did validate and you only display ones that need re-completing? I'd never thought about that but yeah, I guess I'd use a registry or just swap the field out to hidden fields with the POST data in.
EDIT | Erm, I meant session.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
d11 that is basically the idea, yes.
How do you determine if the postback is require though?
For instance, I have my controller check the model (which in my setup handles the validation indirectly through the data access layer) and if the action failed (duplicate record, etc) I set a postback flag so when I re-display the FORM for user corrections (with highlited fields indicating errors) my view knows to use POST data instead of DB data.
I have tried:
1) Registry
2) Response
3) Front controller
To each house the variable and I have determined it makes most sense inside Response object, as the response is what dictates the environment your currently working under, right?
For instance (ie: Zend) you can override the Response for both CLI or HTTP environments. I have little work in GTK/CLI but I don't think a postback would be required as the fields are not refreshed and retain state naturally. Thus it made sense to keep a member variable inside response?
Mind you, I don't think I would use a model 2 front controller in a desktop application, so whether that makes sense or not, is debatable. Perhaps registry makes most sense, but currently I'm leaning towards Response - opinions???
How do you determine if the postback is require though?
For instance, I have my controller check the model (which in my setup handles the validation indirectly through the data access layer) and if the action failed (duplicate record, etc) I set a postback flag so when I re-display the FORM for user corrections (with highlited fields indicating errors) my view knows to use POST data instead of DB data.
I have tried:
1) Registry
2) Response
3) Front controller
To each house the variable and I have determined it makes most sense inside Response object, as the response is what dictates the environment your currently working under, right?
For instance (ie: Zend) you can override the Response for both CLI or HTTP environments. I have little work in GTK/CLI but I don't think a postback would be required as the fields are not refreshed and retain state naturally. Thus it made sense to keep a member variable inside response?
Mind you, I don't think I would use a model 2 front controller in a desktop application, so whether that makes sense or not, is debatable. Perhaps registry makes most sense, but currently I'm leaning towards Response - opinions???
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Depending on the nature of you form, you can do a few things. The first thing I'd suggest, however, is getting rid of the POSTBACK term when speaking PHP. There is no logical comparative functionality in PHP that measures up to the functionality of the .NET POSTBACK, so I suppose it is best to speak in PHP terms in this case (at least to me it makes sense, eh?).
Usually what I do is prepopulate my forms using a form data array. I initially set the default form data fields to empty values for their types. Something akin to:
Then after those values are set, I check to see if the form is posted. If the form is posted, I validate each entry assigning its value to its corresponding $formData array index. I also start of the page with a default $formPassed = false and only set that to true when the form validation passes. So if the form is posted and the values have been reassigned to originally empty formData array values, when the form loads (because $formPassed was never switched to true because of validation errors) the entered data stays the same as what was entered by the user so they can see what they entered and why it needs to change (with your own validation error notices to the user).
(Please take this code with a grain of salt. It is merely an example of one way to do this.)
This same concept can be applied to editing forms (as opposed to add forms like contacts, new users, etc) buy simple setting the default $formData array to the data that is being edited. This allows the user to attempt to screw things up as many times as they want without ever changing anything until everything they decided to change is allowed to be changed. Follow?
Usually what I do is prepopulate my forms using a form data array. I initially set the default form data fields to empty values for their types. Something akin to:
Code: Select all
<?php
// Set these according to whatever style you code in
$formData = array();
$formData['first_name'] = '';
$formData['last_name'] = '';
?>Code: Select all
<form method="post" action="<?php echo $this->formAction(); ?>">
<?php if ($this->hasError('first_name'])): ?>
<div class="error"><?php echo $this->getError('first_name']); ?></div>
<?php endif; ?>
<input type="text" name="first_name" value="<?php $this->escape($this->first_name); ?>" /><br />
<?php if ($this->hasError('last_name'])): ?>
<div class="error"><?php echo $this->getError('last_name']); ?></div>
<?php endif; ?>
<input type="text" name="last_name" value="<?php $this->escape($this->last_name); ?>" />
</form>This same concept can be applied to editing forms (as opposed to add forms like contacts, new users, etc) buy simple setting the default $formData array to the data that is being edited. This allows the user to attempt to screw things up as many times as they want without ever changing anything until everything they decided to change is allowed to be changed. Follow?
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
-
thinsoldier
- Forum Contributor
- Posts: 367
- Joined: Fri Jul 20, 2007 11:29 am
- Contact:
here's the basic way I do it.
2 functions. postReturn and dbData.
basically just 2 if/else statements wrapped in 2 functions.
<input type="text" name="color" value="<?=postReturn('color',dbData('color')?>" />
If $_POST['color'] is present, then echo its value
Else, do whatever the 2nd argument of postReturn does.
dbData() the function looks for a global var named $dbdata which contains all the data for the current form.
Then, just like postReturn() it checks for the existance of the color key and if it exists then it echoes it.
The 2nd argument of dbData would be the value you want returned if 'color' doesnt exist in the $dbdata.
So you could use it to return a string that you can use as the css class name of a div wrapping the form field then use that to style the div to indicate that there was an error related to that field.
2 functions. postReturn and dbData.
basically just 2 if/else statements wrapped in 2 functions.
<input type="text" name="color" value="<?=postReturn('color',dbData('color')?>" />
If $_POST['color'] is present, then echo its value
Else, do whatever the 2nd argument of postReturn does.
dbData() the function looks for a global var named $dbdata which contains all the data for the current form.
Then, just like postReturn() it checks for the existance of the color key and if it exists then it echoes it.
The 2nd argument of dbData would be the value you want returned if 'color' doesnt exist in the $dbdata.
So you could use it to return a string that you can use as the css class name of a div wrapping the form field then use that to style the div to indicate that there was an error related to that field.
Code: Select all
function POST_return($post_variable, $if_false='', $if_true='')
{ //Generally better than previous POST_echo & POST_echo_text combined
$var=$post_variable;
if(isset($_POST["$var"]))
{ $to_return = $_POST["$var"]; } // if found, give back it's value
else { $to_return = $if_false; } // if NOT found, give the alternative
if(isset($_POST["$var"]) && $if_true != '')
{$to_return = $if_true; } // if found, give the thing I want given instead of found value
return $to_return;
}Code: Select all
// -------------------------------------//
function dbdata($subject,$if_false='')
{
global $dbdata; // whatever is the name of your result resource variable containgin all your database values
if(isset($dbdata[$subject])) {
return stripslashes($dbdata[$subject]);
} ////echo $dbdata[$subject];
else {return $if_false; }
}-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
@Everah: Thanks for the detailed reply.
POSTBACK is not a feature exclusive to ASP.NET, PRADO implements a POSTBACK mechanism as well. Really, it just avoids having to re-POST data when a FORM doesn't validate, how you implement doesn't really matter IMHO. It's just a technique, similar to a design a design pattern. For that reason I figured I would follow M$ lead and use the term "postback" instead of explaining what a postback was in my own terms or definition.
I am now more curious as to what kind of information or purpose a REQUEST object holds. Until now I haven't been able to justify adding an object called request, to simply wrap super globals such as GPC. Perhaps with a postback flag/member it would make sense.
Any examples or detailed reasons for using REQUEST?
POSTBACK is not a feature exclusive to ASP.NET, PRADO implements a POSTBACK mechanism as well. Really, it just avoids having to re-POST data when a FORM doesn't validate, how you implement doesn't really matter IMHO. It's just a technique, similar to a design a design pattern. For that reason I figured I would follow M$ lead and use the term "postback" instead of explaining what a postback was in my own terms or definition.
I am now more curious as to what kind of information or purpose a REQUEST object holds. Until now I haven't been able to justify adding an object called request, to simply wrap super globals such as GPC. Perhaps with a postback flag/member it would make sense.
Any examples or detailed reasons for using REQUEST?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Zend Framework reference guide on request objects might offer some insight