This project is read-only.

Understanding QInjection

QInjection is composed by two main API:
  • Validation API
  • Execution API

Following picture shows the whole process.

Current versione of QInjection is more focused on "Validation API".

Validation API allows you to define a Validation Syntax, in other word a set of rules used to decide if the Lambda Expression is valid or not.

Internally the validation engine of QInjcetion builds the AST (Abstract Syntax Tree) of the lambda expression and it walks throught it by validating each node and branch. An AST is composed by Node and Branches. So declaring the syntax of a lambda expression means to define the "structure" of the Tree in term of Nodes and Branches:
  • You define the list of Nodes accepted
  • You define for each Node which Branch it can use (e.g. "IndetifierName on LeftBranch of a BinaryExpression").

Moreover, for each Node you can define restrictions in term of names, operators and so on ... accepted in input.

A Validation Syntax then is composed by three main elements:
  • A set of supported AST Nodes (VS-Nodes)
  • A set of supported AST Branches, the links between Nodes (VS-Branches)
  • A set of Restrictions over each Node (VS-Restrictions)

The Validation API allows you to define these three sets <VS-Nodes, VS-Branches, VS-Restrictions> in order to evaluate them on the lambda expression.
Using <VS-Nodes, VS-Branches> you can builds all the combinations of supported AST.
Using <VS-Restrictions> you can decide if a Node is valid or not.

The Validation Engine of QInjection takes in inputs four entities <Lambda-Expression, VS-Nodes, VS-Branches, VS-Restrictions> and it applies the following algorithm:
  • It calculates the AST associated to the <Lambda-Expression>.
  • It checks if the AST associated to the <Lambda-Expression> is one of this one that you can build using <VS-Nodes, VS-Branches>.
  • It checks if each Node of the AST associated to the <Lambda-Expression> satisfies the <VS-Restrictions>.

The Validation API has following group of methods:
  • LPP (Low Level Pattern): methods used to define the <VS-Nodes, VS-Branches>
  • HPP (High Level Pattern): methods used as macro/shortcuts of LPP in order to be more hermetic
  • CPP (High Level Pattern): methods used to load your own set of commands
  • WITHs: methods used to define <VS-Restrictions>

Following picture shows how the Validation API is organized.

Following picture shows the role of each pattern.

This is the list of the main methods for each group:
  • LPP:
    • Support(Node node)
    • As(Branch branch)
  • HPP:
    • Accept(Element element)
    • AsBranch()
  • CPP:
    • Under Work
  • WITHs:
    • WithArity(int arity)
    • WithOperator(Operator _operator)
    • WithOperator(IEnumerable<Operator> operators)
    • WithOperator(OperatorCategory operatorCategory)
    • WithName(string name)
    • WithNames(IEnumerable<string> name)
    • WithNameRegex(string regex)
    • WithNameRegexs(IEnumerable<string< regex)
    • RefuseReference(Reference reference)
    • RefuseReferences(IEnumerable<Reference> references)

Usually you use LPP if you want define the AST structure step by step, and you use HPP if you don't want to care about generic structure.
Internally the Validation API maps HPP on LPP.

The main challange with LPP is that you have to know how the AST is made and this could be a very tedious and frustrating task.

Last edited Jan 9, 2014 at 8:59 PM by SamNium, version 4