| Q: | In the template I have some JavaScript code. However, OPT tries to parse the { and } characters, which obviously causes error. |
| A: | Enclose your JS code inside {literal} and {/literal} instructions. |
| Q: | I parse some UTF-8 templates with OPT and all the national characters are broken. |
| A: | This is not a problem of OPT, but of many modern browsers. You have to specify the encoding in the HTTP headers. Set the charset directive to "utf-8" and call optClass::httpHeaders() method to send them. |
| Q: | OPT source code makes a use of a PHP @ operator. I have written my own error handler and, however, it catches the notices even if they are "removed" by this operator. |
| A: | If the captured PHP error is preceded by @, the error_reporting() function called inside the handler returns 0: function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if(error_reporting() != 0)
{
// your code
}
} |
| Q: | My server accepts PHP5 in the scripts ended
with |
| A: | You do not have at all. This requirement concerns only the scripts runned directly from the browser. The sources included by them can have different extensions, even such crazy, as "wigglywiggly". Just include the OPT and do not care about the file extension. |
| Q: | Take a look at the following template: foo{var=foo; "bar"}
barThe expected result: foo bar Given result: foobar What is going on? |
| A: | The templates are compiled to the PHP code. We made some tests and noticed the newline characters are removed by the PHP parser, not OPT compiler. |
| Q: | I have an OPT expression with some strings and I want them to contain { and } characters. But then my template gets broken and an error occurs. |
| A: | These characters open and enclose OPT tags always, even inside a string. In order to display them, use the special entities: &lb; and &rb;. They are available, if the directives entities or xmlsyntaxMode are enabled. |