recategorize

Isn't this the expected behaviour? It's certainly what would happen if used $whatever in a string anywhere else in PHP - I think people would just get confused if their variables suddenly disappeared.

If you want to include a $ sign in the string, you need to escape it (\$).

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

I think you misunderstood the report.  The $1 was the literal value (note the single quotes around the string).  When IT.php processes the value it's evaluated instead of being taken literally -- I wouldn't think that'd be expected behavior.  Try this modified example:

<?php

require_once('HTML/IT.php');

$value = 'I have $1 in my pocket';

$t = new IntegratedTemplate;
$t->setTemplate('{x}', TRUE, TRUE);
$t->setVariable('x', $value);

print $value."\n";
$t->show();

?>

This prints:

I have $1 in my pocket
I have  in my pocket

The first time it's printed correctly, but after it's processed in IT.php it's printed incorrectly.

Yes I understand it, but it's an excepted behaviour of the ZendEngine. Just add put a backslash before '$'.

Thanks for your report.

I'm not clear how that's expected behavior.  I'm not referring to PHP's handling of strings, but of IT.php's usage of preg_replace() instead of str_replace().  I understand that this is necessary:

$value = "\$1"

but if I can print $value to STDOUT with the dollar sign, I don't understand why I have to escape it again before substituting it for a template variable.

If the value isn't explicitly defined in my code, form input for example, I'd have to substitute all '$' for '\$' and then revert back to the original value if I wanted to use it in something other than IT.php.

I got the point. I don't think this can be fixed anyway. I will talk about it with the maintainer.

Thanks you, I will let you know.

OK, thanks.  I think the patch I provided should fix the bug.  Looking at the code, the preg_replace() method is used to match the delimeters + variable name even though that will never contain a regular expression.  There also isn't any of that match reused in the substitution (i.e. the $1, $2, \1, \2, etc. variables).  So str_replace() should be an acceptable replacement while fixing the bug.

By the way, I should probably continue in saying that the bug only affects values with characters representing those match variables -- $1, $2, \1, \2, etc. -- not just any dollar sign character combo.

I'm not sure the maintainer want to lose the rapidity of the request just because of that too. ereg() are not enough fast. preg_* is definitly the best way to do a Template class.

Anyway...

I never suggested ereg().  I'm suggesting str_replace(), which is much faster than preg_replace() so the patch would actually give it a speed boost.

Ewps, sorry. Probably too late for me.

well I will see that with the maintainer. There is probably a reason to use preg_replace() and not str_replace() even if I don't see it at 4:18am :-)

Thanks you.

Please upgrade the IT package to 1.0.0.

The new class name is HTML_Template_IT

$t = new HTML_Template_IT();
...

I ll be back with your problem this weekend.

pa

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

$1 to $99 are used by preg_replace in the replacements arguments (see: http://fr2.php.net/manual/en/function.preg-replace.php).

$t = new HTML_Template_IT();
$t->setTemplate('{x}', TRUE, TRUE);
$t->setVariable('x', 'I have $a in my pocket');
$t->show();

thanks for the post

pa

I am wondering if using str_replace instead of preg_replace 
would solve these two problems... Could you please test it 
? Thanks.

Keep it closed. Replace preg by a str_replace does not solve these problems.

Besides that, can you, please, do not set status if you do not know what the status means.

thank's

pierre