php-general Digest 25 Jan 2007 14:33:22 -0000 Issue 4589
Topics (messages 247745 through 247778):
Re: most powerful php editor
247745 by: Roman Neuhauser
247746 by: Curt Zirzow
247748 by: Jochem Maas
247749 by: John Meyer
247750 by: Robert Cummings
247751 by: Robert Cummings
247752 by: Larry Garfield
247753 by: Robert Cummings
247754 by: tedd
247755 by: tedd
247756 by: Larry Garfield
247761 by: David Robley
247763 by: Roman Neuhauser
247768 by: Sancar Saran
247769 by: Roman Neuhauser
247772 by: clive
247777 by: Robert Cummings
Re: JPEG info needed
247747 by: Gerry Danen
Re: Validating a link in php
247757 by: sleestak2.earthlink.net
247762 by: Frank Arensmeier
sortind arrays
247758 by: William Stokes
247764 by: Paul Novitski
247766 by: Roman Neuhauser
247776 by: Alexander Sagen
Parsing AJAX post data -- The Way
247759 by: M5
247760 by: M5
247765 by: Roman Neuhauser
247770 by: Stut
247774 by: Bernhard Zwischenbrugger
247775 by: Colin Guthrie
Re: Unserialize problem (and or bug)
247767 by: Sancar Saran
Re: preg_match problem
247771 by: Jim Lucas
Re: Multi lingual pages
247773 by: Satyam
Send Email to Mobiles
247778 by: Marcelo Ferrufino Murillo
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:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-01-24 18:23:10 -0600:
> On Wed, January 24, 2007 7:41 am, Roman Neuhauser wrote:
> > # [EMAIL PROTECTED] / 2007-01-24 13:57:03 +0200:
> >> and also in these days I'm looking for 19 inch (or more) wide LCD
> >> sceerns to able to fit longer lines in my screen...
> >
> > Number of reading errors people make grows with line length,
> > this has been known for as long as I remember. You're increasing the
> > probability of bugs in the code, and get tired sooner because
> > following
> > long lines requires more energy.
>
> I believe those results are specific to what is being read.
>
> Surely it's easier to read:
>
> SELECT blah, blah, blah, blah, blah, blah, blah, blah, blah
Not for me.
SQL is just another programming language, and I fail to see why
principles of programming hygiene shouldn't apply to it.
> Sure, it can be "hard" to find/read the individual field names, on the
> rare occasion that you need to do that...
Like, on the "rare" occasion that you need to find a bug in a program
with poor formatting.
> Assuming you actually planned your DB and queries out to fit your
> application needs in the first place. I guess if you're coding in an
> unstructured iterative way to design the db, then, yeah, it would be
> harder on the eyes as you morph that statement into what it should
> be...
> :-v
That's a strong argument against indenting source code: all you need is
a solid design upfront! Of course, if your queries sum up to blah,
blah, blah, it might not be worth designing them in the first place.
:-^
--
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 1/20/07, Vinicius C Silva <[EMAIL PROTECTED]> wrote:
hi everyone!
i'd like to ask something maybe commonly asked here. what is the most
powerful php editor?
So now we have a 4 day thread of discussing nothing but, this is what i use....
Curt.
--- End Message ---
--- Begin Message ---
Curt Zirzow wrote:
> On 1/20/07, Vinicius C Silva <[EMAIL PROTECTED]> wrote:
>> hi everyone!
>>
>> i'd like to ask something maybe commonly asked here. what is the most
>> powerful php editor?
>
>
> So now we have a 4 day thread of discussing nothing but, this is what i
> use....
let see if we can make it a full week :-P
>
>
> Curt.
>
--- End Message ---
--- Begin Message ---
Jochem Maas wrote:
> Curt Zirzow wrote:
>> On 1/20/07, Vinicius C Silva <[EMAIL PROTECTED]> wrote:
>>> hi everyone!
>>>
>>> i'd like to ask something maybe commonly asked here. what is the most
>>> powerful php editor?
>>
>> So now we have a 4 day thread of discussing nothing but, this is what i
>> use....
>
> let see if we can make it a full week :-P
If we want to argue about this, let's set a few guidelines as to what
"powerful" means. I propose these guidelines
1. Syntax highlighting
2. Web server integration
3. Link checking
4. Browser check in the top three (Mozilla-IE-Opera)
Now maybe you disagree, maybe you agree. I'd love to just use vi and
type away, but quite frankly I'm not that smart. And if you have your
own guidelines, let's hear them.
--- End Message ---
--- Begin Message ---
On Wed, 2007-01-24 at 18:23 -0600, Richard Lynch wrote:
> On Wed, January 24, 2007 7:41 am, Roman Neuhauser wrote:
> > # [EMAIL PROTECTED] / 2007-01-24 13:57:03 +0200:
> >> and also in these days I'm looking for 19 inch (or more) wide LCD
> >> sceerns to able to fit longer lines in my screen...
> >
> > Number of reading errors people make grows with line length,
> > this has been known for as long as I remember. You're increasing the
> > probability of bugs in the code, and get tired sooner because
> > following
> > long lines requires more energy.
>
> I believe those results are specific to what is being read.
>
> Surely it's easier to read:
>
> SELECT blah, blah, blah, blah, blah, blah, blah, blah, blah
>
> if it's all on one line, no matter how many fields there are, while
> trying to read the code as a whole.
>
> Sure, it can be "hard" to find/read the individual field names, on the
> rare occasion that you need to do that...
Dear Mr Lynch, normally I highly respect your commentary on the list,
but today I think you've been-a-smoking the crackpipe a tad too much.
There is no way in hell one long line of SQL is easier to read than
formatted SQL that clearly delineates the clause structure.
SELECT A.field1 AS afield1, A.field2 AS afield2, B.field1 AS bfield1,
B.field2 AS bfield2, C.field1 AS cfield1, C.field2 AS cfield2, D.field1
AS dfield1, D.field2 AS dfield2 FROM tableA as A LEFT JOIN tableB AS B
ON B.fee = A.foo LEFT JOIN tableC AS C ON C.fii = B.fee LEFT JOIN tableD
AS D ON D.fuu = C.fii WHERE A.foo = 'someValue' ORDER BY afield1 ASC,
cfield2 ASC
The above line "should" be on one line, but my email client might
autowrap it. Either way, the following is formatted and is much clearer.
SELECT
A.field1 AS afield1,
A.field2 AS afield2,
B.field1 AS bfield1,
B.field2 AS bfield2,
C.field1 AS cfield1,
C.field2 AS cfield2,
D.field1 AS dfield1,
D.field2 AS dfield2
FROM
tableA as A
LEFT JOIN tableB AS B ON
B.fee = A.foo
LEFT JOIN tableC AS C ON
C.fii = B.fee
LEFT JOIN tableD AS D ON
D.fuu = C.fii
WHERE
A.foo = 'someValue'
ORDER BY
afield1 ASC,
cfield2 ASC
While the above is contrived, most of us know such examples happen quite
often in the wild. Not only is it easier to read, but the task of adding
or removing selected fields is trivial.
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 ---
On Wed, 2007-01-24 at 18:48 -0700, John Meyer wrote:
> Jochem Maas wrote:
> > Curt Zirzow wrote:
> >> On 1/20/07, Vinicius C Silva <[EMAIL PROTECTED]> wrote:
> >>> hi everyone!
> >>>
> >>> i'd like to ask something maybe commonly asked here. what is the most
> >>> powerful php editor?
> >>
> >> So now we have a 4 day thread of discussing nothing but, this is what i
> >> use....
> >
> > let see if we can make it a full week :-P
>
>
> If we want to argue about this, let's set a few guidelines as to what
> "powerful" means. I propose these guidelines
>
> 1. Syntax highlighting
Useful, but I stuck with joe for 3 years before they got syntax
highlighting. I like the editor that much :)
> 2. Web server integration
Why? Web servers read files. Editor's read and write files. Seems the
filesystem is plenty of glue.
> 3. Link checking
Ummm, what do you do about generated links? My experience has been that
ripping through the site towards the end of development with wget is
quite satisfactory.
> 4. Browser check in the top three (Mozilla-IE-Opera)
Huh? What's browser check? Don't you just test with each of the
browsers? IE works quite nicely with windows confined to a vmware
sandbox.
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 ---
On Wednesday 24 January 2007 8:07 pm, Robert Cummings wrote:
> There is no way in hell one long line of SQL is easier to read than
> formatted SQL that clearly delineates the clause structure.
Sure there is. If it's a very simple SQL statement.
I have at various times done all of the following, depending on the complexity
of the statement in question:
SELECT id, foo, FROM foo_table WHERE id=5
(Too short to really bother with splitting up.)
SELECT id, foo, bar, baz
FROM foo_table
INNER JOIN bar_table on a=b
LEFT OUTER JOIN baz_table on b=c
WHERE blah
AND stuff < narf
OR (thingie AND other)
ORDER BY foo
SELECT a.a, a.b, a.c
b.d, b.e, b.f
FROM a
INNER JOIN b ON whatever
ORDER BY a.b, a.c DESC
"Like any other programming language", or rather any language that isn't
Python, formatting matters most to the reader, not to the program. So,
optimize your style for readability. Readability is, of course, partially
subjective so your style will differ from my style, but the key point is
still to optimize the code for when you come back in 3-6 months to add a
feature or find an obscure bug and don't remember what the frel you were
doing.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--- End Message ---
--- Begin Message ---
On Wed, 2007-01-24 at 20:44 -0600, Larry Garfield wrote:
> On Wednesday 24 January 2007 8:07 pm, Robert Cummings wrote:
>
> > There is no way in hell one long line of SQL is easier to read than
> > formatted SQL that clearly delineates the clause structure.
>
> Sure there is. If it's a very simple SQL statement.
>
> I have at various times done all of the following, depending on the
> complexity
> of the statement in question:
>
> SELECT id, foo, FROM foo_table WHERE id=5
>
> (Too short to really bother with splitting up.)
>
> SELECT id, foo, bar, baz
> FROM foo_table
> INNER JOIN bar_table on a=b
> LEFT OUTER JOIN baz_table on b=c
> WHERE blah
> AND stuff < narf
> OR (thingie AND other)
> ORDER BY foo
>
> SELECT a.a, a.b, a.c
> b.d, b.e, b.f
> FROM a
> INNER JOIN b ON whatever
> ORDER BY a.b, a.c DESC
I notice you formatted all of the "long" ones. That's why in my original
statement I wrote "There is no way in hell one long line". Subsequently,
I deem you to be in agreement with my point, despite the misguided
protest :B
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 ---
At 6:48 PM -0700 1/24/07, John Meyer wrote:
If we want to argue about this, let's set a few guidelines as to what
"powerful" means. I propose these guidelines
1. Syntax highlighting
2. Web server integration
3. Link checking
4. Browser check in the top three (Mozilla-IE-Opera)
Now maybe you disagree, maybe you agree. I'd love to just use vi and
type away, but quite frankly I'm not that smart. And if you have your
own guidelines, let's hear them.
I'm not that smart either, but probably more so than you. ;-)
I use GoLive for the Mac for all my html, javascript, ajax, dom
scripting, php, and mysql development. It has a bunch of WYSIWYG junk
that I seldom use.
But, it gives me: a great editor (syntax coloring throughout the
different languages); allows me to develop real-time on the web
(virtual host stuff); with universal link checking (i.e, change one,
it changes the rest); excellent search and replace features; and an
on-line/off-line directory structure that makes it very easy to
update files to/from my server. Plus, it allows me to edit files via
their parent application (i.e., Photoshop, GIF editor, Flash,
whatever) while using GoLive.
As far as Browsers, GoLive can launch any Mac browser, but not IE --
there is no IE for Mac, other than IE5.2. As such, I use BrowserCam
to check for layouts and I think that's a better way to check for css
differences between browsers. I never observe any php/mysql
differences.
The layout allows me to set-up my defaults to the way I want thing to
be from what the doctypes my files are to be saved as to the way and
type of helper windows I want.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 9:07 PM -0500 1/24/07, Robert Cummings wrote:
Dear Mr Lynch, normally I highly respect your commentary on the list,
but today I think you've been-a-smoking the crackpipe a tad too much.
There is no way in hell one long line of SQL is easier to read than
formatted SQL that clearly delineates the clause structure.
SELECT A.field1 AS afield1, A.field2 AS afield2, B.field1 AS bfield1,
B.field2 AS bfield2, C.field1 AS cfield1, C.field2 AS cfield2, D.field1
AS dfield1, D.field2 AS dfield2 FROM tableA as A LEFT JOIN tableB AS B
ON B.fee = A.foo LEFT JOIN tableC AS C ON C.fii = B.fee LEFT JOIN tableD
AS D ON D.fuu = C.fii WHERE A.foo = 'someValue' ORDER BY afield1 ASC,
cfield2 ASC
The above line "should" be on one line, but my email client might
autowrap it. Either way, the following is formatted and is much clearer.
SELECT
A.field1 AS afield1,
A.field2 AS afield2,
B.field1 AS bfield1,
B.field2 AS bfield2,
C.field1 AS cfield1,
C.field2 AS cfield2,
D.field1 AS dfield1,
D.field2 AS dfield2
FROM
tableA as A
LEFT JOIN tableB AS B ON
B.fee = A.foo
LEFT JOIN tableC AS C ON
C.fii = B.fee
LEFT JOIN tableD AS D ON
D.fuu = C.fii
WHERE
A.foo = 'someValue'
ORDER BY
afield1 ASC,
cfield2 ASC
While the above is contrived, most of us know such examples happen quite
often in the wild. Not only is it easier to read, but the task of adding
or removing selected fields is trivial.
Cheers,
Rob.
Ahem to that!
You're on a roll brother -- keep going.
Can I get another Ahem?!
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On Wednesday 24 January 2007 7:48 pm, John Meyer wrote:
> Jochem Maas wrote:
> > Curt Zirzow wrote:
> >> On 1/20/07, Vinicius C Silva <[EMAIL PROTECTED]> wrote:
> >>> hi everyone!
> >>>
> >>> i'd like to ask something maybe commonly asked here. what is the most
> >>> powerful php editor?
> >>
> >> So now we have a 4 day thread of discussing nothing but, this is what i
> >> use....
> >
> > let see if we can make it a full week :-P
>
> If we want to argue about this, let's set a few guidelines as to what
> "powerful" means. I propose these guidelines
>
> 1. Syntax highlighting
Yes.
> 2. Web server integration
Irrelevant, except insofar as it supports a real-time debugger.
> 3. Link checking
> 4. Browser check in the top three (Mozilla-IE-Opera)
These are both HTML editor features, not PHP editor features.
For me, the big three features I want in a PHP dev environment are:
- Syntax highlighting.
- Context-sensitive code assistance. I hate having to remember the order of
parameters, especially when they're irregular.
- Real-time debugger. The only one I've found that works for me so far is
Zend's. I cannot overstate how useful a real-time debugger is for tracking
down bugs in complex applications.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
--- End Message ---
--- Begin Message ---
tedd wrote:
> At 9:07 PM -0500 1/24/07, Robert Cummings wrote:
<Code structure>
> Ahem to that!
>
> You're on a roll brother -- keep going.
>
> Can I get another Ahem?!
>
> tedd
I'll see your 'Ahem' and raise you an 'Amen' :-)
Cheers
--
David Robley
Vultures only fly with carrion luggage.
Today is Setting Orange, the 25th day of Chaos in the YOLD 3173.
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-01-25 02:21:34 +0100:
> Curt Zirzow wrote:
> > On 1/20/07, Vinicius C Silva <[EMAIL PROTECTED]> wrote:
> >> hi everyone!
> >>
> >> i'd like to ask something maybe commonly asked here. what is the most
> >> powerful php editor?
> >
> >
> > So now we have a 4 day thread of discussing nothing but, this is what i
> > use....
>
> let see if we can make it a full week :-P
This thread has been going on 8 years ago when I first subscribed to
this list. 400 weeks has been enough! :]
--
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 Wednesday 24 January 2007 15:41, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-01-24 13:57:03 +0200:
> > and also in these days I'm looking for 19 inch (or more) wide LCD
> > sceerns to able to fit longer lines in my screen...
>
> Number of reading errors people make grows with line length,
> this has been known for as long as I remember. You're increasing the
> probability of bugs in the code, and get tired sooner because following
> long lines requires more energy.
Yes and no, because these days I'm obsessed very very large arrays like
$arr['this']['is']['what']['i']['m']['looking']['for'];
And If I start to do
if( ($arr['this']['is']['what']['i']['m']['looking']['for'] > 5) &&
($arr['this']['is']['what']['i']['m']['looking']['for'] < 10))
blah blah
then problem begins :)
> --
> 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 ---
# [EMAIL PROTECTED] / 2007-01-25 11:06:22 +0200:
> On Wednesday 24 January 2007 15:41, Roman Neuhauser wrote:
> > # [EMAIL PROTECTED] / 2007-01-24 13:57:03 +0200:
> > > and also in these days I'm looking for 19 inch (or more) wide LCD
> > > sceerns to able to fit longer lines in my screen...
> >
> > Number of reading errors people make grows with line length,
> > this has been known for as long as I remember. You're increasing the
> > probability of bugs in the code, and get tired sooner because following
> > long lines requires more energy.
>
> Yes and no, because these days I'm obsessed very very large arrays like
> $arr['this']['is']['what']['i']['m']['looking']['for'];
Well, ugh!
> And If I start to do
>
> if( ($arr['this']['is']['what']['i']['m']['looking']['for'] > 5) &&
> ($arr['this']['is']['what']['i']['m']['looking']['for'] < 10))
>
> blah blah
>
> then problem begins :)
That's atrocious no matter how wide your screen is.
--
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 ---
Vinicius C Silva wrote:
hi everyone!
i'd like to ask something maybe commonly asked here. what is the most
powerful php editor?
Just thought I'd add my bit,
I used to use phpedit when I developed on a windows systems, then I
started using Zend.
Ive now moved to linux and still use Zend and I am slowly learning VIM.
Now, eddie, the dude I work with is a vi master, he does stuff in that
editor that Zend can't even comprehend. Watching eddie work with vi, is
like watching a conductor conducting a orchestra, quick, efficient and
pretty much amazing.
clive
ps. I dont really listen to orchestral music.
--- End Message ---
--- Begin Message ---
On Thu, 2007-01-25 at 10:12 +0000, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-01-25 11:06:22 +0200:
> > On Wednesday 24 January 2007 15:41, Roman Neuhauser wrote:
> > > # [EMAIL PROTECTED] / 2007-01-24 13:57:03 +0200:
> > > > and also in these days I'm looking for 19 inch (or more) wide LCD
> > > > sceerns to able to fit longer lines in my screen...
> > >
> > > Number of reading errors people make grows with line length,
> > > this has been known for as long as I remember. You're increasing the
> > > probability of bugs in the code, and get tired sooner because following
> > > long lines requires more energy.
> >
> > Yes and no, because these days I'm obsessed very very large arrays like
> > $arr['this']['is']['what']['i']['m']['looking']['for'];
>
> Well, ugh!
>
> > And If I start to do
> >
> > if( ($arr['this']['is']['what']['i']['m']['looking']['for'] > 5) &&
> > ($arr['this']['is']['what']['i']['m']['looking']['for'] < 10))
That's terrible... first off we'll start by doing the following:
if( ($arr['this']['is']['what']['i']['m']['looking']['for'] > 5)
&&
($arr['this']['is']['what']['i']['m']['looking']['for'] < 10) )
Next we'll chop off the redundant bits:
if( $arr['this']['is']['what']['i']['m']['looking']['for'] > 5
&&
$arr['this']['is']['what']['i']['m']['looking']['for'] < 10 )
Now we'll make sure we don't throw any sloppy errors:
if( isset( $arr['this']['is']['what']['i']['m']['looking']['for'] )
&&
$arr['this']['is']['what']['i']['m']['looking']['for'] > 5
&&
$arr['this']['is']['what']['i']['m']['looking']['for'] < 10 )
:)
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 ---
Richard,
imageinterlace() turns the interlace bit on or off. It only returns 1
if you set it to 1 as the second parameter...
Thanks
Gerry
On 1/24/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Wed, January 24, 2007 12:08 am, Gerry Danen wrote:
>> One other possibility is to see what happens if you do
>> imagefromjpeg()
>> on a progressive JPEG -- There amy be functions in GD that will tell
>> you if the JPEG is progressive, once you have sucked it into PHP...
>
> Any idea which ones to look at?
No, but a quick search on php.net for "JPEG progress" with "online
documentation" from the popup yeilded:
http://us3.php.net/manual/en/function.imageinterlace.php
"If the interlace bit is set and the image is used as a JPEG image,
the image is created as a progressive JPEG.
This function returns whether the interlace bit is set for the image. "
Presumably, then, this would work:
<?php
$filename = '/full/path/to/filename.jpg';
$jpeg = imagecreatefromjpeg($filename);
$progressive = imageinterlace($jpeg);
if ($progressive) echo "$filename is progressive.\n";
else echo "$filename is NOT progressive.\n";
?>
--- End Message ---
--- Begin Message ---
Richard Lynch wrote:
>I dunno what you did wrong with fsockopen...
First of all, thanks for taking the time to respond.
I had tried fsockopen, but here's the problem. The
following calls work as expected, returning a valid file
pointer for valid urls and FALSE for invalid urls:
$fp = fsockopen("www.example.com", 80, $errno, $errstr, 30);
$fp = fsockopen("www.youtube.com", 80, $errno, $errstr, 30);
$fp = fsockopen("www.this_url_is_not_valid.com", 80, $errno, $errstr, 30);
The call below does not work and always returns FALSE.
If I enter the url in a web browser, it works fine, but
fsockopen does not like it.
$fp = fsockopen("www.youtube.com/v/JqO8ZevPJNk", 80, $errno, $errstr, 30);
I think it has something to do with the way YouTube
works. Any clues?
Robert Porter
--- End Message ---
--- Begin Message ---
25 jan 2007 kl. 07.06 skrev [EMAIL PROTECTED]:
Richard Lynch wrote:
I dunno what you did wrong with fsockopen...
First of all, thanks for taking the time to respond.
I had tried fsockopen, but here's the problem. The
following calls work as expected, returning a valid file
pointer for valid urls and FALSE for invalid urls:
$fp = fsockopen("www.example.com", 80, $errno, $errstr, 30);
$fp = fsockopen("www.youtube.com", 80, $errno, $errstr, 30);
$fp = fsockopen("www.this_url_is_not_valid.com", 80, $errno,
$errstr, 30);
The call below does not work and always returns FALSE.
If I enter the url in a web browser, it works fine, but
fsockopen does not like it.
$fp = fsockopen("www.youtube.com/v/JqO8ZevPJNk", 80, $errno,
$errstr, 30);
I think it has something to do with the way YouTube
works. Any clues?
Did you take a look at the error numbers / messages returned by
fsockopen? What do they say? I can't see any problems with your code
either. So, either the call gets stuck maybe due to some
configuration on your machine (you can simply test it by changing you
fsockopen call to e.g. www.php.net - or your lolcalhost), or - as you
already mentioned - it is youTube that blocks your calls in some way
(therefore, error message might give you a clue why).
Another thing that poped up in my mind - curl. Tried that?
//frank
Robert Porter
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hello,
How can I sort an array like this so that it would be ASC ordered by the [1]
key in subarrays? I need to maintain only the subarray key - value pairs.
(Do I make sense?)
Array
(
[0] => Array
(
[0] => Logo
[1] => NameC
[2] => Home
[3] => url
)
[1] => Array
(
[0] => Logo
[1] => NameA
[2] => Home
[3] => url
)
[2] => Array
(
[0] => Logo
[1] => NameG
[2] => Home
[3] => url
)
}
Cheers!
-Will
--- End Message ---
--- Begin Message ---
At 1/24/2007 10:12 PM, William Stokes wrote:
How can I sort an array like this so that it would be ASC ordered by the [1]
key in subarrays? I need to maintain only the subarray key - value pairs.
(Do I make sense?)
Array
(
[0] => Array
(
[0] => Logo
[1] => NameC
[2] => Home
[3] => url
)
[1] => Array
(
[0] => Logo
[1] => NameA
[2] => Home
[3] => url
)
[2] => Array
(
[0] => Logo
[1] => NameG
[2] => Home
[3] => url
)
}
Try multisort:
http://php.net/array_multisort
Regards,
Paul
__________________________
Juniper Webcraft Ltd.
http://juniperwebcraft.com
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-01-25 08:12:14 +0200:
> How can I sort an array like this so that it would be ASC ordered by the [1]
> key in subarrays? I need to maintain only the subarray key - value pairs.
> (Do I make sense?)
>
> Array
> (
> [0] => Array
> (
> [0] => Logo
> [1] => NameC
> [2] => Home
> [3] => url
> )
>
> [1] => Array
> (
> [0] => Logo
> [1] => NameA
> [2] => Home
> [3] => url
> )
>
> [2] => Array
> (
> [0] => Logo
> [1] => NameG
> [2] => Home
> [3] => url
> )
> }
http://www.php.net/usort
--
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 ---
Roman Neuhauser skrev:
# [EMAIL PROTECTED] / 2007-01-25 08:12:14 +0200:
How can I sort an array like this so that it would be ASC ordered by the [1]
key in subarrays? I need to maintain only the subarray key - value pairs.
(Do I make sense?)
Array
(
[0] => Array
(
[0] => Logo
[1] => NameC
[2] => Home
[3] => url
)
[1] => Array
(
[0] => Logo
[1] => NameA
[2] => Home
[3] => url
)
[2] => Array
(
[0] => Logo
[1] => NameG
[2] => Home
[3] => url
)
}
http://www.php.net/usort
I think usort would be a bit overkill, he would probably find himself
making a function to sort and maintain the association between the
subarrays. Go with array_multisort, it would be a one-liner.
--- End Message ---
--- Begin Message ---
Just wondering what smart people do for parsing data sent by the
Javascript XMLHTTP object--e.g., http.send("post",url,true)...
In a normal form submit, the $_POST global nicely allocates form
elements as array elements automatically. But with the AJAX way, the
data get stuffed inside $HTTP_RAW_POST_DATA as a string, thereby
making extraction more tedious.
Any ideas?
...Rene
--- End Message ---
--- Begin Message ---
Just wondering what smart people do for parsing data sent by the
Javascript XMLHTTP object--e.g., http.send("post",url,true)...
In a normal form submit, the $_POST global nicely allocates form
elements as array elements automatically. But with the AJAX way, the
data get stuffed inside $HTTP_RAW_POST_DATA as a string, thereby
making extraction more tedious.
Any ideas?
...Rene
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-01-24 23:41:19 -0700:
> Just wondering what smart people do for parsing data sent by the
> Javascript XMLHTTP object--e.g., http.send("post",url,true)...
>
> In a normal form submit, the $_POST global nicely allocates form
> elements as array elements automatically. But with the AJAX way, the
> data get stuffed inside $HTTP_RAW_POST_DATA as a string, thereby
> making extraction more tedious.
Are you looking for http://php.net/manual/en/ref.json.php ?
--
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 ---
M5 wrote:
Just wondering what smart people do for parsing data sent by the
Javascript XMLHTTP object--e.g., http.send("post",url,true)...
In a normal form submit, the $_POST global nicely allocates form
elements as array elements automatically. But with the AJAX way, the
data get stuffed inside $HTTP_RAW_POST_DATA as a string, thereby
making extraction more tedious.
What format is the data you are posting in? If it's in the usual format,
PHP should parse it for you. An AJAX (hate that acronym) post request is
no different to a normal post, unless you are not posting in the form
format (var1=val2&var2=val2).
-Stut
--- End Message ---
--- Begin Message ---
hi
The "X" in AJAX says that the data are XML Data.
To parse XML I use DOM.
It is also possible to validate the data using RelaxNG, DTD or XMLSchema
before processing.
A receiver in PHP looks like
<?php
//read the string ($HTTP_RAW_POST_DATA is by default
//not active -> use "php://input")
$content=file_get_contents("php://input");
//make a dom object
//many people know DOM already from programming javascript
$dom=domDocument::loadXML($content);
//validate with DTD,RelaxNG or XMLSchema
//http://at.php.net/manual/de/function.dom-domdocument-relaxngvalidate.php
if($dom->relaxNGValidate("test.rng")){
//than read the data you need
//for example if your XML looks like
//<person born="1935">
//<firstname>Dalei</firstname><lastname>Lama</lastname>
//</person>
$firstname=$dom->getElementsByTagName('firstname')->item(0);
$lastname=$dom->getElementsByTagName('lastname')->item(0);
$born=$dom->documentElement->getAttribute('born');
}else{
echo "data are not valid";
}
?>
If you don't like XML (AJAX) use JSON.
Bernhard
Am Donnerstag, den 25.01.2007, 00:00 -0700 schrieb M5:
> Just wondering what smart people do for parsing data sent by the
> Javascript XMLHTTP object--e.g., http.send("post",url,true)...
>
> In a normal form submit, the $_POST global nicely allocates form
> elements as array elements automatically. But with the AJAX way, the
> data get stuffed inside $HTTP_RAW_POST_DATA as a string, thereby
> making extraction more tedious.
>
> Any ideas?
>
> ...Rene
>
--- End Message ---
--- Begin Message ---
Stut wrote:
> M5 wrote:
>> Just wondering what smart people do for parsing data sent by the
>> Javascript XMLHTTP object--e.g., http.send("post",url,true)...
>>
>> In a normal form submit, the $_POST global nicely allocates form
>> elements as array elements automatically. But with the AJAX way, the
>> data get stuffed inside $HTTP_RAW_POST_DATA as a string, thereby
>> making extraction more tedious.
>
> What format is the data you are posting in? If it's in the usual format,
> PHP should parse it for you. An AJAX (hate that acronym) post request is
> no different to a normal post, unless you are not posting in the form
> format (var1=val2&var2=val2).
Yes, just to elaborate, consider the following (simple AJAX post (using
prototype.js as it's great!).
function SendRemote(action)
{
new Ajax.Request('backend.php', { parameters: 'submit='+action });
}
This sends a simple form POSTED to the server with one form element
(named "submit") which will be available to the server as $_POST['submit'].
If you want to add more, just use the & as Stut suggests, e.g.:
function SendRemote(action)
{
new Ajax.Request('backend.php', { parameters:
'submit='+action+'&var2=xxx' });
}
etc.
HTH
Col.
--- End Message ---
--- Begin Message ---
Hi
On Thursday 25 January 2007 02:16, Richard Lynch wrote:
> On Wed, January 24, 2007 9:17 am, Sancar Saran wrote:
> > After updating company test server to dotdeb 5.2.0 it star to give
> > memory
> > problems (even 32mb session). I tought it was because of suhosin. And
> > I
> > cannot update that server to vanilla debian php5 package because it
> > was a
> > sarge so today my company gives me another debian etch (like my home
> > pc). I
> > setup latest php 5.2.0.8 for debian etch.
> >
> > Then unserialize gives another problem
> >
> > Message: unserialize(): Error at offset 1384 of 3177 bytes
> > Code: 8
> > Line: 419
> >
> > My pc uses debian etch and have php 5.1.6-5 my scripts working
> > normally.
> >
> > Is there any suggestion for handle this ?
>
> What is in the data at byte 1384 that can't be unserialized?
some UTF-8 data
>
> Are you trying to take data serialized by one version of PHP and
> unserialize it with another?
Yes
> That does not work in current versions, though discussion on Internals
> lends hope that future versions will be able to deal intelligently
> with this situation.
Jochem was inform me, then I was re generate that arrays then problem fixed.
>
> Check http://bugs.php.net/ for similar bugs -- there may be a patch.
>
> Also check with suhosin and Debian bug tracking, as it may be specific
> to either of those.
>
Currently My machine and target has same php version, Today I may do another
transfer. I'll recheck situation, maybe backporting data from server solve
the issue. And or I move my machine to more updated PHP...
Dotdeb (including suhosin) and standart PHP act very differently. In dotdeb
unserialize filling 32 mb'ed session and stop. Vanilla php 5.1.6 (at target
server) and 5.2.0 (at target server) giving offset error...
More interesting was I'm on so tigh schedule to do someting...
Maybe I have to go and burn a candle to St.Murphy
God save Jochem and you, because there was no info anywhere in web, yesterday
I go crazy. And I bet myself to this serialize/unserialize thing...
Many thanks...
Sancar
--- End Message ---
--- Begin Message ---
Beauford wrote:
Here is my rendition of what I think you are looking for.
$str = 'tab( )/space( )/[EMAIL PROTECTED]&*();:...';
if ( preg_match('|[EMAIL PROTECTED]&*();:_.\\\\ /\t-]+$|', $str) ) {
echo 'success';
} else {
echo 'failure';
}
Here is the problem, and it is strange. If I enter each of the above
characters into my form one at a time and hit submit after each one, NO
error is produced for any of them.
If I cut and past this all at once: [EMAIL PROTECTED]&*();:_.\ then an error
IS returned.
If I continue to remove one character at a time, submitting the form each
time, errors ARE still produced.
This is the code in a nutshell:
If(isset($submit)) {
$name = stripslashes($_POST['name']); >> I have tried this with and
without
$formerror = array(); unset($result); >> I have tried this with and
without
if($result = ValidateString($name)) { $formerror['name'] =
$invalidcharacters;
Function ValidateString($string) {
if (!preg_match('|[EMAIL PROTECTED]&*();:_.\\\\ /\t-]+$|',
$string) ) {
return invalidchars;
}
}
}
<Form Stuff>
<input name="name" size="30" type="text">
</form>
Thanks
Here is a link to a page that has this on it, but with the added "'"
Plus a link to the source code for it.
Jim
--- End Message ---
--- Begin Message ---
I wrote something about this, but it is in Spanish:
http://www.satyam.com.ar/blog/2007/01/17/internacionalizacion-y-localizacion-indice/
Satyam
----- Original Message -----
From: "Otto Wyss" <[EMAIL PROTECTED]>
To: <php-general@lists.php.net>
Sent: Wednesday, January 24, 2007 10:44 PM
Subject: [PHP] Multi lingual pages
I'd like to make my pages multi lingual, showing everything in the
language the user chooses. My pages show mostly static text. So what's the
usual implementation for this case.
O. Wyss
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi guys, I need to send a email to mobiles I don´t know if I have to use the
function "mail( )" or if I have to use other one. Thanks your help
--- End Message ---
