I'm looking at the source of a web sockets server and I see these various forms:
ws://{$host}{$path}
HTTP/1.1 ${status}\r\n
Are these simply equivalent to:
ws:// . $host . $path
HTTP/1.1 . $status . \r\n;
and if so, is there any particular benefit to using that form? Or if not, what
On 16 November 2011 13:56, Tim Streater t...@clothears.org.uk wrote:
I'm looking at the source of a web sockets server and I see these various
forms:
ws://{$host}{$path}
HTTP/1.1 ${status}\r\n
Are these simply equivalent to:
ws:// . $host . $path
HTTP/1.1 . $status . \r\n;
and if
On 16 Nov 2011 at 14:27, Richard Quadling rquadl...@gmail.com wrote:
If you want to embed $array[CONSTANT], then the {} is used.
I use {} out of habit for non arrays. Not sure if there is an impact.
http://docs.php.net/manual/en/language.types.string.php#example-71
shows the use.
Oh.
On 11-11-16 09:27 AM, Richard Quadling wrote:
On 16 November 2011 13:56, Tim Streatert...@clothears.org.uk wrote:
I'm looking at the source of a web sockets server and I see these various forms:
ws://{$host}{$path}
HTTP/1.1 ${status}\r\n
Are these simply equivalent to:
ws:// . $host .
On Oct 5, 2009, at 7:42 PM, Manuel Lemos wrote:
Hello,
on 10/05/2009 03:02 PM Philip Thompson said the following:
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or
not...
I use name=submit for the submit
At 7:25 PM +0100 10/4/09, MEM wrote:
Unfortunately, I'm really REALLY on a rush.
I saw a bumper sticker the other day which read:
Humpty Dumpty was rushed
Cheers,
tedd
--
---
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List
On Oct 2, 2009, at 3:00 AM, Manuel Lemos wrote:
Hello,
on 10/02/2009 04:41 AM kranthi said the following:
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or not...
I use name=submit for the submit button instead,
Hello,
on 10/05/2009 03:02 PM Philip Thompson said the following:
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or not...
I use name=submit for the submit button instead, that will pass the
value of the submit
Thanks a lot. To all.
For the moment, I'm with the redirect solution that others have pointed.
But after seen tedd example and watch Manuel videos, I'm starting to
understand how the hidden field solution work as well. Well... I'm
*starting* to understand I've not fully understand it yet,
On 10/4/09 9:25 AM, MEM tal...@gmail.com wrote:
Thanks a lot. To all.
For the moment, I'm with the redirect solution that others have pointed.
But after seen tedd example and watch Manuel videos, I'm starting to
understand how the hidden field solution work as well. Well... I'm
*starting*
i don't think so. if the user requests the page a_form.php then the
server
will normally execute the a_form.php script regardless whether the form
was
submitted or not.
to display a blank form, the user probably requests a_form.php with the
GET
method and probably without any GET
At 3:39 PM +0100 10/4/09, MEM wrote:
i don't think so. if the user requests the page a_form.php then the
server
will normally execute the a_form.php script regardless whether the form
was
submitted or not.
to display a blank form, the user probably requests a_form.php with the
GET
On 10/4/09 10:39 AM, MEM tal...@gmail.com wrote:
i don't think so. if the user requests the page a_form.php then the
server
will normally execute the a_form.php script regardless whether the form
was
submitted or not.
to display a blank form, the user probably requests a_form.php with the
On 10/4/09 10:55 AM, tedd tedd.sperl...@gmail.com wrote:
At 3:39 PM +0100 10/4/09, MEM wrote:
i don't think so. if the user requests the page a_form.php then the
server
will normally execute the a_form.php script regardless whether the form
was
submitted or not.
to display a blank
i agree that it does seem a bit as though Márcio is in such a hurry to
make
something work that the tasks of learning and understanding the
fundamentals
are being left aside. while that's maybe understandable, it's a bit
frustrating when we're trying to explain the fundamentals.
Thanks a
On 10/2/09 10:24 AM, tedd tedd.sperl...@gmail.com wrote:
At 1:55 PM +0530 10/2/09, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
That depends upon how sloppy you are in coding.
NONE of
At 7:11 PM +0100 10/2/09, MEM wrote:
I don't want to take another path. The hidden fields seems the way to go.
However, you gave me the example above, and I'm not understanding how can I
pass from your example: A multi-step form.
To what I was looking form: 1 step form with a success page that
At 9:42 AM -0400 10/3/09, Tom Worster wrote:
On 10/2/09 10:24 AM, tedd tedd.sperl...@gmail.com wrote:
At 1:55 PM +0530 10/2/09, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
That
On 10/2/09 10:06 AM, MEM tal...@gmail.com wrote:
I'm now understanding that even if the form is submitted to self, we can
still use a redirect to a success_message_page.php. However, we must do
this redirect, AFTER the form has submitted to himself. It's the only thing
that we have to pay
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or not...
I use name=submit for the submit button instead, that will pass the
value of the submit button to the action script.
above all i use a template engine, smarty
Hello,
on 10/02/2009 04:41 AM kranthi said the following:
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or not...
I use name=submit for the submit button instead, that will pass the
value of the submit button
That only works if the user clicks on that submit button. If the user
hits the enter key in a text input, the form is submitted but the submit
input variable is not set. That is why an hidden input is a safer solution.
i doubt that, because i use the above mentioned method in nearly all
of my
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 2009-10-02 at 13:55 +0530, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
You say you don't use hidden fields because they can be modified too
easily, yet you say you check for the
You say you don't use hidden fields because they can be modified too
easily, yet you say you check for the submit button? Which out of the
two do you do, as last time I checked, modifying one form field is as
easy as changing any other!
I completely agree with you. changing submit text is as
McConnell
Subject: Re: [PHP] Self-Process php forms or not?
You say you don't use hidden fields because they can be modified too
easily, yet you say you check for the submit button? Which out of
the
two do you do, as last time I checked, modifying one form field is
as
easy as changing any
At 1:55 PM +0530 10/2/09, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
That depends upon how sloppy you are in coding.
NONE of my hidden variables pose any security problems whatsoever.
At 3:06 PM +0100 10/2/09, MEM wrote:
I want to apologize to you all. I have mentioned two things on the same
basket, but it was not appropriate. Since a confirmation page is not the
same thing as a success page.
Let's forget about the confirmation page, since it's not required.
I'm now
You can set it up any number of ways. There is no
absolute need for a redirect. Everything can be
done in one form, or not -- your choice.
Cheers,
tedd
Yes. But since I don't want to display a success information + form fields,
but only the success information,
I believe the only way we
At 3:35 PM +0100 10/2/09, MEM wrote:
You can set it up any number of ways. There is no
absolute need for a redirect. Everything can be
done in one form, or not -- your choice.
Cheers,
tedd
Yes. But since I don't want to display a success information + form fields,
but only the success
Yes. But since I don't want to display a success information + form fields,
but only the success information,
I believe the only way we have to do this is by either use javascript and
update a div or similar, or using only php, by redirecting to another page.
Is this correct?
Whether or not
Hello,
on 10/02/2009 05:23 AM kranthi said the following:
That only works if the user clicks on that submit button. If the user
hits the enter key in a text input, the form is submitted but the submit
input variable is not set. That is why an hidden input is a safer solution.
i doubt that,
Hello,
on 10/02/2009 07:11 AM kranthi said the following:
You say you don't use hidden fields because they can be modified too
easily, yet you say you check for the submit button? Which out of the
two do you do, as last time I checked, modifying one form field is as
easy as changing any
this please?
Ps- I've googled: php redirect success page on self submit form and
similar...
Regards,
Márcio
-Original Message-
From: Bob McConnell [mailto:r...@cbord.com]
Sent: sexta-feira, 24 de Abril de 2009 14:10
To: PHP-General List
Subject: RE: [PHP] Self-Process php forms
May be it is best time to for you to start using Zend Framework - Zend_Form
-Original Message-
From: MEM [mailto:tal...@gmail.com]
Sent: Thursday, October 01, 2009 3:01 PM
To: 'Bob McConnell'; 'PHP-General List'
Subject: RE: [PHP] Self-Process php forms or not?
One last question about
On 10/1/09 8:00 AM, MEM tal...@gmail.com wrote:
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form with a
success page or a confirmation page that doesn't show
2009 13:01
To: 'Bob McConnell'; 'PHP-General List'
Subject: RE: [PHP] Self-Process php forms or not?
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form with a
success page
Original Message
From: Mert Oztekin mozte...@anadolusigorta.com.tr
To: MEM tal...@gmail.com; Bob McConnell r...@cbord.com; PHP-General List
php-general@lists.php.net
Sent: Thursday, October 1, 2009 5:16:40 AM
Subject: RE: [PHP] Self-Process php forms or not?
May be it is best
At 1:00 PM +0100 10/1/09, MEM wrote:
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form with a
success page or a confirmation page that doesn't show the form?
Can
On Thu, 2009-10-01 at 09:30 -0400, Tom Worster wrote:
On 10/1/09 8:00 AM, MEM tal...@gmail.com wrote:
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form
On 10/1/09 10:13 AM, tedd tedd.sperl...@gmail.com wrote:
At 1:00 PM +0100 10/1/09, MEM wrote:
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form with a
success
-Process php forms or not?
On 10/1/09 10:13 AM, tedd tedd.sperl...@gmail.com wrote:
At 1:00 PM +0100 10/1/09, MEM wrote:
One last question about this:
I've done a self submit form, after hearing all the advantages
expressed
here.
But how could we relate, without using javascript
Hello,
on 10/01/2009 09:00 AM MEM said the following:
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form with a
success page or a confirmation page that doesn't
Andrew Ballard wrote:
On Wed, Jun 3, 2009 at 7:13 PM, PJ af.gour...@videotron.ca wrote:
Tom Chubb wrote:
2009/6/3 PJ af.gour...@videotron.ca:
The code:
...snip
div id=loginbox
    form name=login method=post action=? echo
$_SERVER['PHP_SELF'] ?
     Â
Shawn McKenzie wrote:
PJ wrote:
AngeloZanetti wrote:
Shawn McKenzie wrote:
PJ wrote:
PROBLEM 1 solved: errant divs removed; strange that they were
inhibiting entry of data into form field?
PROBLEM 2 not resolved: but the form was off the page and
clipped in
The code:
...snip
div id=loginbox
form name=login method=post action=? echo
$_SERVER['PHP_SELF'] ?
h2accegrave;s client br /input type=text
name=title value=? echo $user; ? size=10 /br /
mot de passe br /input type=text name=title value=?
echo $passwd; ? size=10 /br
On Wed, Jun 3, 2009 at 11:55 AM, PJ af.gour...@videotron.ca wrote:
The code:
...snip
div id=loginbox
form name=login method=post action=? echo
$_SERVER['PHP_SELF'] ?
h2accegrave;s client br /input type=text
name=title value=? echo $user; ? size=10 /br /
mot de
PROBLEM 1 solved: errant divs removed; strange that they were
inhibiting entry of data into form field?
PROBLEM 2 not resolved: but the form was off the page and clipped in
upper right hand corner. What can be done to get it to show correctly?
--
Hervé Kempf: Pour sauver la planète, sortez du
2009/6/3 PJ af.gour...@videotron.ca:
The code:
...snip
div id=loginbox
form name=login method=post action=? echo
$_SERVER['PHP_SELF'] ?
h2accegrave;s client br /input type=text
name=title value=? echo $user; ? size=10 /br /
mot de passe br /input type=text
Tom Chubb wrote:
2009/6/3 PJ af.gour...@videotron.ca:
The code:
...snip
div id=loginbox
form name=login method=post action=? echo
$_SERVER['PHP_SELF'] ?
h2accegrave;s client br /input type=text
name=title value=? echo $user; ? size=10 /br /
mot de passe br
AngeloZanetti wrote:
Shawn McKenzie wrote:
PJ wrote:
PROBLEM 1 solved: errant divs removed; strange that they were
inhibiting entry of data into form field?
PROBLEM 2 not resolved: but the form was off the page and clipped in
upper right hand corner. What can be done to get it to
PJ wrote:
AngeloZanetti wrote:
Shawn McKenzie wrote:
PJ wrote:
PROBLEM 1 solved: errant divs removed; strange that they were
inhibiting entry of data into form field?
PROBLEM 2 not resolved: but the form was off the page and
clipped in upper right hand corner. What can be done to get
On Wed, Jun 3, 2009 at 7:13 PM, PJ af.gour...@videotron.ca wrote:
Tom Chubb wrote:
2009/6/3 PJ af.gour...@videotron.ca:
The code:
...snip
div id=loginbox
form name=login method=post action=? echo
$_SERVER['PHP_SELF'] ?
h2accegrave;s client br /input type=text
name=title
to include browser side (Javascript) validation.
I mean, I am not masochist to create something that will give me more
work in the end to develop PHP forms based applications than if I would
type HTML manually.
Furthermore, the plug-ins that come with the package dramatically reduce
the amount of code
-Original Message-
From: Manuel Lemos [mailto:mle...@acm.org]
Sent: 22 May 2009 09:56
To: Paul M Foster
Cc: php-general@lists.php.net; Angelo Zanetti
Subject: Re: [PHP] Forms validation and creation- easier solution?
Hello,
on 05/20/2009 11:09 AM Paul M Foster said the following
.
IMHO, creating forms by hand is by no means simpler, especially if you
want to include browser side (Javascript) validation.
I mean, I am not masochist to create something that will give me more
work in the end to develop PHP forms based applications than if I would
type HTML manually
Viva,
on 05/22/2009 10:36 AM Paul M Foster said the following:
IMHO, creating forms by hand is by no means simpler, especially if you
want to include browser side (Javascript) validation.
I mean, I am not masochist to create something that will give me more
work in the end to develop PHP
On May 20, 2009, at 2:03 AM, Angelo Zanetti wrote:
We have done quite a few projects and we are looking to find better
ways to
implementing forms.
This is fairly simple to roll-your-own.
I do it from metadata. I check MySQL metadata for data types,
lengths, and defaults. In addition, my
Hi all.
We have done quite a few projects and we are looking to find better ways to
implementing forms.
Forms seem to be quite time consuming and repetitive.
Generally are there any classes or libraries that will assist with:
1. Easy creation of forms (fields and layout)
2.
Hi!
Zend framework has a wonderful solution to solve this task. You can download
even the demo showing how to do this task
Best regards,
Alex.
2009/5/20 Angelo Zanetti ang...@zlogic.co.za
Hi all.
We have done quite a few projects and we are looking to find better ways to
implementing
_
From: Olexandr Heneralov [mailto:ohenera...@gmail.com]
Sent: 20 May 2009 09:08
To: Angelo Zanetti
Cc: php-general@lists.php.net
Subject: Re: [PHP] Forms validation and creation- easier solution?
Hi!
Zend framework has a wonderful solution to solve this task. You can download
:* 20 May 2009 09:08
*To:* Angelo Zanetti
*Cc:* php-general@lists.php.net
*Subject:* Re: [PHP] Forms validation and creation- easier solution?
Hi!
Zend framework has a wonderful solution to solve this task. You can
download even the demo showing how to do this task
Best regards,
Alex
[snip]
1. Easy creation of forms (fields and layout)
[/snip]
I posted a form function several months ago that will help you with
this. Just search the list archives
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, May 20, 2009 at 10:08:12AM +0300, Olexandr Heneralov wrote:
2009/5/20 Angelo Zanetti ang...@zlogic.co.za
Hi all.
We have done quite a few projects and we are looking to find better ways to
implementing forms.
Forms seem to be quite time consuming and repetitive.
-Original Message-
From: Paul M Foster [mailto:pa...@quillandmouse.com]
Sent: 20 May 2009 16:09
To: php-general@lists.php.net
Subject: Re: [PHP] Forms validation and creation- easier solution?
On Wed, May 20, 2009 at 10:08:12AM +0300, Olexandr Heneralov wrote:
2009/5/20 Angelo
On Wed, May 20, 2009 at 05:10:57PM +0200, Angelo Zanetti wrote:
-Original Message-
From: Paul M Foster [mailto:pa...@quillandmouse.com]
Sent: 20 May 2009 16:09
To: php-general@lists.php.net
Subject: Re: [PHP] Forms validation and creation- easier solution?
On Wed, May 20, 2009
Troy Oltmanns wrote:
I have the code below being used to rifle through a list of available
categories and create select options for them. The code is being used to
query the database and compare the product category to the current
iteration, if there's a match, then add selected code so the
On Thu, 2009-04-30 at 11:06 +0200, Marcus Gnaß wrote:
Troy Oltmanns wrote:
I have the code below being used to rifle through a list of available
categories and create select options for them. The code is being used to
query the database and compare the product category to the current
I have the code below being used to rifle through a list of available
categories and create select options for them. The code is being used to
query the database and compare the product category to the current
iteration, if there's a match, then add selected code so the category is
prechosen. More
Im trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the action of
the form to another .php page.
Can anyone point me some resources about this. Why using one instead of
another. What are the main advantages?
...@gmail.com
To: 'PHP-General List' php-general@lists.php.net
Sent: Friday, April 24, 2009 2:34 PM
Subject: [PHP] Self-Process php forms or not?
I'm trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the action of
the form
, 24 de Abril de 2009 13:53
To: 'PHP-General List'
Subject: Re: [PHP] Self-Process php forms or not?
I think the main advantage is that if something goes wrong processing
the
datas, you can show the form again without redirecting again.
And if you have to change the behavior of the page, you
: MEM tal...@gmail.com
To: 'PHP-General List' php-general@lists.php.net
Sent: Friday, April 24, 2009 2:34 PM
Subject: [PHP] Self-Process php forms or not?
I'm trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the action
[snip] What about the moto: let's separate business from presentation?[/snip]
This depends on how strictly you're following any given model like MVC. IMHO
you should use the right tool for the job.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
, 2009 3:03 PM
Subject: RE: [PHP] Self-Process php forms or not?
So, on your opinion, we can call that method, on some circumstances, a good
practice?
What about the moto: let's separate business from presentation?
Thanks once again,
Márcio
-Original Message-
From: Sándor Tamás
presentation?
Thanks once again,
Márcio
-Original Message-
From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu]
Sent: sexta-feira, 24 de Abril de 2009 13:53
To: 'PHP-General List'
Subject: Re: [PHP] Self-Process php forms or not?
I think the main advantage
What you are describing is known as a self executing script where the
script posts back to itself. In other words it has two passes - the first
uses the GET method to build the screen for the user, which may or may not
be empty, while the second uses the POST method to send the user's changes
To: php-general@lists.php.net
Subject: Re: [PHP] Self-Process php forms or not?
Having a script that is self executing - when it posts back to itself
instead of a separate script - has absolutely nothing to do with the
separation of business and presentation. It is possible for a single
Hello,
on 04/24/2009 09:34 AM MEM said the following:
I’m trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the action of
the form to another .php page.
Can anyone point me some resources about this. Why using one
I am fairly new to the php/mySQL combo and just noticed an unusual behavior
and don't know where to find the answer to fix this. It is probably common
knowledge, but not to a newbie.
If I fill in the fields of a form and hit the enter key to submit the
form, no variables seem to be passed
Mark Pashia schreef:
I am fairly new to the php/mySQL combo and just noticed an unusual behavior
and don't know where to find the answer to fix this. It is probably common
knowledge, but not to a newbie.
If I fill in the fields of a form and hit the enter key to submit the
form, no
On Jan 24, 2008 3:34 AM, Mark Pashia [EMAIL PROTECTED] wrote:
If I fill in the fields of a form and hit the enter key to submit the
form, no variables seem to be passed along. If I use the submit button,
everything works perfectly. It seems that other forms on the web work with
the enter key
Some older browsers didn't send along the button name/value when you
hit enter, for a one-button form...
But I've never heard of one that failed to send anything at all...
It's almost for sure a browser issue though -- PHP doesn't really *do*
anything with the data it gets.
It just stuffs it
Why isnt this cleaning my form $_POST's
class forms {
var $UserInputClean;
// Forms to variables
function forms() {
if (count($_POST) 0) {
foreach($_POST as $curPostKey = $curPostVal) {
On Mon, 2008-01-21 at 23:15 -0500, nihilism machine wrote:
Why isnt this cleaning my form $_POST's
class forms {
var $UserInputClean;
// Forms to variables
function forms() {
if (count($_POST) 0) {
foreach($_POST as
: bestplace.biz | Web: seo-diy.com
-Original Message-
From: Jeffrey [mailto:[EMAIL PROTECTED]
Sent: Friday, November 23, 2007 4:12 AM
To: php-general@lists.php.net
Subject: [PHP] Page not displayed/Forbidden on PHP forms
We are running identical web applications with two different
We are running identical web applications with two different hosts. Both
are LAMP.
With one of hosts, we are having reports of users seeing Page not
displayed or 403 Forbidden after submitting forms. These forms are
always sending data to the same page from which they started and the
problem
On Thu, June 7, 2007 9:03 pm, Dylan Bouterse wrote:
My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
Our PHP programmer has developed quite a few PHP email forms and each
time an email is sent, the FROM: address is
[EMAIL PROTECTED] I don't know if this is a PHP
My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
Our PHP programmer has developed quite a few PHP email forms and each
time an email is sent, the FROM: address is
[EMAIL PROTECTED] I don't know if this is a PHP
problem or apache problem (or even a sendmail problem for
My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
Our PHP programmer has developed quite a few PHP email forms and each
time an email is sent, the FROM: address is
[EMAIL PROTECTED] I don't know if this is a PHP
problem or apache problem (or even a sendmail problem for that
On Thu, 2007-06-07 at 22:03 -0400, Dylan Bouterse wrote:
My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
Our PHP programmer has developed quite a few PHP email forms and each
time an email is sent, the FROM: address is
[EMAIL PROTECTED] I don't know if this is a PHP
Hi,
How do I stop contents of a form from being readded to the database if the
user hits the refresh button on their browser.
I have tried to unset/destroy the variables in several different ways, but
it still does it.
After the info is written I unset the variables by using unset($var1,
It doesn't help to reset any values. The form data is being resent by
the browser itself, just if the user presses the submit button again
with the same data.
What you could do is mabye use a session to see if the particular user
has sent form data before.
/Fredrik Thunberg
Beauford skrev:
El Fri, 12 Jan 2007 03:27:12 -0500
Beauford [EMAIL PROTECTED] escribió:
Hi,
How do I stop contents of a form from being readded to the database
if the user hits the refresh button on their browser.
I have tried to unset/destroy the variables in several different
ways, but it still does
Beauford wrote:
Hi,
How do I stop contents of a form from being readded to the database if the
user hits the refresh button on their browser.
Perhaps a session variable that is set once the form is submitted.
Depending on the data you could also look at having a primary key in the
database.
. It will be this address, not the
post that made the database update, that the browser will remember.
Satyam
- Original Message -
From: Beauford [EMAIL PROTECTED]
To: PHP php-general@lists.php.net
Sent: Friday, January 12, 2007 9:27 AM
Subject: [PHP] Forms and destroying values
Hi
confused as to why giving them a null value doesn't work.
Thanks to all.
-Original Message-
From: Satyam [mailto:[EMAIL PROTECTED]
Sent: January 12, 2007 8:21 AM
To: Beauford; PHP
Subject: Re: [PHP] Forms and destroying values
This issue comes over and over again. The trick
again.
Hope that makes it clearer.
-Stut
-Original Message-
From: Satyam [mailto:[EMAIL PROTECTED]
Sent: January 12, 2007 8:21 AM
To: Beauford; PHP
Subject: Re: [PHP] Forms and destroying values
This issue comes over and over again. The trick, as I
learned from this list, is to send
On Fri, 2007-01-12 at 11:23 -0500, Beauford wrote:
So the answer is, there is no way to destroy the values. Question then, what
is unset() used for as it doesn't seem to do anything? With a language as
good as PHP I though there would be some way to do this. I have got a
workaround, but
Subject: Re: [PHP] Forms and destroying values
This issue comes over and over again. The trick, as I
learned from this list, is to send a redirect to the browser
to a confirmation page, so the browser remembers the page
redirected to and completely ignores the page that made
1 - 100 of 368 matches
Mail list logo
