#74 parseCode and embedCode conflict

[Mark Lentczner]

In HTML.pm there are a number of routines that handle the interpretation of square bracket escapes ( [%...%], ["..."], [<...>] and [{...}] ). There are two distinct paths for this interpretation: If compile-o-cache is allowed (not turned off globally, and the user is not in a workspace), then the parseCode() does all the work, building up a sub to do the work of the escapes. On the other hand, if compile-o-cache can't be used, then parseCode() calls oldParseCode() which in turn calls embedCode() to interpret the escapes directly.

Alas, the semantics of the escapes are different when compiled by parseCode() than when interpreted by embedCode(). This means that users in workspaces get different results than other users. And, if you turn off compile-o-cache, you different results globally!

In particular, they differ in how they compute ["..."]:

parseCode compiles this way:
["code"] -> eval {code}

embedCode interprets this way:
["code"] -> eval '"code";'

These are two different Perl contexts and have different expression syntaxes! For example ["$a $b"] works with embedCode, but not parseCode. On the other hand ["getNode($a, 'thing')->getFoo()"] works with parseCode and not embedCode.

The two paths also differ in more subtle ways in their implementation of the other escapes. I don't think those differences can produce different results, but I'm not sure...

- Mark

[Nobody/Anonymous]

Logged In: NO

Check out line 1234 in Everything/HTML.pm, it explains that
it does this on purpose so that user's can't enter what you
have written in. And then if you look at 1301 ( The comments
above parseCode ) you see that it doesn't care if it's from
a user, instead it relies on the caller to make sure the
code is okay.

The question I suppose then is - what is the correct
behaviour? Should there be another case in embedCode that
will let it through? I don't know the code well enough so I
can't answer this question.

je <jay@kenyamountain.com>