An analysis of the insider of razor

The ASPX syntax is relatively simple, so the ASPX parser is almost entirely implemented through regular expressions. The razor parser differs greatly from the ASPX parser, which is actually divided into three separate components:

1 to understand the basic HTML syntax tag parser;

2 understand the basic C # or VB Syntax code parser;

3 to understand how tags and code mix the central controller

So the razor parser has three participants: a code parser, a tag parser, and a code parser. Three components work together to complete the parsing of razor documents. The Razor parser has three states, namely: parsing tag documents, parsing tag blocks, parsing code blocks, in any case the parser is in one of the above three states. The first two states are handled by the tag parser, and the last state is handled by the code parser.

Here we still use the last example to illustrate the process of using these components to parse razor documents.

The contents of the document are as follows:

<ul>
@foreach (var p in model.products) {
<li>@p.name ($@p.price) </li>
}
</ul>

Let's start the parsing process from the top. When the core parser is invoked for the first time, it invokes the tag parser to parse the markup document. At this point, the parser is in the state of the parsing tag document, in which case it scans forward until it finds the next "@" character, which does not care about any markup or other HTML-related content. When a "@" character is encountered, it is viewed by looking at the "@" character before and after, and judging by whether it is switched to the code state or is just an email address. This is the default processing, but there are special circumstances that force the parser to switch to the code resolution state. In this case, when parsing to the "@" character, it is found that the character is preceded by a space, which determines that this is not a legitimate email address, so switch to the code parsing state.

The tag parser then invokes the code parser to parse the code block. In Razor, a block is a separate piece of code or a tag that has a definite beginning to end a sequence of characters, so the "foreach" declaration here is a block of code that begins with the character "F" and ends with the character "}". The code parser is very clear about C # syntax, he will track the C # instruction, when encountered "<li>" character sequence, it knows this should be the beginning of C # instructions, but C # does not support such directives, so the code parser will call the tag parser again to resolve the next block of HTML code. This creates a recursive process between the code and the tag parser, starting with tag parsing, entering code parsing, and then entering the tag parsing .... So far, the call stack within the parser should resemble the following structure (omitting some help methods):

Htmlmarkupparser.parsedocument ()
Csharpcodeparser.parseblock ()
Htmlmarkupparser.parseblock ()

We can see the difference between ASPX and razor: In the ASPX file, the code and tag can be thought of as two parallel streams, we write some tags and then skip over to write some code, then jump back to write tags, and so on; Razor file is more like a tree, we write some tags, Then write some code inside the tag, and then embed the tag in the code ...

So we only need to invoke the tag parser to parse the tag block between "<li>" and "</li>", before "</li>" the parser thinks the tag block is not finished, even if there is a "}" character between the tags that doesn't break the "foreach" Statement.

When parsing "<li>", the tag parser discovers the "@" character, so the code parser is invoked, and the stack structure becomes:

Htmlmarkupparser.parsedocument ()
Csharpcodeparser.parseblock ()
Htmlmarkupparser.parseblock ()
Csharpcodeparser.parseblock ()

The details of how these blocks are terminated will be introduced later, but eventually we'll finish parsing the blocks and go back to the "<li>" block, then back to "foreach" after "</li>", and the Last "}" character ends "foreach." block, back to the top of the stack: mark the document. The document parser then resolves to the end of the file because no new @ characters are found.