|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Thu Feb 28 2008 - 17:53:29 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 28 Feb 2008 23:53:29 -0000 Issue 5320
Topics (messages 270535 through 270666):
Re: output buffering in CLI script.
270535 by: Stut
270538 by: Stuart Dallas
270540 by: Jochem Maas
270541 by: Jochem Maas
270543 by: Jochem Maas
270544 by: Nathan Rixham
270548 by: Stuart Dallas
270549 by: Aschwin Wesselius
270551 by: Jochem Maas
Re: reverse string without strrev();
270536 by: Stut
270537 by: Aschwin Wesselius
270547 by: Nathan Rixham
270550 by: Aschwin Wesselius
270553 by: Ford, Mike
270558 by: Nathan Rixham
270559 by: Christoph Boget
270571 by: Robert Cummings
270573 by: Aschwin Wesselius
270575 by: Aschwin Wesselius
270579 by: Robert Cummings
270581 by: Richard Heyes
270582 by: Aschwin Wesselius
270595 by: Robin Vickery
270609 by: Robert Cummings
Re: Guidance
270539 by: Timothy Asiedu
270542 by: Stut
270545 by: Jochem Maas
270546 by: Thiago Pojda
270561 by: Zoltán Németh
270597 by: Andrew Ballard
[SOLVEDish] Re: [PHP] output buffering in CLI script.
270552 by: Jochem Maas
270554 by: Nathan Rixham
270555 by: Aschwin Wesselius
270556 by: Nathan Rixham
270566 by: Jochem Maas
Re: [NOT SOLVEDish] Re: [PHP] output buffering in CLI script.
270557 by: Jochem Maas
Re: What design patterns do you usually use?
270560 by: tedd
Re: ZCE guidance needed
270562 by: Ray Hauge
270564 by: Ray Hauge
270584 by: Thiago Pojda
270593 by: Nathan Nobbe
Re: Flexible Shopping Cart (was: Shopping Carts)
270563 by: tedd
270614 by: Eric Butera
270616 by: Daniel Brown
270617 by: Eric Butera
270619 by: Nathan Rixham
270621 by: Daniel Brown
270624 by: Eric Butera
270631 by: Daniel Brown
270632 by: Wolf
270636 by: Robert Cummings
270643 by: Shawn McKenzie
auto-wrap on posts
270565 by: Nathan Nobbe
270567 by: Jason Pruim
270568 by: Ray Hauge
270569 by: Nathan Rixham
270570 by: Nathan Nobbe
270572 by: David Giragosian
270574 by: Nathan Nobbe
270576 by: Jason Pruim
270577 by: Jason Pruim
270580 by: David Giragosian
270585 by: Thiago Pojda
270587 by: Daniel Brown
270588 by: Daniel Brown
270589 by: Daniel Brown
270590 by: Ray Hauge
270591 by: David Giragosian
270592 by: Eric Butera
270594 by: Thiago Pojda
Re: php --ini and the like
270578 by: Nathan Nobbe
Re: Getting the name of a function
270583 by: Daniel Brown
Re: Sometimes I wonder why I even started programming...
270586 by: Philip Thompson
270596 by: Eric Butera
270599 by: Jason Pruim
270600 by: Jason Pruim
270602 by: Daniel Brown
270606 by: Eric Butera
270607 by: Daniel Brown
270608 by: Eric Butera
270611 by: Jason Pruim
270612 by: Eric Butera
270613 by: Daniel Brown
270615 by: Andrew Ballard
270618 by: Nathan Rixham
270622 by: Wolf
270623 by: Eric Butera
270625 by: Daniel Brown
270627 by: Jay Blanchard
270628 by: Wolf
270629 by: Per Jessen
270630 by: Per Jessen
270633 by: Daniel Brown
270634 by: Jason Pruim
270637 by: TG
270640 by: Stut
270642 by: Stut
270645 by: Robert Cummings
270646 by: Per Jessen
270647 by: Nathan Rixham
270648 by: Nathan Rixham
270649 by: Shawn McKenzie
270650 by: Robert Cummings
270651 by: Eric Butera
270652 by: Nathan Rixham
270653 by: Shawn McKenzie
270654 by: Ray Hauge
270655 by: TG
270656 by: TG
270657 by: Eric Butera
270658 by: TG
270659 by: Greg Donald
270660 by: Eric Butera
270661 by: Robert Cummings
270662 by: TG
270664 by: Wolf
270666 by: Nathan Rixham
Hot job opportunity - Sr. Software Developer/Architect
270598 by: Nick Gasparro
270601 by: Nathan Rixham
270603 by: Nathan Nobbe
270604 by: Nathan Rixham
270605 by: Daniel Brown
270610 by: Robert Cummings
Re: Traverse directory - Find empty directory
270620 by: Jim Lucas
echo returnArray()['a']; // workaround
270626 by: Nathan Nobbe
270639 by: Ray Hauge
270641 by: Nathan Nobbe
270644 by: Eric Butera
270663 by: Jim Lucas
270665 by: Nathan Rixham
Re: Choose Your Common Design Patterns
270635 by: Wolf
Re: Cannot even come up with the beginning of a regex
270638 by: Dotan Cohen
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
On 28 Feb 2008, at 11:39, Jochem Maas wrote:
> I can't seem to manage to buffer output (of an included file) in a
> CLI script,
> the following does not work:
>
>
> // buffer output so we can avoid the shebang line
> being output (and strip it from the output we log)
> $oldIFvalue = ini_set('implicit_flush', false);
> ob_start();
>
> if (!include $script) {
> ob_end_clean();
> } else {
> $output = explode("\n", ob_get_clean());
> if ($output[0] && preg_match('%^#!\/%',
> $output[0]))
> unset($output[0]);
> }
>
> ini_set('implicit_flush', $oldIFvalue);
>
>
> the reason I'm wanting to do this is, primarily, in order to stop
> the shebang line that *may*
> be present in the included script from being output to stdout.
On my local machine here PHP does not output the shebang line. AFAIK
it detects and strips it at the compilation phase. Have you tried it?
-Stut
--
http://stut.net/
attached mail follows:
On 28 Feb 2008, at 11:52, Stut wrote:
> On 28 Feb 2008, at 11:39, Jochem Maas wrote:
>> I can't seem to manage to buffer output (of an included file) in a
>> CLI script,
>> the following does not work:
>>
>>
>> // buffer output so we can avoid the shebang line
>> being output (and strip it from the output we log)
>> $oldIFvalue = ini_set('implicit_flush', false);
>> ob_start();
>>
>> if (!include $script) {
>> ob_end_clean();
>> } else {
>> $output = explode("\n", ob_get_clean());
>> if ($output[0] && preg_match('%^#!\/%',
>> $output[0]))
>> unset($output[0]);
>> }
>>
>> ini_set('implicit_flush', $oldIFvalue);
>>
>>
>> the reason I'm wanting to do this is, primarily, in order to stop
>> the shebang line that *may*
>> be present in the included script from being output to stdout.
>
> On my local machine here PHP does not output the shebang line. AFAIK
> it detects and strips it at the compilation phase. Have you tried it?
Hang on, ignore that. You're including the file, not running it on the
CLI.
What do you mean when you say it doesn't work? Do you mean you get no
output?
I suggest you remove the at the start of the include while
developing it. Or alternatively spit something out after you call
ob_end_clean so you know it couldn't include the file.
-Stut
--
http://stut.net/
attached mail follows:
Andrés Robinet schreef:
>> -----Original Message-----
>> From: Jochem Maas [mailto:jochemiamjochem.com]
>> Sent: Thursday, February 28, 2008 6:39 AM
>> To: [php] PHP General List
>> Subject: [PHP] output buffering in CLI script.
>>
>> hi there,
>>
>> I can't seem to manage to buffer output (of an included file) in a CLI
>> script,
>> the following does not work:
>>
>>
>> // buffer output so we can avoid the shebang line
>> being output (and strip it from the output we log)
>> $oldIFvalue = ini_set('implicit_flush', false);
>> ob_start();
>>
>> if (!include $script) {
>> ob_end_clean();
>> } else {
>> $output = explode("\n", ob_get_clean());
>> if ($output[0] && preg_match('%^#!\/%',
>> $output[0]))
>> unset($output[0]);
>> }
>>
>> ini_set('implicit_flush', $oldIFvalue);
>>
>>
>> the reason I'm wanting to do this is, primarily, in order to stop the
>> shebang line that *may*
>> be present in the included script from being output to stdout.
>>
>> --
>
> Aren't you deleting the output when you do ob_get_clean?
> Meaning, you are missing an echo of the captured buffer, like:
>
> $output = explode("\n", ob_get_clean());
> if ($output[0] && preg_match('%^#!\/%', $output[0]))
> unset($output[0]);
> echo join("\n", $output); // You need to echo this, since you lost your buffer
> by doing ob_get_clean
I'm retrieving the output buffer and shoving it in $output - which is
subsequently logged to a file. but output is not being buffered at all regardless
of implicit_flush setting and/or use of ob_start()
:-(
>
> Regards,
>
> 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: infobestplace.net | MSN Chat: bestbestplace.net | SKYPE: bestplace |
> Web: bestplace.biz | Web: seo-diy.com
>
attached mail follows:
Stut schreef:
> On 28 Feb 2008, at 11:39, Jochem Maas wrote:
>> I can't seem to manage to buffer output (of an included file) in a CLI
>> script,
>> the following does not work:
>>
>>
>> // buffer output so we can avoid the shebang line
>> being output (and strip it from the output we log)
>> $oldIFvalue = ini_set('implicit_flush', false);
>> ob_start();
>>
>> if (!include $script) {
>> ob_end_clean();
>> } else {
>> $output = explode("\n", ob_get_clean());
>> if ($output[0] && preg_match('%^#!\/%',
>> $output[0]))
>> unset($output[0]);
>> }
>>
>> ini_set('implicit_flush', $oldIFvalue);
>>
>>
>> the reason I'm wanting to do this is, primarily, in order to stop the
>> shebang line that *may*
>> be present in the included script from being output to stdout.
>
> On my local machine here PHP does not output the shebang line. AFAIK it
> detects and strips it at the compilation phase. Have you tried it?
I have, I actually wrote the code assuming that the shebang line is
ignored (as I had experienced and read about ages ago), I was surprised
to see the shebang line output in the shell ... so I figured I'd just
buffer and strip the line manually given that php decided to treat the shebang
line as regular output when it's the first line of an *included* file ...
but no joy on getting output buffering to work in the shell, STFW didn't do it
for me either, so now I'm hassling you guys :-)
obviously the shebang line doesn't get output if I run said script directly
(or by using exec) ... and yes I need to be able to do it both ways :-)
>
> -Stut
>
attached mail follows:
Stuart Dallas schreef:
> On 28 Feb 2008, at 11:52, Stut wrote:
>> On 28 Feb 2008, at 11:39, Jochem Maas wrote:
>>> I can't seem to manage to buffer output (of an included file) in a
>>> CLI script,
>>> the following does not work:
>>>
>>>
>>> // buffer output so we can avoid the shebang line
>>> being output (and strip it from the output we log)
>>> $oldIFvalue = ini_set('implicit_flush', false);
>>> ob_start();
>>>
>>> if (!include $script) {
>>> ob_end_clean();
>>> } else {
>>> $output = explode("\n", ob_get_clean());
>>> if ($output[0] && preg_match('%^#!\/%',
>>> $output[0]))
>>> unset($output[0]);
>>> }
>>>
>>> ini_set('implicit_flush', $oldIFvalue);
>>>
>>>
>>> the reason I'm wanting to do this is, primarily, in order to stop the
>>> shebang line that *may*
>>> be present in the included script from being output to stdout.
>>
>> On my local machine here PHP does not output the shebang line. AFAIK
>> it detects and strips it at the compilation phase. Have you tried it?
>
> Hang on, ignore that. You're including the file, not running it on the CLI.
>
> What do you mean when you say it doesn't work? Do you mean you get no
> output?
I mean that the shebang line at the top of the included file is output
to stdout even when I turn on output buffering on prior to including the file.
nothing else is output but that's because the script doesn't generate any further
output - it logs everything instead - and I know it runs because the relevant lines
appear in the relevant log file.
>
> I suggest you remove the at the start of the include while developing
> it. Or alternatively spit something out after you call ob_end_clean so
> you know it couldn't include the file.
the is niether here nor there with regard to the problem I have, well more
of an annoyance - nobody is going get hurt by some spurious output to stdout but
it looks messy.
just to clarify - I need to be able to run the script directly (as an executable) and
be able to include it within another script ... so the shebang line is needed
(well I could hack around it with a wrapper script to use directly on the command line
or run it using /usr/bin/php foo.php ... but I don't find either of those satisfactory)
>
> -Stut
>
attached mail follows:
Jochem Maas wrote:
> Stut schreef:
>> On 28 Feb 2008, at 11:39, Jochem Maas wrote:
>>> I can't seem to manage to buffer output (of an included file) in a
>>> CLI script,
>>> the following does not work:
>>>
>>>
>>> // buffer output so we can avoid the shebang line
>>> being output (and strip it from the output we log)
>>> $oldIFvalue = ini_set('implicit_flush', false);
>>> ob_start();
>>>
>>> if (!include $script) {
>>> ob_end_clean();
>>> } else {
>>> $output = explode("\n", ob_get_clean());
>>> if ($output[0] && preg_match('%^#!\/%',
>>> $output[0]))
>>> unset($output[0]);
>>> }
>>>
>>> ini_set('implicit_flush', $oldIFvalue);
>>>
>>>
>>> the reason I'm wanting to do this is, primarily, in order to stop the
>>> shebang line that *may*
>>> be present in the included script from being output to stdout.
>>
>> On my local machine here PHP does not output the shebang line. AFAIK
>> it detects and strips it at the compilation phase. Have you tried it?
>
> I have, I actually wrote the code assuming that the shebang line is
> ignored (as I had experienced and read about ages ago), I was surprised
> to see the shebang line output in the shell ... so I figured I'd just
> buffer and strip the line manually given that php decided to treat the
> shebang
> line as regular output when it's the first line of an *included* file ...
> but no joy on getting output buffering to work in the shell, STFW didn't
> do it
> for me either, so now I'm hassling you guys :-)
>
> obviously the shebang line doesn't get output if I run said script directly
> (or by using exec) ... and yes I need to be able to do it both ways :-)
>
>>
>> -Stut
>>
bit of false logic here but have you tried:
eval(ltrim(file_get_contents($script),$shebang));
attached mail follows:
On 28 Feb 2008, at 12:29, Jochem Maas wrote:
> Stuart Dallas schreef:
>> On 28 Feb 2008, at 11:52, Stut wrote:
>>> On 28 Feb 2008, at 11:39, Jochem Maas wrote:
>>>> I can't seem to manage to buffer output (of an included file) in
>>>> a CLI script,
>>>> the following does not work:
>>>>
>>>>
>>>> // buffer output so we can avoid the shebang
>>>> line being output (and strip it from the output we log)
>>>> $oldIFvalue = ini_set('implicit_flush', false);
>>>> ob_start();
>>>>
>>>> if (!include $script) {
>>>> ob_end_clean();
>>>> } else {
>>>> $output = explode("\n", ob_get_clean());
>>>> if ($output[0] && preg_match('%^#!\/%',
>>>> $output[0]))
>>>> unset($output[0]);
>>>> }
>>>>
>>>> ini_set('implicit_flush', $oldIFvalue);
>>>>
>>>>
>>>> the reason I'm wanting to do this is, primarily, in order to stop
>>>> the shebang line that *may*
>>>> be present in the included script from being output to stdout.
This works...
----<test.php>----
#!/usr/bin/php
<?php
echo "arse\n";
echo Inc('testinc.php');
function & Inc($f)
{
ob_start();
include($f);
$content = ob_get_contents();
ob_end_clean();
if (substr($content, 0, 2) == '#!')
{
$content = substr($content, strpos($content, "\n")+1);
}
return $content;
}
----</test.php>----
----<testinc.php>----
#!/usr/bin/php
<?php
echo "testinc\n";
----</testinc.php>----
----<output>----
StutGiles:~$ ./test.php
arse
testinc
----</output>----
-Stut
--
http://stut.net/
attached mail follows:
Jochem Maas wrote:
> I mean that the shebang line at the top of the included file is output
> to stdout even when I turn on output buffering on prior to including
> the file.
>
> nothing else is output but that's because the script doesn't generate
> any further
> output - it logs everything instead - and I know it runs because the
> relevant lines
> appear in the relevant log file.
I don't know what goes wrong here. I took your script and it just works,
so it is not your code (I guess).
I've done this:
$oldIFvalue = ini_set('implicit_flush', false);
ob_start();
if (!include 'scrap2.php') {
ob_end_clean();
}
else {
$output = explode("\n", ob_get_clean());
if ($output[0] && preg_match('%^#!%', $output[0]))
unset($output[0]);
echo implode("\n", $output);
}
ini_set('implicit_flush', $oldIFvalue);
The only difference is it echoes imploded $output. And I do a bit
different preg_match ^#! instead of ^#!\/
If you can include the script you want to include, than it should work.
If you can buffer output without the include file, than it should work.
If you can dump $output after you've done the explode, than it should work.
So, I don't know what goes wrong.
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
Nathan Rixham schreef:
> Jochem Maas wrote:
...
>>>
>>> -Stut
>>>
>
> bit of false logic here but have you tried:
>
> eval(ltrim(file_get_contents($script),$shebang));
haven't tried it, did consider it. I hate eval() :-)
>
attached mail follows:
On 28 Feb 2008, at 11:40, Aschwin Wesselius wrote:
> Stut wrote:
>> On 28 Feb 2008, at 11:30, Aschwin Wesselius wrote:
>>> Shelley wrote:
>>>> Hi all,
>>>>
>>>> What do you think is the best way to display string 'abcdef' as
>>>> 'fedcba'?
>>>
>>>
>>> $tmp = '';
>>> $str = 'abcdef';
>>>
>>> for ($i = strlen($str); $i >= 0; $i--) {
>>>
>>> $tmp.= $str[$i];
>>> }
>>>
>>> echo $tmp;
>>
>> Close, but no cigar. $i should be initialised to strlen($str)-1
>> otherwise you start one character beyond the end of the string.
>
>
> Ah, well. You're right, but it works none the less.
Just because it works doesn't mean it's right.
-Stut
--
http://stut.net/
attached mail follows:
Stut wrote:
> Just because it works doesn't mean it's right.
>
> -Stut
>
What I meant was that I tested the script and it worked, so I didn't
spot the flaw (wich is obvious and you were right).
No big deal.
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
Aschwin Wesselius wrote:
> Stut wrote:
>> Just because it works doesn't mean it's right.
>>
>> -Stut
>>
>
>
> What I meant was that I tested the script and it worked, so I didn't
> spot the flaw (wich is obvious and you were right).
>
> No big deal.
>
should it not use curlies?
$tmp = '';
$str = 'abcdef';
for ($i = strlen($str)-1; $i >= 0; $i--) {
$tmp.= $str{$i};
}
echo $tmp;
here's the "overkill" way to do it:
$str = 'abcdef';
$rev = implode(array_flip(array_reverse(array_flip(str_split($str)))));
echo $rev;
*sniggers*
attached mail follows:
Nathan Rixham wrote:
> should it not use curlies?
I don't know. What is the leading preference nowadays? Does it matter?
Somewhere in the past I learned it with the square brackets like an
array and it still works like that. Maybe it isn't 'right' (Stut?), but
that is the way I picked it up.
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
On 28 February 2008 12:39, Nathan Rixham advised:
> should it not use curlies?
No, they will be deprecated as of PHP6. (Square brackets used to be, but
have been undeprecated and are back in favour!)
>
> $tmp = '';
> $str = 'abcdef';
> for ($i = strlen($str)-1; $i >= 0; $i--) {
> $tmp.= $str{$i};
> }
> echo $tmp;
Cheers!
--
Mike Ford, Electronic Information Services Adviser,
JG125, The Headingley Library,
James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: m.fordleedsmet.ac.uk
Tel: +44 113 812 4730 Fax: +44 113 812 3211
To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
attached mail follows:
Ford, Mike wrote:
> On 28 February 2008 12:39, Nathan Rixham advised:
>
>
>> should it not use curlies?
>
> No, they will be deprecated as of PHP6. (Square brackets used to be, but
> have been undeprecated and are back in favour!)
>
>> $tmp = '';
>> $str = 'abcdef';
>> for ($i = strlen($str)-1; $i >= 0; $i--) {
>> $tmp.= $str{$i};
>> }
>> echo $tmp;
>
> Cheers!
>
> --
> Mike Ford, Electronic Information Services Adviser,
> JG125, The Headingley Library,
> James Graham Building, Leeds Metropolitan University,
> Headingley Campus, LEEDS, LS6 3QS, United Kingdom
> Email: m.fordleedsmet.ac.uk
> Tel: +44 113 812 4730 Fax: +44 113 812 3211
>
>
> To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
cheers for the heads up on curlies Mike :)
attached mail follows:
> >> should it not use curlies?
> > No, they will be deprecated as of PHP6. (Square brackets used to be, but
> > have been undeprecated and are back in favour!)
> cheers for the heads up on curlies Mike :)
Where can I read more information about this?
thnx,
Chris
attached mail follows:
On Thu, 2008-02-28 at 12:39 +0000, Nathan Rixham wrote:
> Aschwin Wesselius wrote:
> > Stut wrote:
> >> Just because it works doesn't mean it's right.
> >>
> >> -Stut
> >>
> >
> >
> > What I meant was that I tested the script and it worked, so I didn't
> > spot the flaw (wich is obvious and you were right).
> >
> > No big deal.
> >
>
> should it not use curlies?
>
> $tmp = '';
> $str = 'abcdef';
> for ($i = strlen($str)-1; $i >= 0; $i--) {
> $tmp.= $str{$i};
> }
> echo $tmp;
>
>
> here's the "overkill" way to do it:
>
> $str = 'abcdef';
> $rev = implode(array_flip(array_reverse(array_flip(str_split($str)))));
> echo $rev;
>
> *sniggers*
There's always a tradeoff between speed and memory. Here's the low
memory version:
<?php
$str = '1234567';
str_reverse_in_place( $str );
echo 'Reversed: '.$str."\n";
function str_reverse_in_place( &$str )
{
$a = 0;
$z = strlen( $str ) - 1;
while( $a < $z )
{
$t = $str[$a];
$str[$a] = $str[$z];
$str[$z] = $t;
++$a;
--$z;
}
}
?>
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. |
`------------------------------------------------------------'
attached mail follows:
Robert Cummings wrote:
> There's always a tradeoff between speed and memory. Here's the low
> memory version:
>
> <?php
>
> $str = '1234567';
> str_reverse_in_place( $str );
> echo 'Reversed: '.$str."\n";
>
> function str_reverse_in_place( &$str )
> {
> $a = 0;
> $z = strlen( $str ) - 1;
>
> while( $a < $z )
> {
> $t = $str[$a];
> $str[$a] = $str[$z];
> $str[$z] = $t;
>
> ++$a;
> --$z;
> }
> }
>
> ?>
>
Sorry, Rob, that function doesn't return anything..... ;-)
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
Aschwin Wesselius wrote:
> Sorry, Rob, that function doesn't return anything..... ;-)
Bugger, it's getting late. Didn't see the &.....
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
On Thu, 2008-02-28 at 16:39 +0100, Aschwin Wesselius wrote:
> Aschwin Wesselius wrote:
> > Sorry, Rob, that function doesn't return anything..... ;-)
>
>
> Bugger, it's getting late. Didn't see the &.....
It wouldn't really be "in place" if it wasn't a reference. Since the
engine would immediately perform a copy on the first write to a passed
non reference string :)
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. |
`------------------------------------------------------------'
attached mail follows:
> Sorry, Rob, that function doesn't return anything..... ;-)
It's not meant to:
<?php
// ...
$str = '123';
str_reverse_in_place($str);
echo $str;
?>
--
Richard Heyes
Employ me (!):
http://www.phpguru.org/cv
attached mail follows:
Robert Cummings wrote:
> It wouldn't really be "in place" if it wasn't a reference. Since the
> engine would immediately perform a copy on the first write to a passed
> non reference string :)
>
Still to much to learn..... Nice list to learn from.... thanks.
I just started to learn more and more about C syntax and solutions,
where a lot of optimization and tradeoffs is made. Memory, speed,
filesystem access etc.
I had to look twice before I understood what you did with the shuffle.
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
On 28/02/2008, Robert Cummings <robertinterjinn.com> wrote:
>
> On Thu, 2008-02-28 at 12:39 +0000, Nathan Rixham wrote:
> > Aschwin Wesselius wrote:
> > > Stut wrote:
> > >> Just because it works doesn't mean it's right.
> > >>
> > >> -Stut
> > >>
> > >
> > >
> > > What I meant was that I tested the script and it worked, so I didn't
> > > spot the flaw (wich is obvious and you were right).
> > >
> > > No big deal.
> > >
> >
> > should it not use curlies?
> >
> > $tmp = '';
> > $str = 'abcdef';
> > for ($i = strlen($str)-1; $i >= 0; $i--) {
> > $tmp.= $str{$i};
> > }
> > echo $tmp;
> >
> >
> > here's the "overkill" way to do it:
> >
> > $str = 'abcdef';
> > $rev = implode(array_flip(array_reverse(array_flip(str_split($str)))));
> > echo $rev;
> >
> > *sniggers*
>
>
> There's always a tradeoff between speed and memory. Here's the low
> memory version:
>
> <?php
>
> $str = '1234567';
> str_reverse_in_place( $str );
> echo 'Reversed: '.$str."\n";
>
> function str_reverse_in_place( &$str )
> {
> $a = 0;
> $z = strlen( $str ) - 1;
>
> while( $a < $z )
> {
> $t = $str[$a];
> $str[$a] = $str[$z];
> $str[$z] = $t;
>
> ++$a;
> --$z;
> }
> }
>
> ?>
every byte counts :-)
function str_reverse_in_place( &$str )
{
$a = -1;
$z = strlen($str);
while( ++$a < --$z )
{
$str[$a] = $str[$a] ^ $str[$z];
$str[$z] = $str[$a] ^ $str[$z];
$str[$a] = $str[$a] ^ $str[$z];
}
}
attached mail follows:
On Thu, 2008-02-28 at 16:26 +0000, Robin Vickery wrote:
> On 28/02/2008, Robert Cummings <robertinterjinn.com> wrote:
> >
> > There's always a tradeoff between speed and memory. Here's the low
> > memory version:
> >
> > <?php
> >
> > $str = '1234567';
> > str_reverse_in_place( $str );
> > echo 'Reversed: '.$str."\n";
> >
> > function str_reverse_in_place( &$str )
> > {
> > $a = 0;
> > $z = strlen( $str ) - 1;
> >
> > while( $a < $z )
> > {
> > $t = $str[$a];
> > $str[$a] = $str[$z];
> > $str[$z] = $t;
> >
> > ++$a;
> > --$z;
> > }
> > }
> >
> > ?>
>
>
> every byte counts :-)
>
> function str_reverse_in_place( &$str )
> {
> $a = -1;
> $z = strlen($str);
>
> while( ++$a < --$z )
> {
> $str[$a] = $str[$a] ^ $str[$z];
> $str[$z] = $str[$a] ^ $str[$z];
> $str[$a] = $str[$a] ^ $str[$z];
> }
> }
>
Nicely done.
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. |
`------------------------------------------------------------'
attached mail follows:
Dear Sir/Madam,
Please I would be grateful if you could remove my e-mail address: tasieduieee.org from the general Mailing List.
I look forward to having a favourable response from you. Thank you.
Best regards,
Timothy Asiedu.
Stut <stuttlegmail.com> wrote:
On 27 Feb 2008, at 21:50, Shawn McKenzie wrote:
> Shawn McKenzie wrote:
>> Stut wrote:
>>> I've interviewed more than my fair share of "web developers" who
>>> couldn't reverse an array without using array_reverse if their life
>>> depended on it. Sometimes it really does scare me!
>>>
>>> So my experience is that there are far more web developers out there
>>> than software engineers who do web development, and it's getting
>>> harder
>>> to find decent software engineers to do web-based work at a
>>> reasonable
>>> price. The good ones are rare - so rare in fact that I'm having
>>> trouble
>>> finding one at the moment. If anyone considers themselves a software
>>> engineer rather than a web developer and would like a job in Windsor
>>> drop me a note.
>>>
>> Job! Now!
>>
>> foreach($array as $k => $v) {
>> $reversed[$v] = $k;
>> }
>> $array = $reversed; //optional
> No wait!
Yeah, nice try ;)
Anyways, I assume you're based in the US somewhere so unless you're
considering emigrating to the UK you were never in the running.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
---------------------------------
Never miss a thing. Make Yahoo your homepage.
attached mail follows:
On 28 Feb 2008, at 12:15, Timothy Asiedu wrote:
> Please I would be grateful if you could remove my e-mail address: tasieduieee.org
> from the general Mailing List.
Unsubscribe instructions are in the footer of every email you receive
from this list. Follow them to get your favourable response.
> To unsubscribe, visit: http://www.php.net/unsub.php
-Stut
--
http://stut.net/
attached mail follows:
Stut schreef:
> On 28 Feb 2008, at 12:15, Timothy Asiedu wrote:
>> Please I would be grateful if you could remove my e-mail address:
>> tasieduieee.org from the general Mailing List.
>
> Unsubscribe instructions are in the footer of every email you receive
> from this list. Follow them to get your favourable response.
lol ... who gave him a ieee.org address in the first place :-)
>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> -Stut
>
attached mail follows:
Go to:
http://php.net/mailing-lists.php
-----Mensagem original-----
De: Timothy Asiedu [mailto:tasiedu123yahoo.com]
Enviada em: quinta-feira, 28 de fevereiro de 2008 09:16
Para: Stut; php-generallists.php.net
Cc: tasieduieee.org
Assunto: Re: [PHP] Guidance
Dear Sir/Madam,
Please I would be grateful if you could remove my e-mail address:
tasieduieee.org from the general Mailing List.
I look forward to having a favourable response from you. Thank you.
Best regards,
Timothy Asiedu.
Stut <stuttlegmail.com> wrote:
On 27 Feb 2008, at 21:50, Shawn McKenzie wrote:
> Shawn McKenzie wrote:
>> Stut wrote:
>>> I've interviewed more than my fair share of "web developers" who
>>> couldn't reverse an array without using array_reverse if their life
>>> depended on it. Sometimes it really does scare me!
>>>
>>> So my experience is that there are far more web developers out there
>>> than software engineers who do web development, and it's getting
>>> harder to find decent software engineers to do web-based work at a
>>> reasonable price. The good ones are rare - so rare in fact that I'm
>>> having trouble finding one at the moment. If anyone considers
>>> themselves a software engineer rather than a web developer and would
>>> like a job in Windsor drop me a note.
>>>
>> Job! Now!
>>
>> foreach($array as $k => $v) {
>> $reversed[$v] = $k;
>> }
>> $array = $reversed; //optional
> No wait!
Yeah, nice try ;)
Anyways, I assume you're based in the US somewhere so unless you're
considering emigrating to the UK you were never in the running.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
---------------------------------
Never miss a thing. Make Yahoo your homepage.
attached mail follows:
2008. 02. 28, csütörtök keltezéssel 04.15-kor Timothy Asiedu ezt Ãrta:
> Dear Sir/Madam,
>
> Please I would be grateful if you could remove my e-mail address: tasieduieee.org from the general Mailing List.
>
> I look forward to having a favourable response from you. Thank you.
remove yourself. look at the bottom of this message.
greets,
Zoltán Németh
>
>
> Best regards,
>
>
> Timothy Asiedu.
>
>
>
> Stut <stuttlegmail.com> wrote:
> On 27 Feb 2008, at 21:50, Shawn McKenzie wrote:
> > Shawn McKenzie wrote:
> >> Stut wrote:
> >>> I've interviewed more than my fair share of "web developers" who
> >>> couldn't reverse an array without using array_reverse if their life
> >>> depended on it. Sometimes it really does scare me!
> >>>
> >>> So my experience is that there are far more web developers out there
> >>> than software engineers who do web development, and it's getting
> >>> harder
> >>> to find decent software engineers to do web-based work at a
> >>> reasonable
> >>> price. The good ones are rare - so rare in fact that I'm having
> >>> trouble
> >>> finding one at the moment. If anyone considers themselves a software
> >>> engineer rather than a web developer and would like a job in Windsor
> >>> drop me a note.
> >>>
> >> Job! Now!
> >>
> >> foreach($array as $k => $v) {
> >> $reversed[$v] = $k;
> >> }
> >> $array = $reversed; //optional
> > No wait!
>
> Yeah, nice try ;)
>
> Anyways, I assume you're based in the US somewhere so unless you're
> considering emigrating to the UK you were never in the running.
>
> -Stut
>
> --
> http://stut.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> ---------------------------------
> Never miss a thing. Make Yahoo your homepage.
attached mail follows:
On Thu, Feb 28, 2008 at 7:32 AM, Jochem Maas <jochemiamjochem.com> wrote:
> Stut schreef:
>
> > On 28 Feb 2008, at 12:15, Timothy Asiedu wrote:
> >> Please I would be grateful if you could remove my e-mail address:
> >> tasieduieee.org from the general Mailing List.
> >
> > Unsubscribe instructions are in the footer of every email you receive
> > from this list. Follow them to get your favourable response.
>
> lol ... who gave him a ieee.org address in the first place :-)
>
Considering his message came from a Yahoo address?
attached mail follows:
Stuart Dallas schreef:
> On 28 Feb 2008, at 12:29, Jochem Maas wrote:
>> Stuart Dallas schreef:
>>> On 28 Feb 2008, at 11:52, Stut wrote:
>>>> On 28 Feb 2008, at 11:39, Jochem Maas wrote:
>>>>> I can't seem to manage to buffer output (of an included file) in a
>>>>> CLI script,
>>>>> the following does not work:
>>>>>
>>>>>
>>>>> // buffer output so we can avoid the shebang line
>>>>> being output (and strip it from the output we log)
>>>>> $oldIFvalue = ini_set('implicit_flush', false);
>>>>> ob_start();
>>>>>
>>>>> if (!include $script) {
>>>>> ob_end_clean();
>>>>> } else {
>>>>> $output = explode("\n", ob_get_clean());
>>>>> if ($output[0] && preg_match('%^#!\/%',
>>>>> $output[0]))
>>>>> unset($output[0]);
>>>>> }
>>>>>
>>>>> ini_set('implicit_flush', $oldIFvalue);
>>>>>
>>>>>
>>>>> the reason I'm wanting to do this is, primarily, in order to stop
>>>>> the shebang line that *may*
>>>>> be present in the included script from being output to stdout.
>
> This works...
>
indeed ... I tested it and it works on my server too. my code is no different
to yours with regard to the context of the problem. so what's going on.
I think (I know) I forgot to mention one tiny little detail.
the whole 'include' code occurs in a script that forks itself ...
the script forks itself a number of times and each child then performs
the include.
so I tested the fork issue with your script ... it still bloody works,
(see the for loop below) so it's something else ... I thought it might
be the difference between using ob_get_clean() and ob_get_contents()+ob_end_clean()
but that doesn't seem to be it either.
the worse thing is my script has just stopped outputting the shebang lines of
the included script(s) ... oh well ... the problem is solved, dunno how, dunno why,
situations like these I'd rather the problem didn't go away .. I prefer to know
wtf happened!
> ----<test.php>----
> #!/usr/bin/php
> <?php
> echo "arse\n";
for ($i = 0; $i < 3; $i++) {
$pid = pcntl_fork();
if ($pid == 0) {
echo Inc('testinc.php');
exit;
}
}
>
> function & Inc($f)
> {
> ob_start();
> include($f);
> $content = ob_get_contents();
> ob_end_clean();
> if (substr($content, 0, 2) == '#!')
> {
> $content = substr($content, strpos($content, "\n")+1);
> }
> return $content;
> }
> ----</test.php>----
>
> ----<testinc.php>----
> #!/usr/bin/php
> <?php
> echo "testinc\n";
> ----</testinc.php>----
>
> ----<output>----
> StutGiles:~$ ./test.php
> arse
> testinc
> ----</output>----
>
> -Stut
>
attached mail follows:
how's this?
#!/usr/bin/php
<?php
class trimshebang {
function filter($in, $out, &$consumed, $closing)
{
while ($bucket = stream_bucket_make_writeable($in)) {
$bucket->data = ltrim($bucket->data,"#!/usr/bin/php\n");
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
stream_filter_register("trim.shebang", "trimshebang");
include "php://filter/read=trim.shebang/resource=/path/to/include.php";
?>
bit more graceful ;)
attached mail follows:
Nathan Rixham wrote:
> how's this?
>
> #!/usr/bin/php
> <?php
> class trimshebang {
> function filter($in, $out, &$consumed, $closing)
> {
> while ($bucket = stream_bucket_make_writeable($in)) {
> $bucket->data = ltrim($bucket->data,"#!/usr/bin/php\n");
> $consumed += $bucket->datalen;
> stream_bucket_append($out, $bucket);
> }
> return PSFS_PASS_ON;
> }
> }
>
> stream_filter_register("trim.shebang", "trimshebang");
> include "php://filter/read=trim.shebang/resource=/path/to/include.php";
> ?>
>
> bit more graceful ;)
>
Me thinks that when shebang doesn't fit /usr/bin/php (which happens
sometimes) you're doomed.....
But it still is a nice example.
--
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
attached mail follows:
Aschwin Wesselius wrote:
>
> Me thinks that when shebang doesn't fit /usr/bin/php (which happens
> sometimes) you're doomed.....
[snip]
good point.. modified to use BINDIR:
#!/usr/bin/php
<?php
class trimshebang {
function filter($in, $out, &$consumed, $closing)
{
while ($bucket = stream_bucket_make_writeable($in)) {
$bucket->data = ltrim($bucket->data,"#!".PHP_BINDIR."/php\n");
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
stream_filter_register("trim.shebang", "trimshebang");
include "php://filter/read=trim.shebang/resource=/path/to/include.php";
?>
> But it still is a nice example.
thanks :)
attached mail follows:
Nathan Rixham schreef:
> how's this?
>
> #!/usr/bin/php
> <?php
> class trimshebang {
> function filter($in, $out, &$consumed, $closing)
> {
> while ($bucket = stream_bucket_make_writeable($in)) {
> $bucket->data = ltrim($bucket->data,"#!/usr/bin/php\n");
> $consumed += $bucket->datalen;
> stream_bucket_append($out, $bucket);
> }
> return PSFS_PASS_ON;
> }
> }
>
> stream_filter_register("trim.shebang", "trimshebang");
> include "php://filter/read=trim.shebang/resource=/path/to/include.php";
> ?>
>
> bit more graceful ;)
it's sick, I like it, nice example of streams filtering while your at it.
I learned something! it also works in so far that the shebang line is no longer
output but the output buffering in *my* script(s) doesn't work, whilst the same
construction does work in Stut's test scripts (although whilst playing with
his script I did manage to bork ik so that the output buffering *doesn't* work
there anymore ... how I did that I can't fathom)
anyway - they problem has been nicely shoved under the carpet. apart from
the shebang lines the script don't ever output anything anyway but rather
log to files ... a simple redirect output to /dev/null in the command line
that is used to run the 'master' script will take care of any spurious cruft
ending up on screen.
thanks to everyone for their input regarding my output! :-)
>
attached mail follows:
Jochem Maas schreef:
...
>
> indeed ... I tested it and it works on my server too. my code is no
> different
> to yours with regard to the context of the problem. so what's going on.
>
> I think (I know) I forgot to mention one tiny little detail.
> the whole 'include' code occurs in a script that forks itself ...
> the script forks itself a number of times and each child then performs
> the include.
>
> so I tested the fork issue with your script ... it still bloody works,
> (see the for loop below) so it's something else ... I thought it might
> be the difference between using ob_get_clean() and
> ob_get_contents()+ob_end_clean()
> but that doesn't seem to be it either.
>
> the worse thing is my script has just stopped outputting the shebang
> lines of
> the included script(s) ... oh well ... the problem is solved, dunno how,
> dunno why,
>
> situations like these I'd rather the problem didn't go away .. I prefer
> to know
> wtf happened!
wtf happened was I was looking at the wrong output. I changed my code to
be as much like your test code as possible (to the point that I now
use a function to perform the buffering and 'include' and returning output) ...
the output buffering is not working at all.
I've had enough - /dev/null meet script output, output meet /dev/null
>
>> ----<test.php>----
>> #!/usr/bin/php
>> <?php
>> echo "arse\n";
>
> for ($i = 0; $i < 3; $i++) {
> $pid = pcntl_fork();
> if ($pid == 0) {
> echo Inc('testinc.php');
> exit;
> }
> }
>
>>
>> function & Inc($f)
>> {
>> ob_start();
>> include($f);
>> $content = ob_get_contents();
>> ob_end_clean();
>> if (substr($content, 0, 2) == '#!')
>> {
>> $content = substr($content, strpos($content, "\n")+1);
>> }
>> return $content;
>> }
>> ----</test.php>----
>>
>> ----<testinc.php>----
>> #!/usr/bin/php
>> <?php
>> echo "testinc\n";
>> ----</testinc.php>----
>>
>> ----<output>----
>> StutGiles:~$ ./test.php
>> arse
>> testinc
>> ----</output>----
>>
>> -Stut
>>
>
attached mail follows:
At 8:57 AM +0100 2/28/08, Zoltán Németh wrote:
>2008. 02. 27, szerda keltezéssel 14.02-kor tedd ezt írta:
> > Just about all my code was reduced to functions
>> and all functions were placed in files according
>> theme. My "main" was probably less than 50 lines
>> of code.
>
>this is absolutely similar to a well-organized class structure, just
>replace 'file' with 'class' :)
and
>well, if classes are not convenient for you, then sure it would take
>more time but only for the first time. after that, my experience is that
>development time is less with classes
A rose by any other name.
Outside of being up on the current trend, I don't
see much difference -- just new paint on an old
thing. I've seen a couple of paint jobs over the
years. What I haven't seen is something that I
can't do with what I've got.
Classes only provide me with a different way to
organize my code. Sure you can cite data hiding,
inheritance, and polymorphism, but I didn't have
problems that required those before -- so why
should I worry about them now? (however,
polymorphism is cool).
Yes, it's kind of neat to make a class with it's
own variables and methods and set a level of
abstraction that permits you to not care what is
is used for, but I really do that with functions
anyway.
From my perspective, increasing complexity doesn't always make things simpler.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
Nathan Nobbe wrote:
> On Wed, Feb 27, 2008 at 10:31 PM, Shelley <myphplistgmail.com> wrote:
>
>> Greetings all,
>>
>> Im just need some guidance of how to prepare for the ZCE exam.
>>
>> Is there somebody passed the exam? Any help infor is highly appreciated.
>
>
> i read the php architect book and paid for 5 of their sample tests.
> http://www.phparch.com/c/books/id/0973862149
> some of the questions on the test are really obscure, not really like
> about the language as much as the set of functions that ship w/ it.
> they try and trip you up, like asking very specific questions about
> some of the functions and so forth.
> good news is a low score still makes the passing grade ;)
>
> -nathan
>
Same here. I read the practice book and took the Vulcan training tests.
http://www.phparch.com/c/product/vulcan/view
My work paid for an online training that got me both of them for free,
so I used them. The hardest part for me was just setting a date and
stop procrastinating. The test was easier than I was expecting, though
there were a few things that I didn't know on there. The tests were my
best training though.
--
Ray Hauge
www.primateapplications.com
attached mail follows:
Nathan Nobbe wrote:
> On Wed, Feb 27, 2008 at 10:31 PM, Shelley <myphplistgmail.com> wrote:
>
>> Greetings all,
>>
>> Im just need some guidance of how to prepare for the ZCE exam.
>>
>> Is there somebody passed the exam? Any help infor is highly appreciated.
>
>
> i read the php architect book and paid for 5 of their sample tests.
> http://www.phparch.com/c/books/id/0973862149
> some of the questions on the test are really obscure, not really like
> about the language as much as the set of functions that ship w/ it.
> they try and trip you up, like asking very specific questions about
> some of the functions and so forth.
> good news is a low score still makes the passing grade ;)
>
> -nathan
>
My SMTP server didn't like my login for a few minutes, so hopefully I
don't double-post this.
I used the book and the Vulcan Training tests as well. I think I got
more out of the tests than the book, but that's just me.
There were a lot of odd functions in there. I can't even remember the
ones that I didn't even know existed. There were also questions about
how to configure PHP, so look at the php.ini options as well.
--
Ray Hauge
www.primateapplications.com
attached mail follows:
-----Mensagem original-----
De: Ray Hauge [mailto:ray.hauge.listsgmail.com]
Enviada em: quinta-feira, 28 de fevereiro de 2008 11:23
Para: Nathan Nobbe
Cc: Shelley; php-generallists.php.net
Assunto: Re: [PHP] ZCE guidance needed
Same here. I read the practice book and took the Vulcan training tests.
http://www.phparch.com/c/product/vulcan/view
My work paid for an online training that got me both of them for free, so I
used them. The hardest part for me was just setting a date and stop
procrastinating. The test was easier than I was expecting, though there
were a few things that I didn't know on there. The tests were my best
training though.
---
I've been reading the ZCE FAQ and there says they will ask stuff about
regex. How much of regex do they ask about? I have to say I know very little
about this :)
--
Ray Hauge
www.primateapplications.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
On Thu, Feb 28, 2008 at 11:13 AM, Thiago Pojda <
thiago.pojdasoftpartech.com.br> wrote:
> -----Mensagem original-----
> De: Ray Hauge [mailto:ray.hauge.listsgmail.com]
> Enviada em: quinta-feira, 28 de fevereiro de 2008 11:23
> Para: Nathan Nobbe
> Cc: Shelley; php-generallists.php.net
> Assunto: Re: [PHP] ZCE guidance needed
>
> Same here. I read the practice book and took the Vulcan training tests.
>
> http://www.phparch.com/c/product/vulcan/view
>
> My work paid for an online training that got me both of them for free, so
> I
> used them. The hardest part for me was just setting a date and stop
> procrastinating. The test was easier than I was expecting, though there
> were a few things that I didn't know on there. The tests were my best
> training though.
>
> ---
>
> I've been reading the ZCE FAQ and there says they will ask stuff about
> regex. How much of regex do they ask about? I have to say I know very
> little
> about this :)
as far as i recall there wasnt a ton on it.
if you read through the study guide and take some of the sample tests you
should be in good shape.
-nathan
attached mail follows:
At 12:14 AM -0200 2/28/08, Manuel Barros Reyes wrote:
>The details are in that thread but basically what I am looking for is
>a shopping cart that has flexibility with respect to the graphical
>layout of elements and their appearance as well as the ability to
>extend the framework with custom functionalities.
Good luck. I haven't found any, yet.
All the shopping carts that I have seen make the mistake of allowing
the developer to think he's proficient in css, when it's usually
totally absent or horribly intermixed within html.
So in looking, ask how they incorporate css into their program. If
they go "Huh?", go somewhere else.
Actually, you can usually simplify that question by asking them if
they use a font tag. If they do, then they're clueless.
Oh, when you find something, please let me know.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
On Thu, Feb 28, 2008 at 9:26 AM, tedd <tedd.sperlinggmail.com> wrote:
> At 12:14 AM -0200 2/28/08, Manuel Barros Reyes wrote:
> >The details are in that thread but basically what I am looking for is
> >a shopping cart that has flexibility with respect to the graphical
> >layout of elements and their appearance as well as the ability to
> >extend the framework with custom functionalities.
>
> Good luck. I haven't found any, yet.
>
> All the shopping carts that I have seen make the mistake of allowing
> the developer to think he's proficient in css, when it's usually
> totally absent or horribly intermixed within html.
>
> So in looking, ask how they incorporate css into their program. If
> they go "Huh?", go somewhere else.
>
> Actually, you can usually simplify that question by asking them if
> they use a font tag. If they do, then they're clueless.
>
> Oh, when you find something, please let me know.
>
> 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
>
>
Magento is designed with css. But I know right now that you won't like it. ;)
Here is an example page:
http://svn.magentocommerce.com/source/branches/beta-0.8/app/design/frontend/default/default/template/catalog/product/list.phtml
attached mail follows:
On Thu, Feb 28, 2008 at 1:26 PM, Eric Butera <eric.buteragmail.com> wrote:
> Magento is designed with css. But I know right now that you won't like it. ;)
Because their server doesn't have PHP configured properly? ;-P
> Here is an example page:
> http://svn.magentocommerce.com/source/branches/beta-0.8/app/design/frontend/default/default/template/catalog/product/list.phtml
All I see is the PHP source. Beginning with:
<?php
/**
* Magento
*
* NOTICE OF LICENSE
*
* This source file is subject to the Open Software License (OSL 3.0)
* that is bundled with this package in the file LICENSE.txt.
* It is also available through the world-wide-web at this URL:
* http://opensource.org/licenses/osl-3.0.php
* If you did not receive a copy of the license and are unable to
* obtain it through the world-wide-web, please send an email
* to licensemagentocommerce.com so we can send you a copy immediately.
*
* category design_default
* package Mage
* copyright Copyright (c) 2004-2007 Irubin Consulting Inc. DBA
Varien (http://www.varien.com)
* license http://opensource.org/licenses/osl-3.0.php Open
Software License (OSL 3.0)
*/
?>
<?
/**
* Product list template
*
* see Mage_Catalog_Block_Product_List
*/
?>
<?$_productCollection=$this->getLoadedProductCollection()?>
<?if(!$_productCollection->getSize()):?>
<div class="note-msg">
<?=$this->__('There are no products matching the selection.')?>
</div>
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>
attached mail follows:
On Thu, Feb 28, 2008 at 1:32 PM, Daniel Brown <parasanegmail.com> wrote:
> On Thu, Feb 28, 2008 at 1:26 PM, Eric Butera <eric.buteragmail.com> wrote:
> > Magento is designed with css. But I know right now that you won't like it. ;)
>
> Because their server doesn't have PHP configured properly? ;-P
>
>
> > Here is an example page:
> > http://svn.magentocommerce.com/source/branches/beta-0.8/app/design/frontend/default/default/template/catalog/product/list.phtml
>
> All I see is the PHP source. Beginning with:
>
> <?php
> /**
> * Magento
> *
> * NOTICE OF LICENSE
> *
> * This source file is subject to the Open Software License (OSL 3.0)
> * that is bundled with this package in the file LICENSE.txt.
> * It is also available through the world-wide-web at this URL:
> * http://opensource.org/licenses/osl-3.0.php
> * If you did not receive a copy of the license and are unable to
> * obtain it through the world-wide-web, please send an email
> * to licensemagentocommerce.com so we can send you a copy immediately.
> *
> * category design_default
> * package Mage
> * copyright Copyright (c) 2004-2007 Irubin Consulting Inc. DBA
> Varien (http://www.varien.com)
> * license http://opensource.org/licenses/osl-3.0.php Open
> Software License (OSL 3.0)
> */
> ?>
> <?
> /**
> * Product list template
> *
> * see Mage_Catalog_Block_Product_List
> */
> ?>
> <?$_productCollection=$this->getLoadedProductCollection()?>
> <?if(!$_productCollection->getSize()):?>
> <div class="note-msg">
> <?=$this->__('There are no products matching the selection.')?>
> </div>
>
>
> --
> </Dan>
>
> Daniel P. Brown
> Senior Unix Geek
> <? while(1) { $me = $mind--; sleep(86400); } ?>
>
Hi Dan.
It is a svn repo showing the code to a product page to which you
design with styles instead of tables.
attached mail follows:
<?$_productCollection=$this->getLoadedProductCollection()?>
<?if(!$_productCollection->getSize()):?>
<div class="note-msg">
<?=$this->__('There are no products matching the selection.')?>
</div>
first 5 lines I've seen of it and it's got short-tags, escapes in and
out of php/html, no templating engine and no language file, or even
concideration of future implementation.
and is all that inside a class? I see a $this but no "class classname {"
just some constuctive critism, could be good though!
attached mail follows:
On Thu, Feb 28, 2008 at 1:33 PM, Eric Butera <eric.buteragmail.com> wrote:
> It is a svn repo showing the code to a product page to which you
> design with styles instead of tables.
D'oh! Didn't even notice that. Sorry, my fault.
I've been (slowly) migrating from tables to styles myself over the
last year or two. Old habits die hard, for sure, but once I started
seeing noticeably-decreased page-load times (sometimes in the
seconds), it became obvious that I had to start weening myself from my
old TR/TD staples.
Thanks for the link. I'm going to check it out for myself later.
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>
attached mail follows:
On Thu, Feb 28, 2008 at 2:03 PM, Daniel Brown <parasanegmail.com> wrote:
> On Thu, Feb 28, 2008 at 1:33 PM, Eric Butera <eric.buteragmail.com> wrote:
> > It is a svn repo showing the code to a product page to which you
> > design with styles instead of tables.
>
> D'oh! Didn't even notice that. Sorry, my fault.
>
> I've been (slowly) migrating from tables to styles myself over the
> last year or two. Old habits die hard, for sure, but once I started
> seeing noticeably-decreased page-load times (sometimes in the
> seconds), it became obvious that I had to start weening myself from my
> old TR/TD staples.
>
> Thanks for the link. I'm going to check it out for myself later.
>
> --
>
>
> </Dan>
>
> Daniel P. Brown
> Senior Unix Geek
> <? while(1) { $me = $mind--; sleep(86400); } ?>
>
Have you messed around with compressing your output at all? Using
something like mod_deflate is pretty nice while falling back on the ob
gz stuff makes a huge improvement too.
attached mail follows:
On Thu, Feb 28, 2008 at 2:10 PM, Eric Butera <eric.buteragmail.com> wrote:
> Have you messed around with compressing your output at all? Using
> something like mod_deflate is pretty nice while falling back on the ob
> gz stuff makes a huge improvement too.
I have, but the improved performance to which I was referring
comes from pure HTML rules. A lot of people (and myself included,
until about two years ago) aren't aware of one of the fundamentals of
HTML: the page won't start to display until all of the tables are
drawn. Newer browsers are getting better with it, but it still takes
longer than stylizing the page with div's and CSS.
Is that whole Magento system done with CSS, with zero tables?
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>
attached mail follows:
Nathan Rixham wrote:
> <?$_productCollection=$this->getLoadedProductCollection()?>
> <?if(!$_productCollection->getSize()):?>
> <div class="note-msg">
> <?=$this->__('There are no products matching the selection.')?>
> </div>
>
> first 5 lines I've seen of it and it's got short-tags, escapes in and
> out of php/html, no templating engine and no language file, or even
> concideration of future implementation.
>
> and is all that inside a class? I see a $this but no "class classname {"
>
> just some constuctive critism, could be good though!
>
Yeah, I gotta agree here, most of the systems I have worked on have
disabled the short-open tags and other things to secure the site, so
definitely something to keep in mind. This page alone would break as
would <?= tags if they live anywhere (shortcut for "<?php echo ").
Wolf
attached mail follows:
On Thu, 2008-02-28 at 14:23 -0500, Daniel Brown wrote:
> On Thu, Feb 28, 2008 at 2:10 PM, Eric Butera <eric.buteragmail.com> wrote:
> > Have you messed around with compressing your output at all? Using
> > something like mod_deflate is pretty nice while falling back on the ob
> > gz stuff makes a huge improvement too.
>
> I have, but the improved performance to which I was referring
> comes from pure HTML rules. A lot of people (and myself included,
> until about two years ago) aren't aware of one of the fundamentals of
> HTML: the page won't start to display until all of the tables are
> drawn. Newer browsers are getting better with it, but it still takes
> longer than stylizing the page with div's and CSS.
>
> Is that whole Magento system done with CSS, with zero tables?
You know... it's all fine and dandy to eliminate tables... except where
tabular data is concerned. Tabular data is SUPPOSED to be in a table.
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. |
`------------------------------------------------------------'
attached mail follows:
Robert Cummings wrote:
> On Thu, 2008-02-28 at 14:23 -0500, Daniel Brown wrote:
>> On Thu, Feb 28, 2008 at 2:10 PM, Eric Butera <eric.buteragmail.com> wrote:
>>> Have you messed around with compressing your output at all? Using
>>> something like mod_deflate is pretty nice while falling back on the ob
>>> gz stuff makes a huge improvement too.
>> I have, but the improved performance to which I was referring
>> comes from pure HTML rules. A lot of people (and mys