Page 1 of 2
Implementing POSTBACK
Posted: Fri Aug 10, 2007 5:46 pm
by alex.barylski
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???
Posted: Sat Aug 11, 2007 7:18 am
by Ollie Saunders
What's POSTBACK?
Posted: Sun Aug 12, 2007 3:01 pm
by alex.barylski
Is that why I haven't received much reply?
It's an ASP term which I have always interpreted as meaning, POSTing values back to an original FORM when the submittion fails for whatever reason.
Posted: Sun Aug 12, 2007 3:07 pm
by superdezign
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...
Posted: Sun Aug 12, 2007 4:59 pm
by alex.barylski
Thats the basic idea of a postback, as I understand it. basically re-POSTing the data back to the same FORM, thus avoiding having to re-submit via an HTTP POST.
Posted: Sun Aug 12, 2007 5:13 pm
by Chris Corbyn
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.
Posted: Sun Aug 12, 2007 5:56 pm
by alex.barylski
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???
Posted: Sun Aug 12, 2007 6:03 pm
by Chris Corbyn
Why response? It's not response data, it's request data. To me, it should be in the request. I even set validation errors in the request itself.
Posted: Sun Aug 12, 2007 11:35 pm
by Christopher
d11wtq wrote:Why response? It's not response data, it's request data. To me, it should be in the request. I even set validation errors in the request itself.
Yes, I have an isPost() method in my HTTP request class to determine the method.
Posted: Sun Aug 12, 2007 11:47 pm
by alex.barylski
I don't have a request object in my framework. What is the purpose behind a request object? What kind of information does it contain?
Posted: Mon Aug 13, 2007 12:00 am
by RobertGonzalez
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:
Code: Select all
<?php
// Set these according to whatever style you code in
$formData = array();
$formData['first_name'] = '';
$formData['last_name'] = '';
?>
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).
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>
(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?
Posted: Mon Aug 13, 2007 12:01 am
by RobertGonzalez
Hockey wrote:I don't have a request object in my framework. What is the purpose behind a request object? What kind of information does it contain?
The request data, perhaps?
Posted: Mon Aug 13, 2007 10:26 am
by thinsoldier
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.
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; }
}
Posted: Mon Aug 13, 2007 12:26 pm
by alex.barylski
@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?
Posted: Mon Aug 13, 2007 12:30 pm
by John Cartwright
Zend Framework reference guide on
request objects might offer some insight