Parsing rules

[TQ White II]

>I don't exactly understand the problem. Would you provide a specific
>example where you do x, and y happens, but what used to happen was
>something else? Thanks.

Dear Brent,

Thanks for your attention. Here is everything that I can figure out about
the problem. Sorry that it's so long and complex.

These examples are PHP. I have stuck in extra carriage returns so it's more
readable.

The first example is a part of a php class that has been running (largely
untouched) for a year. I added a subroutine to the class and got a
compilation error. After debugging, I found that the problem was that the
macro 'phpGenCaseStmts' was not being expanded by Frontier.

Clue #1

My first attempt at workaround was to add another pass of 'processMacros'
to finalFilters. No effect. After an incredable amount of pain, I found
that if I add an angle brace (the first character in the comment before
FRONTIER), the macro processes and the php code compiles correctly.

switch ($fieldName)

	-(-

	/*> FRONTIER won't expand the following macro without the angle
brace tqii 10/24/01*/

	{phpGenCaseStmts(html.getPageTableAddress()^.["dbTableName1"],
html.getPageTableAddress()^.["dbSchemaAddress"], "inputTag", "case
\"#fieldName#\": $outString=\"#inputName#: #elementContent#\"; break;")}

	-)-

Clue #2

Actually, there is another way toget the code to compile and that is to
remove a line of code that precedes the macro shown above.

$outString=ereg_replace(">[a-zA-Z0-9]{0,}data<", "><", $outString);
//insert values into textarea items that don't have the value= part

If I get rid of this, then the macro processes correctly and the class
compiles. Unfortunately, it no longer works. Actually, I don't have to get
rid of the entire line. If I just remove the right braces ('>'), it works.

Clue #3 - The Other Example

In Frontier, this second example looks like:

$messageArray["messageTemplate"].="Hi <!nickName!>\n\r\n\rThis is a news
bulletin to let you know about the 2 Grrrls Friends Count!(tm) email
game.\n\r\n\r";

When rendered, it looks like:

$messageArray["messageTemplate"].="Hi <!nickName!>,nrnrThis is a news
bulletin to let you know about the 2 Grrrls Friends Count!(tm) email
game.nrnr";

Notice that '\n\r\n\r' has turned into 'nrnr'. Bummer.

The workaround that I found is to revise the code so that it looks like this:

$messageArray["messageTemplate"].="Hi <!nickName!>,";

$messageArray["messageTemplate"].="\n\r\n\rThis is a news bulletin to let
you know about the 2 Grrrls Friends Count!(tm) email game.\n\r\n\r";

That is, I split the construction of the string into two lines.

Clue #4

Actually, there is another way to get the backslashes to appear. If I get
rid of the right angle brace ('>'), they render nicely and all is well in
slash-land, except, of course, for the fact that the program no longer
works.


So, there you have it. Everything that I know about this problem. It has
been terrible for me because I have thousands of lines of code like this,
much of it untouched in a long time. I dare not touch it unless I have an
arbitrarily long time to debug. (It's worth noting that there are plenty of
examples of similar code that might be the problem that aren't.)

If you can make it stop doing this, I will be deeply grateful.

Regards,
tqii

--------------------------------------------------------------------------------
TQ White II

708/763-0100
tq at justkidding.com
http://www.justkidding.com

Check out my latest addition:
http://justkidding.com/politics
--------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4079 bytes
Desc: not available
Url : http://lists.userland.com/pipermail/frontier-users/attachments/20011106/550f2d14/attachment-0002.bin