Loco Question, MatchParser about loco HOT 5 CLOSED

also, i bump into parsing completed prematurely exceptions on stray greater-than signs "<" and i have no clue on how to allow them (much like a browser does just displays them). once they're matched in 'content', they can't be part of the closing tag anymore.

from loco.

My preferred solution to this problem is just this:

$name = new RegexParser("#^[a-zA-Z_][a-zA-Z0-9_]*#");
$content = new RegexParser("#^[^<>&]*#"); # or whatever

$tag = new ConcParser(
    array(
        new StringParser("<"),
        $name,
        new StringParser(">"),
        $content,
        new StringParser("</"),
        $name,
        new StringParser(">")
    ),
    function($lt1, $name1, $gt1, $content, $lt2, $name2, $gt2) {
        if($name1 !== $name2) {
            throw new ParseFailureException("Close tag name ".$name2." doesn't match open tag name ".$name1, 0, "");
        }
        return new Tag($name1, $content);
    }
);

print_r($tag->parse("<p>what</p>")); # ok
$tag->parse("<h1>what</h2>");        # exception

(Obviously you'd need to implement a Tag class yourself, and come up with a better $content Parser.)

However, I do see that this is undesirable, because I'm having to throw a ParseFailureException, which demands both an index and a string to be supplied as arguments when instantiated. We don't have access to this information in this case, which means I'm passing 0 and "" respectively instead just as stopgaps. It's almost certainly possible to provide the index and string to the ConcParser callback as arguments somehow, but I'll have to do some thinking before I settle on a good solution to this problem. (It may be that just making those two attributes optional when creating a ParseFailureException is a possibility.)

from loco.

I don't see what use a MatchParser provides anyway. Surely you still need to create one MatchParser for every possible tag, which means it doesn't save any effort over doing the same with ConcParsers.

from loco.

@ferno that's almost exactly what i did, but inside the parser. Have you seen the Gist?

For instance the simpleComment example will fail on a h4 or h6 tag. A match-parser can fetch valid (xml) tags syntax and your callback can discard or ignore them or whatever.

from loco.

Yes, I did see the Gist. The point I was making with my example was that
the functionality you're asking for is already available in Loco, in a much
simpler way than your MatchParser. Therefore, I don't see a good reason to
add this new class to the library.

On 1 October 2012 06:42, GDmac [email protected] wrote:

@ferno https://github.com/ferno that's almost exactly what i did, but
inside the parser. Have you seen the Gist?

For instance the simpleComment example will fail on a h4 or h6 tag. A
match-parser can fetch valid (xml) tags syntax and your callback can
discard or ignore them or whatever.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-9022320.

from loco.