php-general Digest 14 Feb 2007 12:54:10 -0000 Issue 4625
Topics (messages 248808 through 248840):
Re: print() or echo
248808 by: Robert Cummings
248809 by: tg-php.gryffyndevelopment.com
248811 by: tg-php.gryffyndevelopment.com
248815 by: Satyam
how do I just escape double quotes within a string?
248810 by: blackwater dev
248813 by: Eric Butera
248814 by: tg-php.gryffyndevelopment.com
Re: round to nearest 500?
248812 by: tedd
248816 by: tg-php.gryffyndevelopment.com
248817 by: Tim
248818 by: tg-php.gryffyndevelopment.com
248820 by: Jon Anderson
248821 by: tg-php.gryffyndevelopment.com
248822 by: tg-php.gryffyndevelopment.com
248823 by: Satyam
248824 by: tg-php.gryffyndevelopment.com
failed to upload files into directory named "bin"
248819 by: Yeni Setiawan
Redisplay file name on failed upload
248825 by: Miles Thompson
248826 by: Brad Fuller
248827 by: Jochem Maas
248828 by: Jochem Maas
248829 by: Miles Thompson
How to upload files up to 40MB with a html post form?
248830 by: Mauricio Muriel
248831 by: Jay Blanchard
248840 by: David Blanco
Re: Filtering _REQUEST.. Why is this bad?
248832 by: Richard Lynch
248836 by: J R
Re: PHP or Bridge (card game)
248833 by: Richard Lynch
Getting mysql_query results into an array
248834 by: Skip Evans
248835 by: Richard Lynch
248837 by: Skip Evans
248838 by: Roman Neuhauser
248839 by: Robert Cummings
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Tue, 2007-02-13 at 19:19 +0330, Danial Rahmanzadeh wrote:
> is it true that echo is a bit faster than print()? in general, when we don't
> need a return value, which one is better to choose?
Yes, echo is faster than print. I would suggest echo over print since it
is shorter and faster :)
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. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
As referenced in the manual ( http://us2.php.net/manual/en/function.echo.php ),
check out this url:
http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40
Short story, there is a difference, but the speed difference is negligable.
If anyone cares, I prefer echo too. Not sure why. Shorter to type, old habits
(coming more from a scripting background than a "real programming" background
even though I've done some of that too), who knows? Part of it may be the
desire to have my code do what it needs to do and nothing more. Print returns
a value, which I don't use, so why would I want it to do that? That's a
little anal retentive, but every little bit helps I suppose, even if it's a
negligable difference.
-TG
= = = Original message = = =
On Tue, 2007-02-13 at 19:19 +0330, Danial Rahmanzadeh wrote:
> is it true that echo is a bit faster than print()? in general, when we don't
> need a return value, which one is better to choose?
Yes, echo is faster than print. I would suggest echo over print since it
is shorter and faster :)
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. |
`------------------------------------------------------------'
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
"negligible".. blarg spelling. :)
= = = Original message = = =
As referenced in the manual ( http://us2.php.net/manual/en/function.echo.php ),
check out this url:
http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40
Short story, there is a difference, but the speed difference is negligable.
If anyone cares, I prefer echo too. Not sure why. Shorter to type, old habits
(coming more from a scripting background than a "real programming" background
even though I've done some of that too), who knows? Part of it may be the
desire to have my code do what it needs to do and nothing more. Print returns
a value, which I don't use, so why would I want it to do that? That's a
little anal retentive, but every little bit helps I suppose, even if it's a
negligable difference.
-TG
= = = Original message = = =
On Tue, 2007-02-13 at 19:19 +0330, Danial Rahmanzadeh wrote:
> is it true that echo is a bit faster than print()? in general, when we don't
> need a return value, which one is better to choose?
Yes, echo is faster than print. I would suggest echo over print since it
is shorter and faster :)
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. |
`------------------------------------------------------------'
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
echo is slightly faster than print and it takes multiple arguments so
instead of:
echo '<p>' . $test . '</p>';
you can do
echo '<p>' , $test , '</p>';
which should be faster, and I say 'should' just because as print should be
slower because it has to go into the trouble of setting up a return value,
so avoiding doing a concatenation first and then output the whole thing by
just streaming each of the pieces to the output straight away should be
faster, though string operations are so optimized as to be neglig....
well, you can't tell the difference.
Satyam
----- Original Message -----
From: "Danial Rahmanzadeh" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, February 13, 2007 4:49 PM
Subject: [PHP] print() or echo
is it true that echo is a bit faster than print()? in general, when we
don't
need a return value, which one is better to choose?
Cheers,
Danial Rahmanzadeh
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.17.37/682 - Release Date: 12/02/2007
13:23
--- End Message ---
--- Begin Message ---
If I use add slashes, it strips everything, I just want to replace all the
double quotes with slash double quote but this, of course, throws errors:
str_replace(""","\"",$code);
Thanks!
--- End Message ---
--- Begin Message ---
On 2/13/07, blackwater dev <[EMAIL PROTECTED]> wrote:
If I use add slashes, it strips everything, I just want to replace all the
double quotes with slash double quote but this, of course, throws errors:
str_replace(""","\"",$code);
Thanks!
Try this
$string = 'Hello "person." How are you?';
var_dump($string);
var_dump(str_replace('"', '\"', $string));
Notice you can use single and double quotes in the same string.
--- End Message ---
--- Begin Message ---
You could use addslashes():
http://us3.php.net/manual/en/function.addslashes.php
Or, the code you mentioned below, could be rewritten like:
str_replace("\"","\\"",$code);
or
str_replace('"','\"',$code);
And if you're doing it for a MySQL query call, then you want to use
mysql-real-escape-string() instead of all that mess above:
http://www.php.net/manual/en/function.mysql-real-escape-string.php
What's happening with the example you gave is that you're having a conflict
with using the same type of string encloser (what's the proper word for single
and double quotes in this case? hah).
""" = "" with a dangling ". Error.
"\"" = a string containing just a double quote.
Everything inside "" is interpreted.
Everything inside '' is taken literally.
'"' = a string containing a double quote
''' = '' with a dangling ' on the end
'\'' = a string containing ' (I think.. I think this is the only exception to
no-interpretation-within-single-quotes)
Some more information on single and double quotes here:
http://us3.php.net/manual/en/language.types.string.php#language.types.string.syntax.single
-TG
= = = Original message = = =
If I use add slashes, it strips everything, I just want to replace all the
double quotes with slash double quote but this, of course, throws errors:
str_replace(""","\"",$code);
Thanks!
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
At 7:57 PM +0100 2/12/07, Marc Weber wrote:
On Mon, 12 Feb 2007 18:02:41 +0100, <[EMAIL PROTECTED]> wrote:
Is there an easy way in php to round to the nearest 500?
Yeah
$rouned = round($val/500) * 500;
I've always questioned the round() function.
I believe it has a downward bias, am I wrong?
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
For downward rounding, you'd always want to use floor() and use ceil() for
rounding up. round() rounds up on a 5, down on a 4 and below.
Example:
echo round(141.074, 2); // 141.07
echo round(141.065, 2); // 141.07
I thought round() (or maybe it was a rounding function in another language or
something like Excel) did the supposed accounting trick of rounding up and down
depending on the next "significant digit" or whatever you'd call it.
For example, 141.075 might round to 141.08 (because 7 is odd) and 141.065 might
round to 141.06 (because 6 is even). Or vice versa. Supposedly this is an
accounting trick that ultimatley works out in the end for proper rounding of
money values. Guess our PHP 4.3.4 here doesn't do that though.
-TG
= = = Original message = = =
At 7:57 PM +0100 2/12/07, Marc Weber wrote:
>On Mon, 12 Feb 2007 18:02:41 +0100, <[EMAIL PROTECTED]> wrote:
>
>>Is there an easy way in php to round to the nearest 500?
>Yeah
>$rouned = round($val/500) * 500;
I've always questioned the round() function.
I believe it has a downward bias, am I wrong?
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
<snip>
> Supposedly this is an accounting trick that
> ultimatley works out in the end for proper rounding of money
> values.
Yeah works out for who? Bet it doesn't for the guy paying :P
--- End Message ---
--- Begin Message ---
hah yeah, always worth a little skepticism, but it seemed to make some kind of
sense. If you always round up or always round down, that's obviously not
right and you end up losing potentially a lot of money or over-estimating the
money involved.
Founding up for 5 through 9 and down for 0 through 4 seems like it makes some
kind of sense, but apparently it doesn't work out that way.
I'm sure someone out there knows what I'm talking about (it might be the first
time, but I know I'm not making this up hah), but rounding 0.75 up to 0.8 and
0.65 down to 0.6 (or vice versa) is supposed to be more accurate or at least
leads to fewer anomalies.
Someone feel like writing a quick script that generates random numbers and does
the rounding based on these two ideas (doing it the 'hard way') and see how
much variation there is after like 10,000 iterations? If I have time later,
I'll do it. Now I'm even more curious.
-TG
= = = Original message = = =
<snip>
> Supposedly this is an accounting trick that
> ultimatley works out in the end for proper rounding of money
> values.
Yeah works out for who? Bet it doesn't for the guy paying :P
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
[EMAIL PROTECTED] wrote:
hah yeah, always worth a little skepticism, but it seemed to make some kind of
sense. If you always round up or always round down, that's obviously not
right and you end up losing potentially a lot of money or over-estimating the
money involved.
Founding up for 5 through 9 and down for 0 through 4 seems like it makes some
kind of sense, but apparently it doesn't work out that way.
I'm sure someone out there knows what I'm talking about (it might be the first
time, but I know I'm not making this up hah), but rounding 0.75 up to 0.8 and
0.65 down to 0.6 (or vice versa) is supposed to be more accurate or at least
leads to fewer anomalies.
Someone feel like writing a quick script that generates random numbers and does
the rounding based on these two ideas (doing it the 'hard way') and see how
much variation there is after like 10,000 iterations? If I have time later,
I'll do it. Now I'm even more curious.
I wasn't aware of the accounting trick before today, but I believe I can
explain it: If your numbers are statistically random, then the above
solution will lead to an even distribution of rounding up and rounding down.
The reason is simple:
0: No rounding. It's already there. (8.0 doesn't need to be rounded to 8
- it already *is* 8.)
1-4: You round down -> 4 of 9 times you round down.
5-9: You round up -> 5 of 9 times you round up.
So you round up 11.1% more often than you round down. As a result, if
you round up when it's odd, and down when it's even, you eliminate the
11.1% difference in when you'd round up then round down.
That said, if someone were aware of the above rounding trick, it
wouldn't take someone very much effort to come up with things like "fee
structures" or "pricing structures" that could take advantage of that
scheme to force rounding errors to remain permanently in the person's favor.
I certainly hope that PHP continues to use the standard technique, and
not the "accounting trick" above. :-)
jon
--- End Message ---
--- Begin Message ---
Ok, screw work.. it's snowing out anyway (not that that makes a real difference
to doing PHP work inside), curiosity got the better of me.
btw.. the "banker" rounding code here was pulled from the round() manual page.
It's not what I read before, but it's the same concept:
function bankers_round ($moneyfloat = null)
{
$money_str = sprintf("%01.3f", round($moneyfloat, 3)); // convert to rounded
(to the nearest thousandth) string
$thous_pos = strlen($money_str)-1; // Thousandth string
position
$hundt_pos = strlen($money_str)-2; // Hundredth string
position
if ($money_str[$thous_pos] === "5") $money_str[$thous_pos] =
((int)$money_str[$hundt_pos] & 1) ? "9" : "0"; // use a bitwise test, its
faster than modulus
// The above statement assists round() by setting the thousandth position to
9 or zero if the hundredth is even or odd (respectively)
return round($money_str, 2); // Return rounded value
}
for ($i = 0; $i < 10000; $i++) {
$rand = rand() / 10000;
$round += round($rand, 2);
$banker += bankers_round($rand);
$total += $rand;
}
echo "Total: $total<br>\n";
echo "round() rounding: $round<br>\n";
echo "Banker Rounding: $banker<br>\n";
Results for one run:
Total: 1082648588.0678
round() rounding: 1082648588.52
Banker Rounding: 1082648588.21
Banker is closer in this case. Total should round to around ..88.07
Next example...
Total: 1087871577.5462
round() rounding: 1087871578.04
Banker Rounding: 1087871577.83
Banker again closer.. should be around ..77.55
Let's do 100,000 iterations now:
Total: 10769106454.867
round() rounding: 10769106456.21
Banker Rounding: 10769106456.15
Hmm. ...54.xx is a bit different than ..56.xx. Technically the banker one
is still closer, but you can see how after a while the numbers start to drift
apart if you don't (can't?) maintain the precision to keep exact values.
I definitely don't want to be an accountant when I grow up.
-TG
= = = Original message = = =
hah yeah, always worth a little skepticism, but it seemed to make some kind of
sense. If you always round up or always round down, that's obviously not
right and you end up losing potentially a lot of money or over-estimating the
money involved.
Founding up for 5 through 9 and down for 0 through 4 seems like it makes some
kind of sense, but apparently it doesn't work out that way.
I'm sure someone out there knows what I'm talking about (it might be the first
time, but I know I'm not making this up hah), but rounding 0.75 up to 0.8 and
0.65 down to 0.6 (or vice versa) is supposed to be more accurate or at least
leads to fewer anomalies.
Someone feel like writing a quick script that generates random numbers and does
the rounding based on these two ideas (doing it the 'hard way') and see how
much variation there is after like 10,000 iterations? If I have time later,
I'll do it. Now I'm even more curious.
-TG
= = = Original message = = =
<snip>
> Supposedly this is an accounting trick that
> ultimatley works out in the end for proper rounding of money
> values.
Yeah works out for who? Bet it doesn't for the guy paying :P
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
Ahh.. good call.
http://en.wikipedia.org/wiki/Rounding
Apprently it's called "banker's rounding" or "statistician's rounding" and is a
little more complicated than just looking at the odd/even of the digit being
arounded.
This is starting to get into some heavy math theory and scary stuff that I'll
leave up to people much smarter than me as far as statistical analysis goes.
I'm still suprised nobody's mentioned Superman 3/Office Space in all this.
-TG
= = = Original message = = =
I think there's a fairly good article on it on wikipedia... but it's
been a while since I read it and I don't have a link for you... sorry.
On Feb 13, 2007, at 12:32 PM, <[EMAIL PROTECTED]> <tg-
[EMAIL PROTECTED]> wrote:
> hah yeah, always worth a little skepticism, but it seemed to make
> some kind of sense. If you always round up or always round down,
> that's obviously not right and you end up losing potentially a lot
> of money or over-estimating the money involved.
>
> Founding up for 5 through 9 and down for 0 through 4 seems like it
> makes some kind of sense, but apparently it doesn't work out that way.
>
> I'm sure someone out there knows what I'm talking about (it might
> be the first time, but I know I'm not making this up hah), but
> rounding 0.75 up to 0.8 and 0.65 down to 0.6 (or vice versa) is
> supposed to be more accurate or at least leads to fewer anomalies.
>
> Someone feel like writing a quick script that generates random
> numbers and does the rounding based on these two ideas (doing it
> the 'hard way') and see how much variation there is after like
> 10,000 iterations? If I have time later, I'll do it. Now I'm even
> more curious.
>
> -TG
>
> = = = Original message = = =
>
> <snip>
>> Supposedly this is an accounting trick that
>> ultimatley works out in the end for proper rounding of money
>> values.
>
> Yeah works out for who? Bet it doesn't for the guy paying :P
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
----- Original Message -----
From: "Jon Anderson" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
hah yeah, always worth a little skepticism, but it seemed to make some
kind of sense. If you always round up or always round down, that's
obviously not right and you end up losing potentially a lot of money or
over-estimating the money involved.
Founding up for 5 through 9 and down for 0 through 4 seems like it makes
some kind of sense, but apparently it doesn't work out that way.
I'm sure someone out there knows what I'm talking about (it might be the
first time, but I know I'm not making this up hah), but rounding 0.75 up
to 0.8 and 0.65 down to 0.6 (or vice versa) is supposed to be more
accurate or at least leads to fewer anomalies.
Someone feel like writing a quick script that generates random numbers
and does the rounding based on these two ideas (doing it the 'hard way')
and see how much variation there is after like 10,000 iterations? If I
have time later, I'll do it. Now I'm even more curious.
I wasn't aware of the accounting trick before today, but I believe I can
explain it: If your numbers are statistically random, then the above
solution will lead to an even distribution of rounding up and rounding
down.
The reason is simple:
0: No rounding. It's already there. (8.0 doesn't need to be rounded to 8 -
it already *is* 8.)
1-4: You round down -> 4 of 9 times you round down.
5-9: You round up -> 5 of 9 times you round up.
That is not quite correct, there is no such 4 ninths agains 5 ninths. You
round down in the interval from 0 to0.499999999 and you round up from 0.5 to
0.9999999. If you substract the .5 from 0.99999, you get 0.4999999 so it is
about the same interval for both.
If there is any difference, and actually there is, is because any number is,
in reality, truncated, and not rounded, at some point. Depending on the
number of bits of the mantissa, it might be a long way off, but eventually,
it will happen, and that one is truncation, nor rounding, and if you repeat
any calculation involving fractional numbers, it will eventually add up to
something noticeable.
Actually, there is the further problem that computers actually use binary,
not decimal, so they cannot represent decimal numbers exactly. To offer an
example of what I'm talking about, 1/3, which results in a never ending
0.333333 is exactly 0.1 in base 3 arithmetic! Conversely, many 'round'
numbers in our decimal notation are not 'round' in binary and viceversa. So
it is all the piling of lots of rounding errors in real-life number
representations that produce the error, not the mathematics of rounding,
which actually work in an abstract world of infinitely precise number
representations (in other words, infinite bits to represent any numbers).
Satyam
So you round up 11.1% more often than you round down. As a result, if you
round up when it's odd, and down when it's even, you eliminate the 11.1%
difference in when you'd round up then round down.
That said, if someone were aware of the above rounding trick, it wouldn't
take someone very much effort to come up with things like "fee structures"
or "pricing structures" that could take advantage of that scheme to force
rounding errors to remain permanently in the person's favor.
I certainly hope that PHP continues to use the standard technique, and not
the "accounting trick" above. :-)
jon
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.17.37/682 - Release Date:
12/02/2007 13:23
--- End Message ---
--- Begin Message ---
I don't buy "zero doesn't count". But again, this is getting into serious
math. It should be good enough to say 0-4 = 0, 5-9 = 10, but if you don't keep
strict high precision throughout the whole process and round at every step,
things are going to be off no matter what. It's just a matter of being off as
little as possible (especially when it comes to money.. people are a little
touchy about that).
Don't malign zero though.. :)
See also:
Zero: The Biography of a Dangerous Idea (Paperback) by Charles Seife
-TG
= = = Original message = = =
I wasn't aware of the accounting trick before today, but I believe I can
explain it: If your numbers are statistically random, then the above
solution will lead to an even distribution of rounding up and rounding down.
The reason is simple:
0: No rounding. It's already there. (8.0 doesn't need to be rounded to 8
- it already *is* 8.)
1-4: You round down -> 4 of 9 times you round down.
5-9: You round up -> 5 of 9 times you round up.
So you round up 11.1% more often than you round down. As a result, if
you round up when it's odd, and down when it's even, you eliminate the
11.1% difference in when you'd round up then round down.
That said, if someone were aware of the above rounding trick, it
wouldn't take someone very much effort to come up with things like "fee
structures" or "pricing structures" that could take advantage of that
scheme to force rounding errors to remain permanently in the person's favor.
I certainly hope that PHP continues to use the standard technique, and
not the "accounting trick" above. :-)
jon
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
Dear all, I was just creating two upload pages,both will upload files into
directory named "bin".
./bin/ <-- directory where the files uploaded
./admin/upload.php <-- I wrote path as "../bin/"
./userupload.php <-- I wrote path as "bin/"
I was confused because ./userupload.php failed to upload while
./admin/upload.php run as expected.
Was it because the directory name "bin"? This problem solved when I rename
the directory into another name.
FYI, I'm using AppServ with PHP 4.4.1 on Windows environtment.
Does anyone have any explanation?
--
thanks,
Yeni Setiawan
--- End Message ---
--- Begin Message ---
When a file upload fails, not because of a problem with the upload itself,
is there anyway of assigning the value captured by
<input name="upldFile" type="file">
when the form is redisplayed?
The failure may not be due to a problem with the file being uploaded, but
because the user failed to complete a keywords field or some other bit of
wanted information.
Is it possible to assign form[ upldFile ] = "C:\somepath\somefile"
or
form[ upldFile ] = $_FILES['userfile']['name']
The script which does the validation is the same one which contains the
upload form. I suspect we're completely out of luck - apart from validating
with JavaScript.
Regards - Miles
--- End Message ---
--- Begin Message ---
> Is it possible to assign form[ upldFile ] = "C:\somepath\somefile"
> or
> form[ upldFile ] = $_FILES['userfile']['name']
The "value" attribute of the <input type="file"...> tag is not able to be
altered or pre-populated for obvious security reasons.
> The script which does the validation is the same one which contains the
> upload form. I suspect we're completely out of luck - apart from
> validating
> with JavaScript.
Yup.
-Brad
--- End Message ---
--- Begin Message ---
Miles Thompson wrote:
> When a file upload fails, not because of a problem with the upload itself,
> is there anyway of assigning the value captured by
>
> <input name="upldFile" type="file">
>
> when the form is redisplayed?
>
> The failure may not be due to a problem with the file being uploaded, but
> because the user failed to complete a keywords field or some other bit of
> wanted information.
>
> Is it possible to assign form[ upldFile ] = "C:\somepath\somefile"
> or
> form[ upldFile ] = $_FILES['userfile']['name']
>
> The script which does the validation is the same one which contains the
> upload form. I suspect we're completely out of luck - apart from validating
> with JavaScript.
it's a security measure that you are not able to set the value of file upload
element,
neither by filling the value attribute literally nor by using javascript.
this is because your page is not allowed access to the local filesystem ... if
you
are able to do it then your looking at a browser bug.
what you can do is place the full local path the the file in question
above/below the file upload element to help the user.
a better alternative would be to temporarily store the file in the staging area
and redisplay the form without the upload element (and inform the user the file
is
already on the server) and have the user fill everything else correctly
- once you recieve the rest of the data correctly you can pluck the
relevant file from the staging area.
another tactic would be to use a multi-page form and have the upload on the last
page, only showing the last page when everything else has been submitted
correctly.
>
> Regards - Miles
>
--- End Message ---
--- Begin Message ---
Brad Fuller wrote:
>> Is it possible to assign form[ upldFile ] = "C:\somepath\somefile"
>> or
>> form[ upldFile ] = $_FILES['userfile']['name']
>
> The "value" attribute of the <input type="file"...> tag is not able to be
> altered or pre-populated for obvious security reasons.
>
>> The script which does the validation is the same one which contains the
>> upload form. I suspect we're completely out of luck - apart from
>> validating
>> with JavaScript.
>
> Yup.
well no - you don't have any certainty that the javascript is even being run.
you still have to check everything server side and assume the javascript was
circumvented.
javascript validation is purely a mechanism to aid the user - i.e. it makes the
form
more responsive for honest users with a javascript *enabled* browser by
eliminating
superfluous trips to the server.
>
> -Brad
>
--- End Message ---
--- Begin Message ---
Thanks guys - I guess the staging area is the way we'll go. (This is from
gmail, I'm not used to it, so if I included all of the prev msgs, please
forgive me.)
Thanks - Miles
--- End Message ---
--- Begin Message ---
How can I upload files up to 40MB with a html post form? (without a ftp
client)
Please, remember
1. My hosting provider has up to 120 seconds apache timeout
2. My hosting provider has up to 10MB to upload files in php.ini
Any kind of ideas?
Regards
Mauricio M.
--- End Message ---
--- Begin Message ---
[snip]
1. My hosting provider has up to 120 seconds apache timeout
2. My hosting provider has up to 10MB to upload files in php.ini
Any kind of ideas?
[/snip]
Get a new provider?
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola!
Mauricio Muriel escribió:
> How can I upload files up to 40MB with a html post form? (without a ftp
> client)
>
> Please, remember
>
> 1. My hosting provider has up to 120 seconds apache timeout
> 2. My hosting provider has up to 10MB to upload files in php.ini
>
> Any kind of ideas?
Yes, use CGI & Perl.
Note: I love PHP but also know its limitations :)
Greetings.
- --
David Blanco - Programación y sistemas
Publicinet (Publicidad-Cine-Internet, S.L.)
Urzaiz, 71, entlo, izda. -- 36204 Vigo
Telf 902.014.606 -- http://www.publicinet.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFF0wZndbgIy1SiWTARAo0GAKCia3qWT+Q6SJsRR63VMUwHQxZkfgCeKlTx
LZKY9HlOeOGixGhWWi2U3ZU=
=duqS
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
On Mon, February 12, 2007 8:41 pm, J R wrote:
> it is not adviced to do filtering on _REQUEST getting data in general
> from
> it actually. It is much better to specify where your data is coming
> from (
> e.g. _POST or _GET). This is because variable _REQUST contains all the
> data
> from the cookies, get and post. and if ever you have the same variable
> name
> on two or more of those variable you might get the wrong one.
>
> and as we all know there is a security risk with cookies. users can
> easily
> replace you data for example in post using cookies.
Or they could replace all the POST data using POST...
A Bad Guy would have to be incredibly naive, unskilled, and downright
dumb to be caught by your script differentiating between
GET/POST/COOKIE as the source of the data.
Spoofing a POST is a matter of saving the HTML locally and filling in
whatever you want for extra INPUT and the values you like.
If you intentionally have 2 (or more) inputs to your script of the
same name, one each from GET/POST/COOKIE, I'd have to say that's a
pretty confusing design from the get-go.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
i agree, no argument there.
Data coming from user should always be considered malicious. I'm just
pointing out one reason why not use _REQUEST. but there are intance _REQUEST
variable can be useful (just be very careful). Regarding _GET and _POST
using same name, there are instance this can be useful, not at the same time
in one page but rather interchangely. example in page submit you get data
from $_GET['sameName'] and on the next page submit you get it from
$_POST['sameName'] this is for dynamic purpose. There are situation, that
for example data on _GET needed to be passed but you need to pass your page
using POST.(like i said be careful and not over use because of lazyness)
(i hope i'm being clear)
On 2/14/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Mon, February 12, 2007 8:41 pm, J R wrote:
> it is not adviced to do filtering on _REQUEST getting data in general
> from
> it actually. It is much better to specify where your data is coming
> from (
> e.g. _POST or _GET). This is because variable _REQUST contains all the
> data
> from the cookies, get and post. and if ever you have the same variable
> name
> on two or more of those variable you might get the wrong one.
>
> and as we all know there is a security risk with cookies. users can
> easily
> replace you data for example in post using cookies.
Or they could replace all the POST data using POST...
A Bad Guy would have to be incredibly naive, unskilled, and downright
dumb to be caught by your script differentiating between
GET/POST/COOKIE as the source of the data.
Spoofing a POST is a matter of saving the HTML locally and filling in
whatever you want for extra INPUT and the values you like.
If you intentionally have 2 (or more) inputs to your script of the
same name, one each from GET/POST/COOKIE, I'd have to say that's a
pretty confusing design from the get-go.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
GMail Rocks!!!
--- End Message ---
--- Begin Message ---
On Sat, February 10, 2007 3:19 pm, pub wrote:
> To all PHP experts,
>
> Do any of you also know how to play bridge?
> If yes, which do you think is harder to learn, PHP or bridge?
Bridge is way more harder to learn.
Especially all those weird bidding conventions with no rationale.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
Hey all,
I read on php.net about resources, the type
returned from mysql_query(), and was trying locate
the best way to get the result set back from a
query into an array.
Is simply looping through the result set with
mysql_fetch_assoc() the common way to do this?
As great as PHP is with arrays I was wondering if
there is some simply, more efficient way, but as
yet have not located one.
Thanks,
Skip
--
Skip Evans
Big Sky Penguin, LLC
61 W Broadway
Butte, Montana 59701
406-782-2240
http://bigskypenguin.com
=-=-=-=-=-=-=-=-=-=
Check out PHPenguin, a lightweight and
versatile PHP/MySQL development framework.
http://phpenguin.bigskypenguin.com/
--- End Message ---
--- Begin Message ---
On Tue, February 13, 2007 5:34 pm, Skip Evans wrote:
> I read on php.net about resources, the type
> returned from mysql_query(), and was trying locate
> the best way to get the result set back from a
> query into an array.
>
> Is simply looping through the result set with
> mysql_fetch_assoc() the common way to do this?
>
> As great as PHP is with arrays I was wondering if
> there is some simply, more efficient way, but as
> yet have not located one.
The most efficient way is "Don't do that." :-)
Simply loop through the results and do whatever you want to do with
them, and don't put them into an array at all.
This question has appeared before, and usually breaks down to one of
these scenarios:
#1
loop through mysql result set to build $array
loop through $array to output results
In this case, it's clearly more efficient to do:
loop through mysql result set to output results
#2
loop through mysql result set to build $array
perform some kind of calculation upon $array
In this case, it's USUALLY much more efficient to write an SQL query
to perform the calculation.
Databases are highly optimized for this kind of thing, and very
efficient at it.
PHP is a generalized programming language, and not so efficient for
this kind of task.
#2 does occasionally have an exception to the rule, where the SQL
query is nasty and the PHP is fast and easy, but that's awfully rare.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
Richard Lynch wrote:
The most efficient way is "Don't do that." :-)
Simply loop through the results and do whatever you want to do with
them, and don't put them into an array at all.
This makes perfect sense.
However, I am currently writing an abstraction
layer for a project that will later be ported from
MySQL to another database (and I haven't even
been told what that database will be, but probably
MS SQL Server), so I was thinking if some sort of
"helper functions" might be useful, but I think
simple wrappers are probably the way to go.
--
Skip Evans
Big Sky Penguin, LLC
61 W Broadway
Butte, Montana 59701
406-782-2240
http://bigskypenguin.com
=-=-=-=-=-=-=-=-=-=
Check out PHPenguin, a lightweight and
versatile PHP/MySQL development framework.
http://phpenguin.bigskypenguin.com/
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-02-13 17:43:10 -0700:
> Richard Lynch wrote:
> >The most efficient way is "Don't do that." :-)
> >
> >Simply loop through the results and do whatever you want to do with
> >them, and don't put them into an array at all.
>
> This makes perfect sense.
>
> However, I am currently writing an abstraction
> layer for a project that will later be ported from
> MySQL to another database (and I haven't even
> been told what that database will be, but probably
> MS SQL Server), so I was thinking if some sort of
> "helper functions" might be useful, but I think
> simple wrappers are probably the way to go.
Use iterators.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
On Tue, 2007-02-13 at 18:22 -0600, Richard Lynch wrote:
> #2
> loop through mysql result set to build $array
> perform some kind of calculation upon $array
>
> In this case, it's USUALLY much more efficient to write an SQL query
> to perform the calculation.
>
> Databases are highly optimized for this kind of thing, and very
> efficient at it.
> PHP is a generalized programming language, and not so efficient for
> this kind of task.
>
> #2 does occasionally have an exception to the rule, where the SQL
> query is nasty and the PHP is fast and easy, but that's awfully rare.
I hear this all the time that the database should do as much as possible
"it's highly optimized" yadda yadda. I'm going to go out on a limb and
say that in a heavily loaded system, shoving all the work into the
primary bottleneck is a bad idea. 100 workers make light work, and that
would be the inherent power in horizontal scalability. Databases do not
scale well horizontally, machines loaded with Apache and PHP do,
especially when each machine doesn't expect the database server to do
all the work. In fact, I'd wager queries involving joins are another
bane on horizontal scalability since now the tables are forced to reside
on the same machine.
I could be completely wrong, I've never worked on an extremely loaded
server, but I get a tick every time someone says "shove all the work
into the query", and that usually happens when something doesn't feel
right :)
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. |
`------------------------------------------------------------'
--- End Message ---
