vlthr / levee Goto Github PK

• Naked subtags
• Malformed boolean expressions
• Case blocks without any when blocks

• append
• capitalize
• date
• divided_by
• downcase
• escape
• escape_once
• first
• join
• last
• map
• minus
• modulo
• newline_to_br
• plus
• prepend
• remove_first
• remove
• replace_first
• replace
• size
• sort
• split
• strip_html
• strip_newlines
• times
• truncate
• truncatewords
• upcase
• json
• reverse

Liquid custom tags allow each tag to define the structure of its arguments entirely freely, so a filter must handle the parsing of its own arguments. It would be nice if this complexity was not exposed to the user of the library, since the vast majority of filters would not it.

Filters could possibly be represented as a partial function, defined something like follows:

@Filter
case class MyFilter() {
    def apply() {
        case (input: Value, a: Int, b: Int) => ...
        case (input: Value, args: String) => ...
    }
}

In the Filter macro, matching String -> (Int, Int) and String -> String parsers could be generated automatically, such that the filter above would work when called with:

{{ "Hello world" | myfilter: "xxx" }}
or 
{{ "Hello World" | myfilter: 1, 2 }}

Parsing:

• Unrecognized tokens (needs special case for improved error messages)
• Unbalanced tags/objects (needs special case for improved error messages)
• Unmatched tag pair (needs special case for improved error messages)
• No input to filter
• Nonexistent tag

Evaluation/Rendering:

• Undefined identifier use
• Invalid iterable in for loop
• Incomparable values (needs test)
• Invalid index type
• Invalid indexable in IndexExpr
• Index out of range
• Undefined fields in map
• Invalid map type in DotExpr
• Invalid filter input type
• Invalid filter argument type
• Invalid number of filter arguments
• Unknown filter

• assign
• capture
• case
• comment
• cycle
• for
• if
• include
• raw
• tablerow
• unless
• increment

Rendering a template should not error out on the first exception but rather collect as many errors as is meaningful and then report them to the user.

Possible solutions:

• Refactor render methods signature to Try[String]
• Implement an error listener system similar to ANTLRs

{{ true > false }} will currently yield true, but in liqp the same tag renders to false.

Something like sbt testExamples to render all the template files in a given folder, then comparing the result with another file containing the expected output. Then sbt genExamples to regenerate the expected outputs.

Some tags and filters such as slice can have an optional positional argument.

 dottydoc-templating (de-submodule) ✗ sbt compile                 
[warn] Executing in batch mode.
[warn]   For better performance, hit [ENTER] to switch to interactive mode, or
[warn]   consider launching sbt without any commands, or explicitly passing 'shell'
[info] Loading global plugins from /home/von/.sbt/0.13/plugins
[info] Loading project definition from /home/von/bb/dottydoc-templating/project
[info] Set current project to dottydoc-templating (in build file:/home/von/bb/dottydoc-templating/)
[warn] Binary version (0.1.2-RC1) for dependency ch.epfl.lamp#scala-library;0.1.2-RC1
[warn]  in macros#macros_0.1;0.1-SNAPSHOT differs from Scala binary version in project (0.1).
[info] Updating {file:/home/von/bb/dottydoc-templating/}macros...
[info] Resolving ch.epfl.lamp#dotty-library_0.1;0.1.2-RC1 ...
[warn] circular dependency found: ch.epfl.lamp#scala-library;0.1.2-RC1->ch.epfl.lamp#dotty-library_0.1;0.1.2-RC1->...
[warn] circular dependency found: ch.epfl.lamp#dotty-library_0.1;0.1.2-RC1->ch.epfl.lamp#scala-library;0.1.2-RC1->...
[info] Resolving my.fengy#gestalt_2.11;0.1.1 ...
[warn]  module not found: my.fengy#gestalt_2.11;0.1.1
[warn] ==== local: tried
[warn]   /home/von/.ivy2/local/my.fengy/gestalt_2.11/0.1.1/ivys/ivy.xml
[warn] ==== public: tried
[warn]   https://repo1.maven.org/maven2/my/fengy/gestalt_2.11/0.1.1/gestalt_2.11-0.1.1.pom
[warn] ==== sonatype-snapshots: tried
[warn]   https://oss.sonatype.org/content/repositories/snapshots/my/fengy/gestalt_2.11/0.1.1/gestalt_2.11-0.1.1.pom
[warn] ==== sonatype-releases: tried
[warn]   https://oss.sonatype.org/content/repositories/releases/my/fengy/gestalt_2.11/0.1.1/gestalt_2.11-0.1.1.pom
[warn] ==== typesafe-ivy-releases: tried
[warn]   https://repo.typesafe.com/typesafe/ivy-releases/my.fengy/gestalt_2.11/0.1.1/ivys/ivy.xml
[info] Resolving org.scala-lang.modules#scala-xml_2.11;1.0.1 ...
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: my.fengy#gestalt_2.11;0.1.1: not found
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn] 
[warn]  Note: Unresolved dependencies path:
[warn]          my.fengy:gestalt_2.11:0.1.1 (/home/von/bb/dottydoc-templating/build.sbt#L26)
[warn]            +- macros:macros_0.1:0.1-SNAPSHOT
sbt.ResolveException: unresolved dependency: my.fengy#gestalt_2.11;0.1.1: not found
[trace] Stack trace suppressed: run last macros/*:update for the full output.
[error] (macros/*:update) sbt.ResolveException: unresolved dependency: my.fengy#gestalt_2.11;0.1.1: not found
[error] Total time: 3 s, completed Jun 9, 2017 4:31:16 PM

The error seems to be related to a mismatch in dotty versions. Doing an sbt publishLocal in gestalt publishes to:

[info]  published ivy to /home/von/.ivy2/local/me.fengy/gestalt_0.4/0.1.1/ivys/ivy.xml

https://shopify.github.io/liquid/basics/whitespace/

• AST classes
• Parser API
• Basic Tests/Usecases

Implementing both filters and custom tags with arguments turns out to be fairly cumbersome due to all the type checking required to make the filter robust - especially if trying to catch all detectable errors before returning.

Having a somewhat cumbersome API for defining these in a well-behaved way is not necessarily a problem for code that is internal to the project, but the current API is not easily approachable by users and is also fairly verbose and boilerplate heavy. Fixing this now would both allow for user-extensibility and would also make implementing the remaining standard set of filters and tags easier.

Filter API Requirements

A filter application has the following form:

{{ input | filterName: arg0, arg1 }}

Error types

The filter must be able to (where possible) simultaneously detect all instances of the following:

Invalid input type

Filters always take a single value as input, so type checking should amount simply to checking which subclass of value was given as input. Error message should at least specify what the invalid type is, but preferably also what the expected type/types are.

Invalid count argument count

A given filter may be defined for a variable number of arguments, and if an invalid number of arguments is given, the error message should preferably be able to give some indication of how to fix it.

Invalid filter argument type

If a filter is given the correct number of arguments but of the wrong value types, the error message should specify the invalid type and if possible also an expected type.

Other

• Filters should be easy to implement for users
• There should not be any gotchas that could cause type unsafe behavior
• Implementations of standard filters should be as DRY as possible
• A filter should be easy to define for multiple input types