Re: [PHP] {} forms

[Robert Cummings]

On 11-11-16 09:27 AM, Richard Quadling wrote:

On 16 November 2011 13:56, Tim Streater  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 so, is there any particular benefit to using that form? Or if not, what 
do they mean?

(I've read up about variable variables).



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.



The braces are also used when the characters following the variable are 
also valid variable name characters :)


Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: [PHP] {} forms

[Tim Streater]

On 16 Nov 2011 at 14:27, Richard Quadling  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. I've fixed the layout bug for
> http://docs.php.net/manual/en/language.types.string.php#example-70.

Ah *that's* where it was hiding. Thanks - got it now.

--
Cheers  --  Tim

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] {} forms

[Richard Quadling]

On 16 November 2011 13:56, Tim Streater  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 so, is there any particular benefit to using that form? Or if not, 
> what do they mean?
>
> (I've read up about variable variables).
>
> Thanks,
>
> --
> Cheers  --  Tim
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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. I've fixed the layout bug for
http://docs.php.net/manual/en/language.types.string.php#example-70.

-- 
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] {} forms

[Tim Streater]

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 
do they mean?

(I've read up about variable variables).

Thanks,

--
Cheers  --  Tim

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Philip Thompson]

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 button instead, that will pass  
the

value of the submit button to the action script.

above all i use a template engine, smarty to take care of the
presentation for me(like deciding whether to show the form and/or a
success/failure message)


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.


If you need the button to be *clicked*...



Or something along those lines.


That does not make much sense and is pointless. First that syntax you
mentioned probably requires JQuery or some other large Javascript
library. something like this['submitButton'].click() would emulate the
click event. Second, by the time that onsubmit is called, the event  
that

triggered it was already dispatched. Emulating the click on a button
would probably fire the form submission and onsubmit code would be run
again, leading to an infinite loop sucking machine CPU.


It makes perfect sense and is not pointless. Yes, it is library- 
specific javascript. However, it was used to show an example and make  
a point. I assume that most the subscribers here are able to decipher  
the code and determine what the intent was. And no, this will not  
cause an infinite loop. The onsubmit is called first and will process  
whatever action you specify, and then move on. *If* the submit button  
wasn't *clicked* and you needed it to be, then this would emulate that  
functionality. I'm not saying this is the best solution on how to deal  
with the previous question but it is *a* solution.


Here's some code that you can see there's no infinite loop and shows  
which events are called first.


--



loop? i don't think so


Times submitted: 

name="theForm" onsubmit="document.getElementById('submitBtn').click();  
return false;">


>




document.theForm.text.focus();


--

The above code works as expected in Safari 4.0.3, FF3.5.3 and IE8.

Cheers,
~Philip

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Manuel Lemos]

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 button to the action script.
>>>
>>> above all i use a template engine, smarty to take care of the
>>> presentation for me(like deciding whether to show the form and/or a
>>> success/failure message)
>>
>> 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.
> 
> If you need the button to be *clicked*...
> 
> 
> 
> Or something along those lines.

That does not make much sense and is pointless. First that syntax you
mentioned probably requires JQuery or some other large Javascript
library. something like this['submitButton'].click() would emulate the
click event. Second, by the time that onsubmit is called, the event that
 triggered it was already dispatched. Emulating the click on a button
would probably fire the form submission and onsubmit code would be run
again, leading to an infinite loop sucking machine CPU.


-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Philip Thompson]

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, that will pass the
value of the submit button to the action script.

above all i use a template engine, smarty to take care of the
presentation for me(like deciding whether to show the form and/or a
success/failure message)


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.


If you need the button to be *clicked*...



Or something along those lines.

~Philip

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[tedd]

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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

> 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 lot.

Tedd, Tom,
I perfectly understand. I can only apologize. 
Unfortunately, I'm really REALLY on a rush. 
But as an additional information, I'm marking all this e-mails for latter
reference and study. 

>as i said before, a script will execute regardless. but this new script
fragment does nothing except initialize >$erros if $_POST['submit'] is not
set (e.g. if the user requests the page without POSTing the form). i don't
see a >problem. this script also has the three cases i described clearly
separated.
>now, what was your question?

None. I've not properly see the structure that I was in, and according to
that mistake, I've taking wrong conclusions.

But thanks for pointing it out.



Regards and, once again, thanks for your feedback, and I'm really sorry for
not been able to properly learn with your advices. :s
Márcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/4/09 10:55 AM, "tedd"  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 form, the user probably requests a_form.php with the
>>>  GET
>>>  method and probably without any GET parameters. the script will run but
>>>  $_POST['submit'] is not set. so the script you show above will echo
>>>  "Sorry,
>>>  couldn't process the form". that will likely confuse the user.
>>> 
>> 
>> 
>> Ok... but please have a look here, I've uploaded and tested that code, and I
>> can assure you that the message doesn't appear when the form first load:
>> 
>> http://pastebin.com/m21078fe3
>> Note: if you use: "copy to clipboard" option the numbers will gone.
>> 
>> 
>> 
>> Regards,
>> Márcio
> 
> The problem, as I see it, is that you are not
> willing to write a simple example and get that to
> work. Instead, you complicate things beyond your
> ability to understand.
> 
> My advice, step back -- write a simple example
> that does what you want and then expand it.

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.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/4/09 10:39 AM, "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
>> method and probably without any GET parameters. the script will run but
>> $_POST['submit'] is not set. so the script you show above will echo
>> "Sorry,
>> couldn't process the form". that will likely confuse the user.
>> 
> 
> 
> Ok... but please have a look here, I've uploaded and tested that code, and I
> can assure you that the message doesn't appear when the form first load:
> 
> http://pastebin.com/m21078fe3
> Note: if you use: "copy to clipboard" option the numbers will gone.

this has a different structure from what you showed us in your email earlier
today (Sunday, October 4, 2009 9:25 AM). this script has the structure:



as i said before, a script will execute regardless. but this new script
fragment does nothing except initialize $erros if $_POST['submit'] is not
set (e.g. if the user requests the page without POSTing the form). i don't
see a problem. this script also has the three cases i described clearly
separated.

now, what was your question?



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[tedd]

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
 method and probably without any GET parameters. the script will run but
 $_POST['submit'] is not set. so the script you show above will echo
 "Sorry,
 couldn't process the form". that will likely confuse the user.




Ok... but please have a look here, I've uploaded and tested that code, and I
can assure you that the message doesn't appear when the form first load:

http://pastebin.com/m21078fe3
Note: if you use: "copy to clipboard" option the numbers will gone.



Regards,
Márcio


The problem, as I see it, is that you are not 
willing to write a simple example and get that to 
work. Instead, you complicate things beyond your 
ability to understand.


My advice, step back -- write a simple example 
that does what you want and then expand it.


Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

> 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 parameters. the script will run but
> $_POST['submit'] is not set. so the script you show above will echo
> "Sorry,
> couldn't process the form". that will likely confuse the user.
> 


Ok... but please have a look here, I've uploaded and tested that code, and I
can assure you that the message doesn't appear when the form first load:

http://pastebin.com/m21078fe3
Note: if you use: "copy to clipboard" option the numbers will gone.



Regards,
Márcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/4/09 9:25 AM, "MEM"  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* to understand I've not fully understand it yet, despite all your
> great examples. 
> 
> Because the structure of the code with hidden fields, seems quite different
> from the structure I have right now and I'm unable to make the switch.
> 
> Here is the actual structure:
> 
> if (isset($_POST['submit']))
> {
> 
>   //declare variables
>   $var = $_POST['var']; etc...
> 
>   //validate
> 
>   //process the form
>   (send e-mail or save to database etc...)
> 
>   //redirect to success page.
> } 
> else 
> {
> Echo "Sorry, couldn't process the form";
> }
> 
> 
> 
> I suppose that the echo message telling "we couldn't process the form" does
> not appear when the form first loads, because the server side script is not
> requested on load, it is requested when the form submits to the php code
> presented on that same page (self). Tom Worster, is this precise?

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 parameters. the script will run but
$_POST['submit'] is not set. so the script you show above will echo "Sorry,
couldn't process the form". that will likely confuse the user.

in your structure you branch only two ways. i think you need three ways:

1 - the user simply arrived at the form. there is no POST data. the form was
not submitted.

2 - there is POST data. the form was submitted.

  2a - the POST data is unacceptable.

  2b - the POST data is good.


in branches 1 and 2a you send the form.

in 2b, you send some other page or a redirect.

in 1 you send the form blank.

in 2a you might fill some form elements with data from POST and add some
annotations to the form so the user knows what she or he did wrong.

> In the future, I will print tedd example, and Manuel scheme, and try to
> change the code above to accommodate hidden fields, because I still prefer
> having only one file.

one can learn a lot reading other people's code. 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

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, despite all your
great examples. 

Because the structure of the code with hidden fields, seems quite different
from the structure I have right now and I'm unable to make the switch. 

Here is the actual structure:

if (isset($_POST['submit']))
{

  //declare variables
  $var = $_POST['var']; etc...

  //validate

  //process the form 
  (send e-mail or save to database etc...)

  //redirect to success page.
} 
else 
{
Echo "Sorry, couldn't process the form";
}



I suppose that the echo message telling "we couldn't process the form" does
not appear when the form first loads, because the server side script is not
requested on load, it is requested when the form submits to the php code
presented on that same page (self). Tom Worster, is this precise?


In the future, I will print tedd example, and Manuel scheme, and try to
change the code above to accommodate hidden fields, because I still prefer
having only one file.


Thank you all once again,
Márcio








--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/2/09 10:06 AM, "MEM"  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 attention here, correct?
> 
> Since we are not dealing with a confirmation page, or a multi-step form, the
> hidden field isn't necessary.
> 
> It's this correct assumptions?

the server script that runs in response to an http request for uri X can
determine if "conditions of success" are met only after the server receives
the request for X. so, if i understand your question, yes.

i think your terminology is confusing you, e.g.: "AFTER the form has
submitted to himself". a form doesn't submit to itself. a form and a script
that processes it are SEPARATE THINGS.

it's better to think in terms of a user agent and a server communicating
with http requests and responses. the UA sends http requests for uris X, Y,
Z, etc. (with or without accompanying form data). the forms are part of html
pages the server sends to the UA in http responses. a user drives the UA.
PHP scripts are involved in the server's generation of responses. (a diagram
might help.)

now to your queston:

if a UA has an html page that it got in a response for uri X; and if the
page has a form; and if the form has no action attribute (or action=X); and
if the user submits the form; then the UA will send the server an http
request for X.

next the server receives the request for X and the server runs a certain
script, the php script you are coding.

now i'm assuming these are your requirements: if that script determines
failure, the user says at X and is asked to resubmit the form. if the script
determines success, the user will wind up at a new uri: Y. further, you want
to send the user over to Y by sending her UA an http response with
Location=Y redirection.

in these terms, the answer to your question should be pretty clear. your
script has to receive and process requests for X before it can decide if
it's going to respond to the UA with a Location=Y redirection or an html
page with a form and an error message.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[tedd]

At 9:42 AM -0400 10/3/09, Tom Worster wrote:

On 10/2/09 10:24 AM, "tedd"  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 my hidden variables pose any security problems whatsoever.


...because one always assumes that data supplied in an http request is
tainted. hence arguments about which exploit is more likely is rather
pointless.

a hidden input is really no different from any other form field. kranthi's
argument would be consistent if he felt that all form inputs should be
avoided because they are so easily modified as to pose a security threat.


Exactly.

All data gathered via forms, hidden or not, must be sanitized.

Cheers,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[tedd]

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 shows no
form elements.

Sorry if I've not understand. I was having no intention of doing so.

Regards,
Márcio



Márcio:

At some point here, you must take keyboard in hand and program this yourself.

If you took my code and ran it, then you would understand.

Here's a working example:

http://www.webbytedd.com/aa/step-form/

This only one of many ways to solve your problem, but it does solve it.

Cheers,

tedd

PS: Please reply to the list and not me 
privately, unless you are hiring me (learned that 
from Stut)

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/2/09 10:24 AM, "tedd"  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 my hidden variables pose any security problems whatsoever.

...because one always assumes that data supplied in an http request is
tainted. hence arguments about which exploit is more likely is rather
pointless. 

a hidden input is really no different from any other form field. kranthi's
argument would be consistent if he felt that all form inputs should be
avoided because they are so easily modified as to pose a security threat.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Manuel Lemos]

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 other!
> I completely agree with you. changing submit text is as easy as
> changing hidden fields, but its less likely for a user to modify a
> submit button as compared to a hidden field. moreover it just reduces
> my typing load. (This is just my practice)

How come an user can modify a hidden field is more likely to change
submit button? I don't think an average user will modify anything at all.


>>> Also worth noting, you can only successfully check for the name="submit"
>>> value if there is only one submit button in your form, as that is then
>>> the default (and only) submit that the form can use, so it uses that. If
>>> you have more than one submit button (and this includes image input
>>> elements) then using the keyboard will use the first submit field it
>>> finds I believe.
> Cant agree with you on this though. as far as i know using name=""
> (names of the two buttons may/may not be unique) is the only way to
> track form submission for forms with multiple submit buttons. Please
> point out if you think otherwise

As everbody has been telling you, if you check an hidden field it will
work regardless whether the user clicked on a button or hit enter on a
text input. With multiple buttons there is no way (except for using some
Javascript) to tell whether it was clicked a button or the user hit
enter in a text input.


-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Manuel Lemos]

Hello,

on 10/02/2009 05:25 AM kranthi said the following:
> and yes i forgot to mention... i avoid hidden form elements because
> they can be modified very easily and hence pose a security threat.

How can hidden field be changed in a way that submit buttons can't? I do
 not see any security threat scenario.

-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Manuel Lemos]

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, because i use the above mentioned method in nearly all
> of my projects, and all of them are working fine.
> 
> P.S: i prefer keyboard to mouse as a input device

Sorry, what I meant is that if you have multiple submit buttons in your
form, say "Preview", "Save" and "Cancel", if you hit enter in a text
input it will not set the variables for all buttons. At most only one
button variable is set, which usually is the first button in the HTML,
but you have no way to change which will be set.

If you use an hidden field is easier to determine whether the form was
submitted or not, as you do not have to check variables for all buttons.

-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Ben Dunlap]

> 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 it's the only way, redirecting to a success page is
probably the best way, from a user-experience perspective. It keeps
the browser history sane and avoids possible trouble with
page-refreshes.

Google for "post redirect get" and you'll find all sorts of
discussions of this pattern. Here's one of the clearer articles that
came up on the first page of results, when I ran that search:

http://www.andypemberton.com/engineering/the-post-redirect-get-pattern/

Ben

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[tedd]

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 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?


No -- and you are not listening.

I gave you the way to do it, but you are taking another path. As 
always, it's your choice.


Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

> 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 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?


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[tedd]

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 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 attention here, correct?

Since we are not dealing with a confirmation page, or a multi-step form, the
hidden field isn't necessary.

It's this correct assumptions?

Please advice,
Regards,
Márcio


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

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[tedd]

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.

Cheers,

tedd


--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

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 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 attention here, correct?

Since we are not dealing with a confirmation page, or a multi-step form, the
hidden field isn't necessary.

It's this correct assumptions?

Please advice,
Regards,
Márcio



> -Original Message-
> From: kranthi [mailto:kranthi...@gmail.com]
> Sent: sexta-feira, 2 de Outubro de 2009 11:12
> To: a...@ashleysheridan.co.uk
> Cc: Manuel Lemos; php-general@lists.php.net; MEM; Bob 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 other!
> I completely agree with you. changing submit text is as easy as
> changing hidden fields, but its less likely for a user to modify a
> submit button as compared to a hidden field. moreover it just reduces
> my typing load. (This is just my practice)
> 
> >> Also worth noting, you can only successfully check for the
> name="submit"
> >> value if there is only one submit button in your form, as that is
> then
> >> the default (and only) submit that the form can use, so it uses that.
> If
> >> you have more than one submit button (and this includes image input
> >> elements) then using the keyboard will use the first submit field it
> >> finds I believe.
> Cant agree with you on this though. as far as i know using name=""
> (names of the two buttons may/may not be unique) is the only way to
> track form submission for forms with multiple submit buttons. Please
> point out if you think otherwise
> 
> --
> Kranthi.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[kranthi]

>> 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 easy as
changing hidden fields, but its less likely for a user to modify a
submit button as compared to a hidden field. moreover it just reduces
my typing load. (This is just my practice)

>> Also worth noting, you can only successfully check for the name="submit"
>> value if there is only one submit button in your form, as that is then
>> the default (and only) submit that the form can use, so it uses that. If
>> you have more than one submit button (and this includes image input
>> elements) then using the keyboard will use the first submit field it
>> finds I believe.
Cant agree with you on this though. as far as i know using name=""
(names of the two buttons may/may not be unique) is the only way to
track form submission for forms with multiple submit buttons. Please
point out if you think otherwise

-- 
Kranthi.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Ashley Sheridan]

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 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!

Also worth noting, you can only successfully check for the name="submit"
value if there is only one submit button in your form, as that is then
the default (and only) submit that the form can use, so it uses that. If
you have more than one submit button (and this includes image input
elements) then using the keyboard will use the first submit field it
finds I believe.

Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[kranthi]

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

Re: [PHP] Self-Process php forms or not?

[kranthi]

>> 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 projects, and all of them are working fine.

P.S: i prefer keyboard to mouse as a input device

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Manuel Lemos]

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 to the action script.
> 
> above all i use a template engine, smarty to take care of the
> presentation for me(like deciding whether to show the form and/or a
> success/failure message)

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.

-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[kranthi]

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 to take care of the
presentation for me(like deciding whether to show the form and/or a
success/failure message)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Manuel Lemos]

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 show the form?
> 
> Can please someone throw me some infos about this please?
> 
> 
> Ps- I've googled: "php redirect success page on self submit form" and
> similar... 

All you need to do is to include an hidden field in the form. Then check
the respective $_POST or $_GET variable is set. If it is not set, show
the form for the first time. If it is set, validate the form and process
it. If the form is not valid, show the form again with previously
submitted values.

This tutorial video explains this workflow:

http://www.phpclasses.org/browse/video/1/package/1/section/usage.html

This example script demonstrates how to setup your code. It uses a
function of a forms class name WasSubmiteed() to check if the form is
being presented for the first time or is being submitted:

http://www.meta-language.net/forms-examples.html?example=test_form&code=1

-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

Thanks a lot to all,

I will see what best fits my limited knowledge, and choose the possible
option.

Regards,
Márcio

> -Original Message-
> From: Tom Worster [mailto:f...@thefsb.org]
> Sent: quinta-feira, 1 de Outubro de 2009 20:11
> To: tedd; 'PHP-General List'
> Subject: Re: [PHP] Self-Process php forms or not?
> 
> On 10/1/09 10:13 AM, "tedd"  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 page" or a "confirmation page" that doesn't show the form?
> >>
> >> Can please someone throw me some infos about this please?
> >
> >
> > MEM:
> >
> > Here's what I do -- it's pretty simple.
> >
> > I use a hidden input variable I call "step" and monitor it as the
> > user clicks whatever form submit they are on -- it works like so:
> >
> > $step = isset($_POST['step']) ? $_POST['step'] : 0;
> >
> > switch ($step)
> > {
> >case 0: // present the first form to the user
> >// collect data
> >// you can enhance the user experience by using javascript here.
> >// 
> > break;
> >
> >case 1: // present second form to the user
> >// clean data
> >// if data OK then record data in db  value=2>
> >// if data not OK then send user back  value=0>
> > break;
> >
> >case 2: //present the third form to the user
> >// success, or confirmation, or thank you page
> > break;
> > }
> >
> > Now, to make things easier for the user, be sure to set session
> > variables for all the data collected in the first form so that IF you
> > send the user back to the first form, the user doesn't have to
> > reenter everything.
> 
> i do pretty much the same thing. each form in my html template files
> has a
> form name tucked away in a hidden input element. the only difference
> from
> your method is that the names are unique across the application.
> 
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/1/09 10:13 AM, "tedd"  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 page" or a "confirmation page" that doesn't show the form?
>> 
>> Can please someone throw me some infos about this please?
> 
> 
> MEM:
> 
> Here's what I do -- it's pretty simple.
> 
> I use a hidden input variable I call "step" and monitor it as the
> user clicks whatever form submit they are on -- it works like so:
> 
> $step = isset($_POST['step']) ? $_POST['step'] : 0;
> 
> switch ($step)
> {
>case 0: // present the first form to the user
>// collect data
>// you can enhance the user experience by using javascript here.
>// 
> break;
> 
>case 1: // present second form to the user
>// clean data
>// if data OK then record data in db 
>// if data not OK then send user back 
> break;
> 
>case 2: //present the third form to the user
>// success, or confirmation, or thank you page
> break;
> }
> 
> Now, to make things easier for the user, be sure to set session
> variables for all the data collected in the first form so that IF you
> send the user back to the first form, the user doesn't have to
> reenter everything.

i do pretty much the same thing. each form in my html template files has a
form name tucked away in a hidden input element. the only difference from
your method is that the names are unique across the application.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Ashley Sheridan]

On Thu, 2009-10-01 at 09:30 -0400, Tom Worster wrote:
> On 10/1/09 8:00 AM, "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 please someone throw me some infos about this please?
> 
> i use one php script that knows how to deliver more than one html page
> depending on the outcome of processing of form input and the rest.
> 
> i'm sure there are other ways.
> 
> 
> 

The way I always tend to do something like this is as follows:

$errors = false;
if(isset($_REQUEST['submit']))
{
// process form here
// if it doesn't validate $errors to true

// you can either redirect here, or display the confirmation message
}
if(!isset($_REQUEST['submit']) || $errors)
{
// display form
// if $errors is true populate the form with user submitted data
}


Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[tedd]

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 please someone throw me some infos about this please?



MEM:

Here's what I do -- it's pretty simple.

I use a hidden input variable I call "step" and monitor it as the 
user clicks whatever form submit they are on -- it works like so:


$step = isset($_POST['step']) ? $_POST['step'] : 0;

switch ($step)
   {
  case 0: // present the first form to the user
  // collect data
  // you can enhance the user experience by using javascript here.
  // 
   break;

  case 1: // present second form to the user
  // clean data
  // if data OK then record data in db 
  // if data not OK then send user back 
   break;

  case 2: //present the third form to the user
  // success, or confirmation, or thank you page
   break;
   }

Now, to make things easier for the user, be sure to set session 
variables for all the data collected in the first form so that IF you 
send the user back to the first form, the user doesn't have to 
reenter everything.


HTH,

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tommy Pham]

 Original Message 
> From: Mert Oztekin 
> To: MEM ; Bob McConnell ; PHP-General List 
> 
> Sent: Thursday, October 1, 2009 5:16:40 AM
> Subject: RE: [PHP] Self-Process php forms or not?
> 
> 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 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 please someone throw me some infos about this please?
> 

Use of javascript to validate form is not required but will help with 
(processing) load on the server side.  However, you should always validate and 
sanitize all user input on server side if you want to maintain good data 
integrity in your DB and security.  Why?  In case someone uses cURL or another 
TCP app to do GET/POST to your app (server)  ;)  As for redirecting w/o 
javascript, it's easy.  Here's a sample:

entryForm.php post to $self or other $url > $self / $url validates the form >
* if valid form > redirect via header()
 or > include/require another modular page  (suggested)
* else invalid form > show entryForm.php with errors

You can either pass the variables via GET in your redirect or use $_SESSION 
variables.  I prefer $_SESSION since you really make your app modular and have 
access to those variables from any include/require page.  If you're really 
innovative, you could expand on it to have more performance ;)

Regards,
Tommy

> 
> 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 or not?
> >
> > When you have it all in one file, the first thing you do is check to
> > see if this request was submitted from the form. If not, you send the
> > blank form. If it was, you validate all of the data. When a validation
> > fails, you add error messages and resend the form with any fields that
> > passed the validation already filled in. When validation succeeds,
> > process and move on. No muss, no fuss.
> >
> > Bob McConnell
> >
> > -Original Message-
> > From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu]
> > Sent: Friday, April 24, 2009 8:53 AM
> > 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 have to change
> > only
> > one file instead of two.
> >
> > SanTa
> >
> > - Original Message -
> > From: "MEM" 
> > To: "'PHP-General List'" 
> > 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 to another .php page.
> >
> > Can anyone point me some resources about this. Why using one instead of
> > another. What are the main advantages?
> >
> >
> >
> > Regards,
> > Márcio
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> Bu mesaj ve ekleri, mesajda gönderildiği belirtilen kişi/kişilere özeldir ve 
> gizlidir. Size yanlışlıkla ulaşmışsa lütfen gönderen kisiyi bilgilendiriniz 
> ve 
> mesajı sisteminizden siliniz. Mesaj ve eklerinin içeriği ile ilgili olarak 
> şirketimizin herhangi bir hukuki sorumluluğu bulunmamaktadır. Şirketimiz 
> mesajın 
> ve bilgilerinin size değişikliğe uğrayarak veya geç ula

RE: [PHP] Self-Process php forms or not?

[Jason]

I've used the form page with a the following code (at the bottom - but
before any output is done) to redirect to a thank you page:

if ($submittedcorrectly)
{
  header("Location: thankyou.htm"); 
  exit();
}

HTH
J

-Original Message-
From: MEM [mailto:tal...@gmail.com] 
Sent: 01 October 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" or a "confirmation page" that doesn't show the form?

Can please someone throw me some infos about 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 or not?
> 
> When you have it all in one file, the first thing you do is check to
> see if this request was submitted from the form. If not, you send the
> blank form. If it was, you validate all of the data. When a validation
> fails, you add error messages and resend the form with any fields that
> passed the validation already filled in. When validation succeeds,
> process and move on. No muss, no fuss.
> 
> Bob McConnell
> 
> -Original Message-
> From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu]
> Sent: Friday, April 24, 2009 8:53 AM
> 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 have to change
> only
> one file instead of two.
> 
> SanTa
> 
> - Original Message -
> From: "MEM" 
> To: "'PHP-General List'" 
> 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 to another .php page.
> 
> Can anyone point me some resources about this. Why using one instead of
> another. What are the main advantages?
> 
> 
> 
> Regards,
> Márcio
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tom Worster]

On 10/1/09 8:00 AM, "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 please someone throw me some infos about this please?

i use one php script that knows how to deliver more than one html page
depending on the outcome of processing of form input and the rest.

i'm sure there are other ways.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[Mert Oztekin]

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 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 please someone throw me some infos about 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 or not?
>
> When you have it all in one file, the first thing you do is check to
> see if this request was submitted from the form. If not, you send the
> blank form. If it was, you validate all of the data. When a validation
> fails, you add error messages and resend the form with any fields that
> passed the validation already filled in. When validation succeeds,
> process and move on. No muss, no fuss.
>
> Bob McConnell
>
> -Original Message-
> From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu]
> Sent: Friday, April 24, 2009 8:53 AM
> 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 have to change
> only
> one file instead of two.
>
> SanTa
>
> - Original Message -
> From: "MEM" 
> To: "'PHP-General List'" 
> 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 to another .php page.
>
> Can anyone point me some resources about this. Why using one instead of
> another. What are the main advantages?
>
>
>
> Regards,
> Márcio
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Bu mesaj ve ekleri, mesajda gönderildiği belirtilen kişi/kişilere özeldir ve 
gizlidir. Size yanlışlıkla ulaşmışsa lütfen gönderen kisiyi bilgilendiriniz ve 
mesajı sisteminizden siliniz. Mesaj ve eklerinin içeriği ile ilgili olarak 
şirketimizin herhangi bir hukuki sorumluluğu bulunmamaktadır. Şirketimiz 
mesajın ve bilgilerinin size değişikliğe uğrayarak veya geç ulaşmasından, 
bütünlüğünün ve gizliliğinin korunamamasından, virüs içermesinden ve bilgisayar 
sisteminize verebileceği herhangi bir zarardan sorumlu tutulamaz.

This message and attachments are confidential and intended for the 
individual(s) stated in this message. If you received this message in error, 
please immediately notify the sender and delete it from your system. Our 
company has no legal responsibility for the contents of the message and its 
attachments. Our company shall have no liability for any changes or late 
receiving, loss of integrity and confidentiality, viruses and any damages 
caused in anyway to your computer system.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

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 please someone throw me some infos about 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 or not?
> 
> When you have it all in one file, the first thing you do is check to
> see if this request was submitted from the form. If not, you send the
> blank form. If it was, you validate all of the data. When a validation
> fails, you add error messages and resend the form with any fields that
> passed the validation already filled in. When validation succeeds,
> process and move on. No muss, no fuss.
> 
> Bob McConnell
> 
> -Original Message-
> From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu]
> Sent: Friday, April 24, 2009 8:53 AM
> 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 have to change
> only
> one file instead of two.
> 
> SanTa
> 
> - Original Message -
> From: "MEM" 
> To: "'PHP-General List'" 
> 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 to another .php page.
> 
> Can anyone point me some resources about this. Why using one instead of
> another. What are the main advantages?
> 
> 
> 
> Regards,
> Márcio
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[PJ]

Shawn McKenzie wrote:
> PJ wrote:
>   
>> AngeloZanetti wrote:
>> 
>>> Shawn McKenzie wrote:
>>>
>>>   
 PJ wrote:

 
> PROBLEM 1 solved: errant s 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?
>
>
>   
 Remove the link to any stylesheets that you're using and see what
 it looks like.




 
>>> Where is your source code / form so we can see what is going on?
>>>
>>> http://www.Elemental.co.za http://www.Elemental.co.za 
>>> http://www.wapit.co.za http://www.wapit.co.za
>>>
>>>   
>> The code: ...snip  > method="post" action=""> 
>> accès client > value="" size="10" /> mot de passe > />> size="10" /> > value="  entrez " /> > href="inscription.php"> Inscription   >
>> I had posted this earlier... just before finding the blockage for the
>> input in PROBLEM 1, though I don't know why some stray s would
>> cause that.
>>
>>
>> 
>
> Based on the fact that you said things were "off the page and clipped in
> the upper right hand corner", I thought that you had a style that may
> have positioned the div or the form or something.  If you disable all
> styles, whether in the head of the document or via an external
> stylesheet, then that should show the form on the page as it should.
 I think I didn't explain correctly; It does not appear on the page(IE
6) as it should & does in Firefox3.
The form is displayed but off-screen on startup; The page is set for a
width of 1025px but the display is probably about 900px so the form is
just off-screen to the right. But it is clipped in the middle and all
you see is the password and submit fields.
I suspect that the guilty party here is the CSS - I have the top margin
set to -100px in order to position it where I want it. I guess, I have
to find another way to position it. :-(

-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[PJ]

Andrew Ballard wrote:
> On Wed, Jun 3, 2009 at 7:13 PM, PJ  wrote:
>   
>> Tom Chubb wrote:
>> 
>>> 2009/6/3 PJ :
>>>
>>>   
 The code:
 ...snip
 
 Â  Â  Â  Â 
 Â  Â  Â  Â  Â  Â accès client >>> name="title" value="" size="10" />
 Â  Â  Â  Â  Â  Â mot de passe >>> value=">>> echo $passwd; ?>" size="10" />
            >>> value="      entrez     " />
 Â  Â  Â  Â  Â  Â  Inscription 
 Â  Â  Â  Â 
 Â  Â >>> snip...

 PROBLEM 1: On Firefox3, the first input (accès client) does not accept
 any input, does not show the cursor; the second input (mot de passe)
 works fine.

 PROBLEM 2: The form does not appear on IE 6

 Running FreeBSD 7.1, apache22, php 5, using sessions, CSS

 Am I doing something wrong?

 --
 Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
 -
 Phil Jourdan --- p...@ptahhotep.com
 Â  http://www.ptahhotep.com
 Â  http://www.chiccantine.com/andypantry.php


 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



 
>>> I think the first problem is because both your inputs are defined as 
>>> "title".
>>>
>>>   
>> Does that change anything in the functionanlity? If so, how?
>> Bastien says it works in IE8; here it does not in IE6. :-)
>>
>> 
>
> I'm not sure about functionanlity, but it definitely changes the
> functionality. ;-) 
>
> It means that regardless of whether someone is able to enter a value
> in the field you have labeled "accès client", your PHP page will never
> see it because it will look at the value from the field you have
> labeled "mot de passe", even if it is left blank. And that is true
> regardless of which browser they are using. In some scripting platform
> other than PHP, or if you process the raw post data yourself it could
> be different, but in PHP the variable $_POST['title'] will only have
> one value in it, and it will be the last one passed by the form. (In
> this case, "mot de passe".)
>
> Andrew
>   
Thanks Andrew, I hadn't gotten that far and had not thought about
that... it's a wake-up call for me. Glad to learn that. PJ

-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[Andrew Ballard]

On Wed, Jun 3, 2009 at 7:13 PM, PJ  wrote:
> Tom Chubb wrote:
>> 2009/6/3 PJ :
>>
>>> The code:
>>> ...snip
>>> 
>>>        
>>>            accès client >> name="title" value="" size="10" />
>>>            mot de passe 
>>>            >> value="      entrez     " />
>>>             Inscription 
>>>        
>>>    >> snip...
>>>
>>> PROBLEM 1: On Firefox3, the first input (accès client) does not accept
>>> any input, does not show the cursor; the second input (mot de passe)
>>> works fine.
>>>
>>> PROBLEM 2: The form does not appear on IE 6
>>>
>>> Running FreeBSD 7.1, apache22, php 5, using sessions, CSS
>>>
>>> Am I doing something wrong?
>>>
>>> --
>>> Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
>>> -
>>> Phil Jourdan --- p...@ptahhotep.com
>>>   http://www.ptahhotep.com
>>>   http://www.chiccantine.com/andypantry.php
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>>
>>
>> I think the first problem is because both your inputs are defined as "title".
>>
> Does that change anything in the functionanlity? If so, how?
> Bastien says it works in IE8; here it does not in IE6. :-)
>

I'm not sure about functionanlity, but it definitely changes the
functionality. ;-)

It means that regardless of whether someone is able to enter a value
in the field you have labeled "accès client", your PHP page will never
see it because it will look at the value from the field you have
labeled "mot de passe", even if it is left blank. And that is true
regardless of which browser they are using. In some scripting platform
other than PHP, or if you process the raw post data yourself it could
be different, but in PHP the variable $_POST['title'] will only have
one value in it, and it will be the last one passed by the form. (In
this case, "mot de passe".)

Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[Shawn McKenzie]

PJ wrote:
> AngeloZanetti wrote:
>> Shawn McKenzie wrote:
>> 
>>> PJ wrote:
>>> 
 PROBLEM 1 solved: errant s 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?
 
 
>>> Remove the link to any stylesheets that you're using and see what
>>> it looks like.
>>> 
>>> 
>>> 
>>> 
>> Where is your source code / form so we can see what is going on?
>> 
>> http://www.Elemental.co.za http://www.Elemental.co.za 
>> http://www.wapit.co.za http://www.wapit.co.za
>> 
> 
> The code: ...snip   method="post" action=""> 
> accès client  value="" size="10" /> mot de passe  /> size="10" />  value="  entrez " />  href="inscription.php"> Inscription
> I had posted this earlier... just before finding the blockage for the
> input in PROBLEM 1, though I don't know why some stray s would
> cause that.
> 
> 

Based on the fact that you said things were "off the page and clipped in
the upper right hand corner", I thought that you had a style that may
have positioned the div or the form or something.  If you disable all
styles, whether in the head of the document or via an external
stylesheet, then that should show the form on the page as it should.

-- 
Thanks!
-Shawn
http://www.spidean.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[PJ]

AngeloZanetti wrote:
>
> Shawn McKenzie wrote:
>   
>> PJ wrote:
>> 
>>> PROBLEM 1 solved: errant s 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?
>>>
>>>   
>> Remove the link to any stylesheets that you're using and see what it
>> looks like.
>>
>>
>>
>> 
>
> Where is your source code / form so we can see what is going on?
>
> http://www.Elemental.co.za http://www.Elemental.co.za 
> http://www.wapit.co.za http://www.wapit.co.za 
>   

The code:
...snip

   
   accès client 
   mot de passe 
   
Inscription 
   
   s would cause that.


-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[PJ]

Tom Chubb wrote:
> 2009/6/3 PJ :
>   
>> The code:
>> ...snip
>> 
>>
>>accès client > name="title" value="" size="10" />
>>mot de passe 
>>> value="  entrez " />
>> Inscription 
>>
>>> snip...
>>
>> PROBLEM 1: On Firefox3, the first input (accès client) does not accept
>> any input, does not show the cursor; the second input (mot de passe)
>> works fine.
>>
>> PROBLEM 2: The form does not appear on IE 6
>>
>> Running FreeBSD 7.1, apache22, php 5, using sessions, CSS
>>
>> Am I doing something wrong?
>>
>> --
>> Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
>> -
>> Phil Jourdan --- p...@ptahhotep.com
>>   http://www.ptahhotep.com
>>   http://www.chiccantine.com/andypantry.php
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>> 
>
> I think the first problem is because both your inputs are defined as "title".
>   
Does that change anything in the functionanlity? If so, how?
Bastien says it works in IE8; here it does not in IE6. :-)

-- 
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[AngeloZanetti]

Shawn McKenzie wrote:
> 
> PJ wrote:
>> PROBLEM 1 solved: errant s 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?
>> 
> 
> Remove the link to any stylesheets that you're using and see what it
> looks like.
> 
> 
> 

Where is your source code / form so we can see what is going on?

http://www.Elemental.co.za http://www.Elemental.co.za 
http://www.wapit.co.za http://www.wapit.co.za 

-- 
View this message in context: 
http://www.nabble.com/forms-problem-tp23854436p23857375.html
Sent from the PHP - General mailing list archive at Nabble.com.


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[Tom Chubb]

2009/6/3 PJ :
> The code:
> ...snip
> 
>        
>            accès client  name="title" value="" size="10" />
>            mot de passe 
>             value="      entrez     " />
>             Inscription 
>        
>     snip...
>
> PROBLEM 1: On Firefox3, the first input (accès client) does not accept
> any input, does not show the cursor; the second input (mot de passe)
> works fine.
>
> PROBLEM 2: The form does not appear on IE 6
>
> Running FreeBSD 7.1, apache22, php 5, using sessions, CSS
>
> Am I doing something wrong?
>
> --
> Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
> -
> Phil Jourdan --- p...@ptahhotep.com
>   http://www.ptahhotep.com
>   http://www.chiccantine.com/andypantry.php
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I think the first problem is because both your inputs are defined as "title".

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] forms problem

[PJ]

PROBLEM 1 solved: errant s 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 capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] forms problem

[Bastien Koert]

On Wed, Jun 3, 2009 at 11:55 AM, PJ  wrote:
> The code:
> ...snip
> 
>        
>            accès client  name="title" value="" size="10" />
>            mot de passe 
>             value="      entrez     " />
>             Inscription 
>        
>     snip...
>
> PROBLEM 1: On Firefox3, the first input (accès client) does not accept
> any input, does not show the cursor; the second input (mot de passe)
> works fine.
>
> PROBLEM 2: The form does not appear on IE 6
>
> Running FreeBSD 7.1, apache22, php 5, using sessions, CSS
>
> Am I doing something wrong?
>
> --
> Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
> -
> Phil Jourdan --- p...@ptahhotep.com
>   http://www.ptahhotep.com
>   http://www.chiccantine.com/andypantry.php
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

works in IE8 and Chorme

Doesn't look like anything is wrong..post more code


-- 

Bastien

Cat, the other other white meat

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] forms problem

[PJ]

The code:
...snip


accès client 
mot de passe 

 Inscription 

http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms validation and creation- easier solution?

[phphelp -- kbk]

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 metadata tables contain:

 -- field captions
 -- field-use descriptions and business rules (generates CSS pop-up  
help)

 -- the type of control used
 -- the source of data for controls (I call system codes: like the  
lists of choices for comboboxes and radio buttons -- I keep almost  
all of these in a single table.)

 -- whether data in a field is required
 -- whether the data in a field are visible, editable, or new-record- 
only editable
 -- whether the data are encrypted (core data class handles the  
encryption/decryption)

 -- data entry order
 -- any non-standard user rights to the data.
 -- Simple business rules (like maximums, minimums and ranges of  
acceptable values)
 -- easy validation categories: birthdates, eMail formatting, USA  
phone numbers & postal codes, US social security #'s, credit card  
format, and the like.


The last two can generate JavaScript, too (still working on that).

 -- I also am working on more complex validation being automatic:  
across fields or tables, dependent on other variables, etc.


By standardizing the format of metadata and the means of storing  
system code values, plus core CSS class names, you can use this  
across projects.


Ken

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms validation and creation- easier solution?

[Manuel Lemos]

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 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 you need to type to achieve the same generating
>> common HTML inputs manually.
>>
>> Anyone can judge by yourself by going here and see several example forms
>> and the actual code that it takes to generate them:
>>
>> http://www.meta-language.net/forms-examples.html
>>
>> For instance this scaffolding plug-in generates CRUD forms that you
>> often need to manage data stored for instance in databases.
>>
>> http://www.meta-language.net/forms-examples.html?example=test_scaffolding_input
>>
>> For those interested to check it out, the actual class package can be
>> downloaded from here:
>>
>> http://www.phpclasses.org/formsgeneration
>>
>> Here you may watch an extensive tutorial video that covers practically
>> all features:
>>
>> http://www.phpclasses.org/browse/video/1/package/1.html
>>
> 
> 
> Here's what I was talking about. Assuming you simply type out your form
> fields like this:
> 
> 
> 
> Now, if you do it with a class like yours:
> 
> $arr = array('type' => 'text',
> 'name' => 'address',
> 'size' => 30,
> 'value' => '123 Main St.');
> 
> $form->AddInput($arr);
> 
> (I haven't looked at your class in a while, so I may have invoked it
> slightly incorrectly.)
> 
> If you compare the typing involved in the first case with the typing
> involved in the second case, you can see that it's more in the second
> case.

That is because you are just thinking about the typing of the generated
HTML. To generate and validate forms, you also have to consider the code
you write to validate and process the forms because the HTML forms do
not process by themselves.

You need to think about the security of your application, so you also
need to validate submitted values, discard invalid values, escape
outputted values, and so on. All that is done with a couple of calls to
the forms class.


> Yes, your forms generation class includes a tremendous amount of proven
> code, including a bunch of Javascript validation, all of which the
> programmer doesn't have to develop himself.
> 
> The only real complaint I have about your class is that the class file
> itself (forms.php) is 158+ K bytes, which must be loaded every time you
> surf to a page for the first time.

That used to be an issue in the 20th century in the PHP 3 days. Since
PHP 4, the PHP code is no longer interpreted. The Zend engine compiles
the PHP code in Zend op codes in the first stage. In the second stage
the op codes are executed. If you use a cache extension like APC, Turck
MMCache, XCache, etc.. the first step is skipped after the first
execution and the size of the original code is not relevant because it
is already compiled in shared memory.

Anyway, the class has all that code because it is necessary to implement
all it supports.

-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms validation and creation- easier solution?

[Paul M Foster]

On Fri, May 22, 2009 at 04:56:01AM -0300, Manuel Lemos wrote:

> Hello,
> 
> on 05/20/2009 11:09 AM Paul M Foster said the following:
> > Both this class and Manuel Lemos' form generation class (from
> > phpclasses.org) will create beautiful forms for you. However, you may
> > find that the amount of [repetitive] typing you do will be equivalent or
> > greater than simply creating the form by hand.
> >
> > The best solution would probably be a form you fill out which asks you
> > about all the fields you want, and then generates the code to paint the
> > form. There are commercial solutions which do this, and some (not that
> > great) free solutions. I'm working on one myself, which will eventually
> > be a sourceforge/freshmeat project.
> 
> Thank you for mentioning my package, but I am not sure what you mean.
> 
> The Forms Generation and Validation package seems to do exactly what you
> describe and more.
> 
> 
> 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.
> 
> Furthermore, the plug-ins that come with the package dramatically reduce
> the amount of code you need to type to achieve the same generating
> common HTML inputs manually.
> 
> Anyone can judge by yourself by going here and see several example forms
> and the actual code that it takes to generate them:
> 
> http://www.meta-language.net/forms-examples.html
> 
> For instance this scaffolding plug-in generates CRUD forms that you
> often need to manage data stored for instance in databases.
> 
> http://www.meta-language.net/forms-examples.html?example=test_scaffolding_input
> 
> For those interested to check it out, the actual class package can be
> downloaded from here:
> 
> http://www.phpclasses.org/formsgeneration
> 
> Here you may watch an extensive tutorial video that covers practically
> all features:
> 
> http://www.phpclasses.org/browse/video/1/package/1.html
> 


Here's what I was talking about. Assuming you simply type out your form
fields like this:



Now, if you do it with a class like yours:

$arr = array('type' => 'text',
'name' => 'address',
'size' => 30,
'value' => '123 Main St.');

$form->AddInput($arr);

(I haven't looked at your class in a while, so I may have invoked it
slightly incorrectly.)

If you compare the typing involved in the first case with the typing
involved in the second case, you can see that it's more in the second
case.

Yes, your forms generation class includes a tremendous amount of proven
code, including a bunch of Javascript validation, all of which the
programmer doesn't have to develop himself.

The only real complaint I have about your class is that the class file
itself (forms.php) is 158+ K bytes, which must be loaded every time you
surf to a page for the first time.

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms validation and creation- easier solution?

[Angelo Zanetti]

-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:
> Both this class and Manuel Lemos' form generation class (from
> phpclasses.org) will create beautiful forms for you. However, you may
> find that the amount of [repetitive] typing you do will be equivalent or
> greater than simply creating the form by hand.
> 
> The best solution would probably be a form you fill out which asks you
> about all the fields you want, and then generates the code to paint the
> form. There are commercial solutions which do this, and some (not that
> great) free solutions. I'm working on one myself, which will eventually
> be a sourceforge/freshmeat project.

Thank you for mentioning my package, but I am not sure what you mean.

The Forms Generation and Validation package seems to do exactly what you
describe and more.


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.

Furthermore, the plug-ins that come with the package dramatically reduce
the amount of code you need to type to achieve the same generating
common HTML inputs manually.

Anyone can judge by yourself by going here and see several example forms
and the actual code that it takes to generate them:

http://www.meta-language.net/forms-examples.html

For instance this scaffolding plug-in generates CRUD forms that you
often need to manage data stored for instance in databases.

http://www.meta-language.net/forms-examples.html?example=test_scaffolding_in
put

For those interested to check it out, the actual class package can be
downloaded from here:

http://www.phpclasses.org/formsgeneration

Here you may watch an extensive tutorial video that covers practically
all features:

http://www.phpclasses.org/browse/video/1/package/1.html


Thanks manuel.

I will check out the class.

Much appreciated your response.

Thanks
Angelo

Elemental
http://www.elemental.co.za


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms validation and creation- easier solution?

[Manuel Lemos]

Hello,

on 05/20/2009 11:09 AM Paul M Foster said the following:
> Both this class and Manuel Lemos' form generation class (from
> phpclasses.org) will create beautiful forms for you. However, you may
> find that the amount of [repetitive] typing you do will be equivalent or
> greater than simply creating the form by hand.
> 
> The best solution would probably be a form you fill out which asks you
> about all the fields you want, and then generates the code to paint the
> form. There are commercial solutions which do this, and some (not that
> great) free solutions. I'm working on one myself, which will eventually
> be a sourceforge/freshmeat project.

Thank you for mentioning my package, but I am not sure what you mean.

The Forms Generation and Validation package seems to do exactly what you
describe and more.


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.

Furthermore, the plug-ins that come with the package dramatically reduce
the amount of code you need to type to achieve the same generating
common HTML inputs manually.

Anyone can judge by yourself by going here and see several example forms
and the actual code that it takes to generate them:

http://www.meta-language.net/forms-examples.html

For instance this scaffolding plug-in generates CRUD forms that you
often need to manage data stored for instance in databases.

http://www.meta-language.net/forms-examples.html?example=test_scaffolding_input

For those interested to check it out, the actual class package can be
downloaded from here:

http://www.phpclasses.org/formsgeneration

Here you may watch an extensive tutorial video that covers practically
all features:

http://www.phpclasses.org/browse/video/1/package/1.html

-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms validation and creation- easier solution?

[Paul M Foster]

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 at 10:08:12AM +0300, Olexandr Heneralov wrote:
> 
> >
> > 2009/5/20 Angelo Zanetti 
> >
> > > 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. Validation of specific fields within the forms (server side not JS)
> > >
> > > 3. Decrease in time required to setup the forms pages
> > > any other comments are welcome.
> > >
> > 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.
> 
> Both this class and Manuel Lemos' form generation class (from
> phpclasses.org) will create beautiful forms for you. However, you may
> find that the amount of [repetitive] typing you do will be equivalent or
> greater than simply creating the form by hand.
> 
> The best solution would probably be a form you fill out which asks you
> about all the fields you want, and then generates the code to paint the
> form. There are commercial solutions which do this, and some (not that
> great) free solutions. I'm working on one myself, which will eventually
> be a sourceforge/freshmeat project.
> 
> Hi Paul.
> 
> This sounds Great. Thanks for the advise. Just as a matter of interest do
> you know the location / path to Jay's class? I tried searching the archives
> but couldn't find it/
> 
> Thanks
> Angelo
> 

You can search the archives by author, but I found it here:

http://marc.info/?l=php-general&m=123003593813003&w=2

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms validation and creation- easier solution?

[Angelo Zanetti]

-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 Zanetti 
> 
> > 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. Validation of specific fields within the forms (server side not JS)
> >
> > 3. Decrease in time required to setup the forms pages
> > any other comments are welcome.
> >
> 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.

Both this class and Manuel Lemos' form generation class (from
phpclasses.org) will create beautiful forms for you. However, you may
find that the amount of [repetitive] typing you do will be equivalent or
greater than simply creating the form by hand.

The best solution would probably be a form you fill out which asks you
about all the fields you want, and then generates the code to paint the
form. There are commercial solutions which do this, and some (not that
great) free solutions. I'm working on one myself, which will eventually
be a sourceforge/freshmeat project.

Hi Paul.

This sounds Great. Thanks for the advise. Just as a matter of interest do
you know the location / path to Jay's class? I tried searching the archives
but couldn't find it/

Thanks
Angelo



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms validation and creation- easier solution?

[Paul M Foster]

On Wed, May 20, 2009 at 10:08:12AM +0300, Olexandr Heneralov wrote:

> 
> 2009/5/20 Angelo Zanetti 
> 
> > 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. Validation of specific fields within the forms (server side not JS)
> >
> > 3. Decrease in time required to setup the forms pages
> > any other comments are welcome.
> >
> 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.

Both this class and Manuel Lemos' form generation class (from
phpclasses.org) will create beautiful forms for you. However, you may
find that the amount of [repetitive] typing you do will be equivalent or
greater than simply creating the form by hand.

The best solution would probably be a form you fill out which asks you
about all the fields you want, and then generates the code to paint the
form. There are commercial solutions which do this, and some (not that
great) free solutions. I'm working on one myself, which will eventually
be a sourceforge/freshmeat project.

Paul

-- 
Paul M. Foster

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms validation and creation- easier solution?

[Jay Blanchard]

[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

Re: [PHP] Forms validation and creation- easier solution?

[Olexandr Heneralov]

Hi!
No, you should not use all the framework.
You can use just a class - Zend_Form (
http://framework.zend.com/manual/en/zend.form.quickstart.html).


2009/5/20 Angelo Zanetti 

>
>
>
>  --
>
> *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 even the demo showing how to do this task
> Best regards,
> Alex.
>
>
>
> Thanks Alex. But would that mean that I need to implement the entire
> Framework or can I just use the class to incorporate into our new projects
> (bespoke applications – custom developed).
>
> Looking forward to your reply!
>
> Angelo
>
> 2009/5/20 Angelo Zanetti 
>
> 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. Validation of specific fields within the forms (server side not JS)
>
> 3. Decrease in time required to setup the forms pages
>
> any other comments are welcome.
>
>
>
> Thanks in advance
>
> Angelo
>
>
> Elemental
> http://www.elemental.co.za <http://www.elemental.co.za/>
>
> Dynamic Web and Mobile Solutions
>
>
>
>
>
>

RE: [PHP] Forms validation and creation- easier solution?

[Angelo Zanetti]

 

 

  _  

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
even the demo showing how to do this task
Best regards,
Alex.

 

Thanks Alex. But would that mean that I need to implement the entire
Framework or can I just use the class to incorporate into our new projects
(bespoke applications - custom developed).

Looking forward to your reply!

Angelo

2009/5/20 Angelo Zanetti 

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. Validation of specific fields within the forms (server side not JS)

3. Decrease in time required to setup the forms pages

any other comments are welcome.



Thanks in advance

Angelo


Elemental
http://www.elemental.co.za <http://www.elemental.co.za/>

Dynamic Web and Mobile Solutions






 

Re: [PHP] Forms validation and creation- easier solution?

[Olexandr Heneralov]

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 

> 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. Validation of specific fields within the forms (server side not JS)
>
> 3. Decrease in time required to setup the forms pages
>
> any other comments are welcome.
>
>
>
> Thanks in advance
>
> Angelo
>
>
> Elemental
> http://www.elemental.co.za 
>
> Dynamic Web and Mobile Solutions
>
>
>
>
>
>

[PHP] Forms validation and creation- easier solution?

[Angelo Zanetti]

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. Validation of specific fields within the forms (server side not JS)

3. Decrease in time required to setup the forms pages

any other comments are welcome.

 

Thanks in advance

Angelo


Elemental
http://www.elemental.co.za  

Dynamic Web and Mobile Solutions

 

 

Re: [PHP] php forms - select menu selected behavior

[Ashley Sheridan]

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
> > iteration, if there's a match, then add selected code so the category is
> > prechosen. More code (not included) does the saving and all that, I've check
> > phpmyadmin. But when the page submits, the old category appears in the drop
> > down as selected. If I leave the page and come back it's fine, it's just
> > right after it is saved. The form script is being used on itself, in that
> > there is only one file for the form, the submission, etc. All of the other
> > input elements will load the data after being saved, is it something
> > specific to dropdowns, or it is the way the code is being instatiated?
> > 
> > All help is much appreciated. Please let me know if anymore info is needed.
> > 
> 
> //MAKE CATEGORIES DROPDOWN
> 
> $catlist1 = "";
> 
> // read product
> $catmatch = "SELECT prod_cat0 FROM product WHERE dbi='$dbi';";
> $catresult = mysql_query($catmatch);
> $catquery = mysql_fetch_array($catresult);
> 
> // read categories
> $sql = "SELECT category FROM categories ORDER BY category;";
> $result = mysql_query($sql);
> while ($col2 = mysql_fetch_array($result)) {
> 
>   $id = $col2["category"];
> 
>   if ($id == $catquery['prod_cat0']){
> 
>   $catlist1 .= " selected=\"selected\">$id";
> 
>   }   else {
> 
>   $catlist1 .= "$id";
> 
>   }
> 
> }
> 
> > 
> > to instantiate 
> > 
> 
> The only data you need from table product is the column prod_cat0, from
> table categories it's category, so you should read only the needed data
> instead of using * for better performance.
> 
> Take the SQL and verify if it returns what you want it to return then.
> 
I tend to do my loops like this:

while ($col2 = mysql_fetch_array($result))
{
$id = $col2["category"];
$selected =($id == $catquery['prod_cat0'])?'selected="selected"':'';

$catlist1 .= "$id";
}

Just looks a little neater. 'Course, you could remove the $id line and
chuck the value straight into the short if statement there.


Ash
www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php forms - select menu selected behavior

[Marcus Gnaß]

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 category is
> prechosen. More code (not included) does the saving and all that, I've check
> phpmyadmin. But when the page submits, the old category appears in the drop
> down as selected. If I leave the page and come back it's fine, it's just
> right after it is saved. The form script is being used on itself, in that
> there is only one file for the form, the submission, etc. All of the other
> input elements will load the data after being saved, is it something
> specific to dropdowns, or it is the way the code is being instatiated?
> 
> All help is much appreciated. Please let me know if anymore info is needed.
> 

//MAKE CATEGORIES DROPDOWN

$catlist1 = "";

// read product
$catmatch = "SELECT prod_cat0 FROM product WHERE dbi='$dbi';";
$catresult = mysql_query($catmatch);
$catquery = mysql_fetch_array($catresult);

// read categories
$sql = "SELECT category FROM categories ORDER BY category;";
$result = mysql_query($sql);
while ($col2 = mysql_fetch_array($result)) {

$id = $col2["category"];

if ($id == $catquery['prod_cat0']){

$catlist1 .= "$id";

}   else {

$catlist1 .= "$id";

}

}

> 
> to instantiate 
> 

The only data you need from table product is the column prod_cat0, from
table categories it's category, so you should read only the needed data
instead of using * for better performance.

Take the SQL and verify if it returns what you want it to return then.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] php forms - select menu selected behavior

[Troy Oltmanns]

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 code (not included) does the saving and all that, I've check
phpmyadmin. But when the page submits, the old category appears in the drop
down as selected. If I leave the page and come back it's fine, it's just
right after it is saved. The form script is being used on itself, in that
there is only one file for the form, the submission, etc. All of the other
input elements will load the data after being saved, is it something
specific to dropdowns, or it is the way the code is being instatiated?

All help is much appreciated. Please let me know if anymore info is needed.

//MAKE CATEGORIES DROPDOWN
$sql="SELECT * FROM categories ORDER BY category";

$catmatch="SELECT * FROM product WHERE dbi='$dbi'";
$catresult=mysql_query($catmatch);
$catquery=mysql_fetch_array($catresult);
//for($a=0;$a".$id."";
  }
else {
$catlist1.="".$id."";
  }

}

to instantiate 

[PHP] Re: Self-Process php forms or not?

[Manuel Lemos]

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 instead of
> another. What are the main advantages?

You may want to watch this tutorial video that explains why presenting
and processing a form with a single script is a better solution.

http://www.phpclasses.org/browse/video/1/package/1/section/usage.html

Basically if you use the same script, if the form has invalid fields,
you can present the form with the previously submitted values.


-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

Thanks to all for your replies. 
I'm more elucidated about the possibilities now. I have seen here a lot of
keywords to start digging. :)

Thanks once again,
Márcio

> -Original Message-
> From: Tony Marston [mailto:t...@marston-home.demon.co.uk]
> Sent: sexta-feira, 24 de Abril de 2009 14:20
> 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
> script
> to use separate components for the presentation, business and data
> access
> layers.
> 
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
> 
> ""MEM""  wrote in message
> news:002b01c9c4dd$08569bc0$1903d3...@com...
> > 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 (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 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 have to
> change
> > only
> > one file instead of two.
> >
> > SanTa
> 
> 
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Self-Process php forms or not?

[Tony Marston]

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 
back to the server for validation and updating. By dealing with both the GET 
and POST in a single script it means that you don't have to redirect to a 
different script if you have to redisplay the data because of invalid use 
input.


--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org


""MEM""  wrote in message 
news:002301c9c4d9$03515920$09f40b...@com...

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 instead of
another. What are the main advantages?



Regards,
Márcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[Tony Marston]

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 script 
to use separate components for the presentation, business and data access 
layers.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

""MEM""  wrote in message 
news:002b01c9c4dd$08569bc0$1903d3...@com...
> 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 (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 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 have to change
> only
> one file instead of two.
>
> SanTa




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[HostWare Kft.]

Well, if you keen on separating business from presentation (which is usually 
a good practice), you can always do this:




So you can call in fact the processing page, the real presentation can be in 
another PHP file, as well as the processing functions. Of course, instead of 
PrintForm() you can actually implant the real HTML code.
And by the way, if you keep the form and the processing parts in one file, 
and create the form like this:



you can name your file as you want, it will work without rewriting the page.

SanTa

- Original Message - 
From: "MEM" 
To: "'Sándor Tamás (HostWare Kft.)'" ; 
"'PHP-General List'" 

Sent: Friday, April 24, 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 (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 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 have to change
only
one file instead of two.

SanTa




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[Jay Blanchard]

[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: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[Bob McConnell]

When you have it all in one file, the first thing you do is check to see if 
this request was submitted from the form. If not, you send the blank form. If 
it was, you validate all of the data. When a validation fails, you add error 
messages and resend the form with any fields that passed the validation already 
filled in. When validation succeeds, process and move on. No muss, no fuss.

Bob McConnell

-Original Message-
From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu] 
Sent: Friday, April 24, 2009 8:53 AM
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 have to change only 
one file instead of two.

SanTa

- Original Message - 
From: "MEM" 
To: "'PHP-General List'" 
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 to another .php page.

Can anyone point me some resources about this. Why using one instead of
another. What are the main advantages?



Regards,
Márcio


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Self-Process php forms or not?

[MEM]

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 (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 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 have to change
> only
> one file instead of two.
> 
> SanTa



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Self-Process php forms or not?

[HostWare Kft.]

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 have to change only 
one file instead of two.


SanTa

- Original Message - 
From: "MEM" 

To: "'PHP-General List'" 
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 to another .php page.

Can anyone point me some resources about this. Why using one instead of
another. What are the main advantages?



Regards,
Márcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Self-Process php forms or not?

[MEM]

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 instead of
another. What are the main advantages?
 
 
 
Regards,
Márcio

Re: [PHP] forms and php

[Richard Lynch]

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 into $_POST / $_GET

Ah.

Did you remember to use method="post" in your FORM tag?... :-)

On Thu, January 24, 2008 2:34 am, Mark Pashia wrote:
> 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 along. If I use the submit
> button,
> everything works perfectly. It seems that other forms on the web work
> with
> the enter key just fine, so I am probably doing something to cause
> this yet
> I don't know what.
>
>
>
> I am hosted at hostgator.com and it has php version 4.4.4 and mySQL
> version
> 4.1.22-standard.
>
>
>
> Thanks, Mark Pashia
>
>


-- 
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

Re: [PHP] forms and php

[Nathan Nobbe]

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 just fine, so I am probably doing something to cause this
> yet
> I don't know what.


what does the html look like?
i did a quick little experiment
http://nathan.moxune.com/exampleForm.php
and found if the type attribute of the input tag,
used for the submission button, was 'submit',
the enter key would not submit the form.  however,
if the value of the type attribute was 'button', pressing
the enter button would submit the form.

-nathan

Re: [PHP] forms and php

[Jochem Maas]

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 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 just fine, so I am probably doing something to cause this yet
I don't know what.


seem?

try the following line at the top of your submit script to see what is posted:

var_dump($_GET, $_POST);



 


I am hosted at hostgator.com and it has php version 4.4.4 and mySQL version
4.1.22-standard.

 


Thanks, Mark Pashia




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] forms and php

[Mark Pashia]

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 along. If I use the submit button,
everything works perfectly. It seems that other forms on the web work with
the enter key just fine, so I am probably doing something to cause this yet
I don't know what.

 

I am hosted at hostgator.com and it has php version 4.4.4 and mySQL version
4.1.22-standard.

 

Thanks, Mark Pashia

Re: [PHP] forms class

[Robert Cummings]

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 $curPostKey => $curPostVal) {
>   $curPostKey = forms::CleanInput($curPostVal);

That should probably be something along the lines:

$_POST[$curPostKey] = forms::CleanInput( $curPostVal );

>   }
>   }
>   // Debug
>   print_r($_POST);
>   }
> 
>   // Clean XSS
>   function CleanInput($UserInput) {
>   $allowedtags =  
> "";
>   $notallowedattribs = array("@javascript:|onclick|ondblclick| 
> onmousedown|onmouseup"
>   ."|onmouseover|onmousemove|onmouseout|onkeypress|onkeydown| 
> [EMAIL PROTECTED]");
>   $changexssto = '';
>   $UserInput = preg_replace($notallowedattribs, $changexssto,  
> $UserInput);
>   $UserInput = strip_tags($text, $allowedtags);
>   $UserInput = nl2br($UserInput);
>   return $this->UserInputClean;

WTF? BAD MONKEY!!! This function is called statically and so $this is
NOT available. You probably meant to do the following though:

return $UserInput;

>   }
> }

Other comments for you...

Don't use hard tabs, use spaces (preferrably 4). Switch to vertically
aligned braces it makes it easier for me to read your code ;)

if( $foo )
{
}

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

[PHP] forms class

[nihilism machine]

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) {
$curPostKey = forms::CleanInput($curPostVal);
}
}
// Debug
print_r($_POST);
}

// Clean XSS
function CleanInput($UserInput) {
		$allowedtags =  
"";
		$notallowedattribs = array("@javascript:|onclick|ondblclick| 
onmousedown|onmouseup"
		."|onmouseover|onmousemove|onmouseout|onkeypress|onkeydown| 
[EMAIL PROTECTED]");

$changexssto = '';
		$UserInput = preg_replace($notallowedattribs, $changexssto,  
$UserInput);

$UserInput = strip_tags($text, $allowedtags);
$UserInput = nl2br($UserInput);
return $this->UserInputClean;
}
}

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Page not displayed/Forbidden on PHP forms

[Andrés Robinet]

I would check the follwing:
- If the problematic host has apache's mod_security enabled. The system
administrator can tell you if mod_security is disallowing some of the input
(which might cause the "403 forbidden").
- PHP.INI parameters max_execution_time, max_input_time and
max_input_nesting_level (more info is at the online php manual) you can
query these values through ini_get, and you can set them through .htaccess
files, e.g. "php_value max_execution_time 300" (if the hosting company
allows their use).
- Call ignore_user_abort at the top of the processing script (CAREFULLY read
the notes for that function) and query the value returned by
connection_status, or connection_aborted (maybe create a log file for the
returnded values through successive requests to keep track of any issue)
- Check what (cache) headers the server or your processing script is sending
to the browser.
- Also, if $_REQUEST processing is a time consuming operation and you use
ob_start, ob_end_flush, etc you can try flushing the output buffer from time
to time (if your programming logic allows for that).

Well, this is quite a list... but if they are getting "403 forbidden" it
might be an issue with the server configuration (such as a highly restricted
mod_security configuration), rather than server performance or speed. Hope
that helps.

Ohh, by the way, if you can send the culprit URL to us for testing it will
help a lot (BUT DON'T DO THAT if this is a private system, or a system for
which you don't want to get any additional traffic).

Rob

Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308
| TEL 954-607-4207 | FAX 954-337-2695 | 
Email: [EMAIL PROTECTED]  | MSN Chat: [EMAIL PROTECTED]  |  SKYPE:
bestplace |  Web: 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 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 is not consistent. (ie. sometimes the forms work fine,
> sometimes
> they deliver the error). The problem only seems to have occurred with
> users on IE and mostly who are a significant distance from the server.
> 
> This does not seem to be occurring at the other host.
> 
> The problem host is not being responsive about solving the problem
> (which will cost them our business). Could this be a PHP time-out
> issue?
> Something in the PHP settings or is it likely a server issue or
> something else.
> 
> Your expertise - as always - is much appreciated!
> 
> Jeff
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Page not displayed/Forbidden on PHP forms

[Jeffrey]

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 is not consistent. (ie. sometimes the forms work fine, sometimes 
they deliver the error). The problem only seems to have occurred with 
users on IE and mostly who are a significant distance from the server.


This does not seem to be occurring at the other host.

The problem host is not being responsive about solving the problem 
(which will cost them our business). Could this be a PHP time-out issue? 
Something in the PHP settings or is it likely a server issue or 
something else.


Your expertise - as always - is much appreciated!

Jeff

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] need to alter FROM address when sending with PHP forms

[Richard Lynch]

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
> problem or apache problem (or even a sendmail problem for that matter)
> so I am asking both lists for help. I have tried lookup up apache docs
> and PHP docs to alter the FROM: address to no avail. No matter what I
> and my programmer try in PHP or apache the from address stays coming
> from the user apache runs as @webserver.domain.com (obviously I mean
> the FQDN of the server). We would like to be able to alter the FROM:
> address per form as we should be able to do in PHP. If there is a PHP
> fix for this any help would be appreciated. If this is definitely NOT
> a PHP problem, please let me know and I will move on from there. Thank
> you.

You would need the mail() call to specify the From: and Reply-to:
headers:
mail('[EMAIL PROTECTED]', 'test', 'test, "From:
[EMAIL PROTECTED]: [EMAIL PROTECTED]");

Your mail software may also be REJECTING the over-riding of those
headers if the PHP user is not "trusted" enough by the mail software.

E.g., maybe you need to add the User setting of httpd.conf to the
trusted user list in sendmail.cf

Try sending email different ways to localize the trouble.

Use 'mail' from the command line as yourself.
'su' to the PHP User and then try 'mail' from command line again.

This may help explain where the problem lies.

-- 
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/browse/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

RE: [PHP] need to alter FROM address when sending with PHP forms

[Jim Moseby]

> 
> 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 matter)
> so I am asking both lists for help. I have tried lookup up apache docs
> and PHP docs to alter the FROM: address to no avail. No matter what I
> and my programmer try in PHP or apache the from address stays coming
> from the user apache runs as @webserver.domain.com (obviously I mean
> the FQDN of the server). We would like to be able to alter the FROM:
> address per form as we should be able to do in PHP. If there is a PHP
> fix for this any help would be appreciated. If this is definitely NOT
> a PHP problem, please let me know and I will move on from there. Thank
> you.


You will need to set the From: header.  I use the awesome phpmailer class
that makes sending complex emails really easy.

http://phpmailer.sourceforge.net/

JM

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] need to alter FROM address when sending with PHP forms

[Robert Cummings]

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
> problem or apache problem (or even a sendmail problem for that matter)
> so I am asking both lists for help. I have tried lookup up apache docs
> and PHP docs to alter the FROM: address to no avail. No matter what I
> and my programmer try in PHP or apache the from address stays coming
> from the user apache runs as @webserver.domain.com (obviously I mean
> the FQDN of the server). We would like to be able to alter the FROM:
> address per form as we should be able to do in PHP. If there is a PHP
> fix for this any help would be appreciated. If this is definitely NOT
> a PHP problem, please let me know and I will move on from there. Thank
> you.

Have him set the "From:" header when sending the email.

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] need to alter FROM address when sending with PHP forms

[Dylan Bouterse]

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 matter)
so I am asking both lists for help. I have tried lookup up apache docs
and PHP docs to alter the FROM: address to no avail. No matter what I
and my programmer try in PHP or apache the from address stays coming
from the user apache runs as @webserver.domain.com (obviously I mean
the FQDN of the server). We would like to be able to alter the FROM:
address per form as we should be able to do in PHP. If there is a PHP
fix for this any help would be appreciated. If this is definitely NOT
a PHP problem, please let me know and I will move on from there. Thank
you.

Dylan

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms and destroying values

[Beauford]

Thanks, a little confusing there. You would think though that once the info
is transmitted by the browser it would be forgotten by the browser. Anyway,
I do have a work around, and since PHP can't do anything about what the
browser does, this will have to suffice.

Thanks all.

> -Original Message-
> From: Stut [mailto:[EMAIL PROTECTED] 
> Sent: January 12, 2007 11:38 AM
> To: Beauford
> Cc: 'PHP'
> Subject: Re: [PHP] Forms and destroying values
> 
> 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 that's exactly what it is - a work 
> > around. I am also still confused as to why giving them a 
> null value doesn't work.
> >   
> 
> You need to get it clear in your head when PHP is sending 
> data to the client and when it is not. Your assumption is 
> basically that the data in $_POST is actually *connected* to 
> the form displayed in the browser. 
> This is not the case. When you change the contents of $_POST 
> it has no effect on what the browser displays or uses since 
> it's not actually sent to the browser unless you specifically 
> output it in the form of a, erm, form.
> 
> When the user hits refresh, or uses the back button it is up 
> to the browser what it does. In the case of refresh, if the 
> page being refreshed was created in response to a form being 
> submitted the browser will ask the user if they want to 
> resubmit the data. When using the back button the browser 
> will usually use its cached copy of the page rather than 
> hitting the server 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 a redirect to the browser to a confirmation 
> >> page, so the browser remembers the page redirected to and 
> completely 
> >> ignores the page that made the redirection so that neither 
> a refresh 
> >> nor going back to it can repeat the operation.
> >>
> >> So, if the database update has been succesful, use the
> >> header() function to send a 'location' header along with enough 
> >> arguments in the URL to display a significant confirmation 
> message  
> >> but make sure that it is different from
> >> the URL that makes the database update.   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" 
> >> Sent: Friday, January 12, 2007 9:27 AM
> >> Subject: [PHP] Forms and destroying values
> >>
> >>
> >> 
> >>> 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,
> >> 
> >>> $var2,
> >>> $etc). I have also tried unset($_POST['var1'], $_POST['var2'], 
> >>> $_POST['etc']). I even got deperate and tried $var = ""; or
> >>>   
> >> $_POST['var']
> >> 
> >>> =
> >>> "";
> >>>
> >>> What do I need to do to get rid of these values??? 
> >>>   
> >> Obviously I am missing
> >> 
> >>> something.
> >>>
> >>> Any help is appreciated.
> >>>
> >>> Thanks
> >>>
> >>> --
> >>> PHP General Mailing List (http://www.php.net/) To unsubscribe, 
> >>> visit: http://www.php.net/unsub.php
> >>>
> >>>   
> >> --
> >> PHP General Mailing List (http://www.php.net/) To 
> unsubscribe, visit: 
> >> http://www.php.net/unsub.php
> >>
> >>
> >>
> >> 
> >
> >   
> 
> 
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms and destroying values

[Satyam]

As many have already replied to your question, what happens is that upon a 
refresh the browser is resending the original post variables again.


The unset() does work, from the point of the unset() to the end of the 
script (when all variables except for session variables are unset), PHP will 
have completely forgotten about those values.   But that does not affect the 
browser at all.


On a refresh the browser will send the information again, unless it is 
tricked via a redirection command to believe the URL used for the post is 
obsolete.  Then, what the browser will do is to remember the URL it was 
redirected to and drop the 'obsolete' URL so, when the user does a refresh, 
the browser will be smart enough to go to the 'updated' (the redirected-to) 
URL instead of the original 'obsolete' one and thus will get the 
confirmation page again, but without passing through the database 
transaction.


Satyam



- Original Message - 
From: "Beauford" <[EMAIL PROTECTED]>

To: "'PHP'" 
Sent: Friday, January 12, 2007 5:23 PM
Subject: RE: [PHP] Forms and destroying values




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 that's exactly what it is - a work around. I am also still
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, 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 the
redirection so that neither a refresh nor going back to it
can repeat the operation.

So, if the database update has been succesful, use the
header() function to send a 'location' header along with
enough arguments in the URL to display a significant
confirmation message  but make sure that it is different from
the URL that makes the database update.   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" 
Sent: Friday, January 12, 2007 9:27 AM
Subject: [PHP] Forms and destroying values


> 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,
> $var2,
> $etc). I have also tried unset($_POST['var1'], $_POST['var2'],
> $_POST['etc']). I even got deperate and tried $var = ""; or
$_POST['var']
> =
> "";
>
> What do I need to do to get rid of these values???
Obviously I am missing
> something.
>
> Any help is appreciated.
>
> Thanks
>
> -- 
> PHP General Mailing List (http://www.php.net/)

> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms and destroying values

[Németh Zoltán]

2007. 01. 12, péntek keltezéssel 11.43-kor Robert Cummings ezt írta:
> On Fri, 2007-01-12 at 17:36 +0100, Németh Zoltán wrote:
> > Beauford,
> > 
> > The unset() function is for session variables, which are remembered by
> > the server even after the script finished running, that's their
> > purpose. Your variables are not session variables but normal
> > variables.
> 
> Wrong! Please go read the manual for unset()...
> 
> http://www.php.net/manual/en/function.unset.php
> 
> Cheers,
> Rob.

You're right, sorry, I remembered incorrectly.

Zoltán Németh

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms and destroying values

[Robert Cummings]

On Fri, 2007-01-12 at 17:36 +0100, Németh Zoltán wrote:
> Beauford,
> 
> The unset() function is for session variables, which are remembered by
> the server even after the script finished running, that's their
> purpose. Your variables are not session variables but normal
> variables.

Wrong! Please go read the manual for unset()...

http://www.php.net/manual/en/function.unset.php

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms and destroying values

[Németh Zoltán]

Beauford,

I think you miss the point. The point is that the values are not
remembered by the server at all (after the script finished running), so
you don't have to explicitely destroy them. The unset() function is for
session variables, which are remembered by the server even after the
script finished running, that's their purpose. Your variables are not
session variables but normal variables.

BUT they are remembered by the browser, which may send them again to
your script, that's why you get the same values again. So you have to
apply some workaround to make the browser not send them again.

Greets,
Zoltán Németh

2007. 01. 12, péntek keltezéssel 11.23-kor Beauford ezt írta:
>  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 that's exactly what it is - a work around. I am also still
> 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, 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 the 
> > redirection so that neither a refresh nor going back to it 
> > can repeat the operation.
> > 
> > So, if the database update has been succesful, use the 
> > header() function to send a 'location' header along with 
> > enough arguments in the URL to display a significant 
> > confirmation message  but make sure that it is different from 
> > the URL that makes the database update.   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" 
> > Sent: Friday, January 12, 2007 9:27 AM
> > Subject: [PHP] Forms and destroying values
> > 
> > 
> > > 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, 
> > > $var2,
> > > $etc). I have also tried unset($_POST['var1'], $_POST['var2'],
> > > $_POST['etc']). I even got deperate and tried $var = ""; or 
> > $_POST['var'] 
> > > =
> > > "";
> > >
> > > What do I need to do to get rid of these values??? 
> > Obviously I am missing
> > > something.
> > >
> > > Any help is appreciated.
> > >
> > > Thanks
> > >
> > > -- 
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > 
> > 
> > -- 
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> > 
> > 
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Forms and destroying values

[Robert Cummings]

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 that's exactly what it is - a work around. I am also still
> confused as to why giving them a null value doesn't work.

Because it's not PHP that won't destroy the values, it's the browser
resubmitting the values. Thus PHP needs to work around the browser's
resubmission of the form.

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Forms and destroying values

[Stut]

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 that's exactly what it is - a work around. I am also still
confused as to why giving them a null value doesn't work.
  


You need to get it clear in your head when PHP is sending data to the 
client and when it is not. Your assumption is basically that the data in 
$_POST is actually *connected* to the form displayed in the browser. 
This is not the case. When you change the contents of $_POST it has no 
effect on what the browser displays or uses since it's not actually sent 
to the browser unless you specifically output it in the form of a, erm, 
form.


When the user hits refresh, or uses the back button it is up to the 
browser what it does. In the case of refresh, if the page being 
refreshed was created in response to a form being submitted the browser 
will ask the user if they want to resubmit the data. When using the back 
button the browser will usually use its cached copy of the page rather 
than hitting the server 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 a redirect to the browser 
to a confirmation page, so the browser remembers the page 
redirected to and completely ignores the page that made the 
redirection so that neither a refresh nor going back to it 
can repeat the operation.


So, if the database update has been succesful, use the 
header() function to send a 'location' header along with 
enough arguments in the URL to display a significant 
confirmation message  but make sure that it is different from 
the URL that makes the database update.   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" 
Sent: Friday, January 12, 2007 9:27 AM
Subject: [PHP] Forms and destroying values




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, 


$var2,
$etc). I have also tried unset($_POST['var1'], $_POST['var2'],
$_POST['etc']). I even got deperate and tried $var = ""; or 
  
$_POST['var'] 


=
"";

What do I need to do to get rid of these values??? 
  

Obviously I am missing


something.

Any help is appreciated.

Thanks

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

  

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php






  


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php