Code Monkey home page Code Monkey logo

htl-tck's Introduction

HTML Template Language Technology Compatibility Kit

The HTML Template Language (HTL), formerly known as Sightly, has been introduced with Adobe Experience Manager 6.0 and takes the place of JSP (JavaServer Pages) as the preferred and recommended server-side template system for HTML.

This TCK provides a suite of tests meant to certify that an HTL implementation conforms with the official language specification.

How To

Building the package

To build the TCK just run the following command:

mvn clean install

This will result in two artifacts being built:

  1. io.sightly.tck-<version>.jar
  2. io.sightly.tck-<version>-standalone.jar

Extracting and deploying the test scripts

The test files used by the TCK can be extracted using the following commands:

# extracts the test files in the current directory:
java -jar io.sightly.tck-<version>-standalone.jar --extract 

# extracts the test files in a specified folder
java -jar io.sightly.tck-<version>-standalone.jar --extract path/to/folder

The extracted files are organised as follows:

testfiles/
├── definitions # contains JSON files describing the tests
├── output      # contains the expected output markup
└── scripts     # contains the test scripts

The TCK assumes the scripts are available at some predefined URLs. The URL at which a test can be found is composed from /sightlytck, to which the relative path of script file from testfiles/scripts is added.

Assuming we have the following structure in testfiles:

testfiles/
└── scripts
    └── exprlang
        └── operators
            └── operators.html

the URL at which the output of the operators.html script is expected to be found is <severURL>/sightlytck/exprlang/operators.html.

Running the TCK

The HTL TCK can be run standalone or as a Maven artifact. Both modes assume that you have a server running where you have deployed the testing scripts.

Run the TCK as part of the integration-test Maven build phase

Add the TCK as a test dependency to your pom.xml file:

<!-- testing dependencies -->
<dependency>
    <groupId>io.sightly</groupId>
    <artifactId>io.sightly.tck</artifactId>
    <version>1.4.5</version>
    <scope>test</scope>
</dependency>

The following Java properties need to be set for successfully Running the TCK:

io.sightly.tck.serverURL=<server root URL>
io.sightly.tck.user=<Basic authentication user> # optional
io.sightly.tck.pass=<Basic authentication password> # optional

The TCK can then be run during the integration-test phase of your Maven project build using the following configuration:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-failsafe-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>integration-test</goal>
                        <goal>verify</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <dependenciesToScan>
                    <dependency>io.sightly:io.sightly.tck</dependency>
                </dependenciesToScan>
                <includes>
                    <include>%regex[io.*sightly.*tck.*TestsRunner.*]</include>
                </includes>
                <systemPropertyVariables>
                    <io.sightly.tck.serverURL>http://${test.host}:${test.host.port}</io.sightly.tck.serverURL>
                </systemPropertyVariables>
            </configuration>
        </plugin>
    </plugins>
</build>

Run the TCK in standalone mode

For this mode you need the io.sightly.tck-<version>-standalone.jar artifact.

The standalone mode assumes that you have deployed the test scripts on your platform.

The following commands run the TCK:

# run the TCK
java -jar io.sightly.tck-<version>-standalone.jar --url http://www.example.com

# run the TCK on a server that requires Basic authentication
java -jar io.sightly.tck-<version>-standalone.jar --url http://www.example.com --authUser user --authPass pass

In case you need the standalone version of the artifact in a Maven project, you can add the following dependency to your pom.xml file:

<dependency>
    <groupId>io.sightly</groupId>
    <artifactId>io.sightly.tck</artifactId>
    <version>1.4.5</version>
    <classifier>standalone</classifier>
</dependency>

Versioning

The TCK artifacts use a semantic versioning scheme - MAJOR.MINOR.PATCH:

  • MAJOR.MINOR - identify the specification version for which the TCK was built
  • PATCH - identifies the version of the TCK artifact for the corresponding specification version

Exceptions

  1. version 1.4.0 corresponds to version 1.4 of the HTML Template Language Specification

htl-tck's People

Contributors

gabrielwalt avatar raducotescu avatar vladbailescu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

htl-tck's Issues

HTMLExtractor#hasAttribute logic can return false positive when checking empty attribute values

The current implementation of HTMLExtractor#hasAttribute can return false positive when checking empty attribute values. Luckily this doesn't affect the current tests.

In order to avoid a complex logic for the method, two methods should be implemented: hasAttribute, which checks only the presence of an attribute on the selected elements, and hasAttributeValue, which checks the presence + value.

Add attribute tests with values which cannot be evaluated

Some tests should check that a value that cannot be evaluated passed to an attribute does not allow the attribute to be displayed.

Examples:

<!-- assuming null is not actually a variable provided in the scope -->
<div id="null-1" data-test="${inexistent}"></div>
<div id="null-2" data-test="${inexistent @ context='unsafe'}"></div>
<div id="null-3" data-sly-attribute.data-test="${inexistent @ context='unsafe'}"></div>

Provide more tests for data-sly-text

Currently there's only one test for data-sly-text, that only checks of the children of the current element are replaced by the value of the data-sly-text expression. However, given the nature of this block statement, more tests should be added to check the correct display contexts.

Two XSS tests don't use the correct POJO methods

Two tests do not use the correct POJO methods, therefore executing with empty values for the onclick attributes:

<a id="attr_2" onclick="${xsspojo.jsUri @ context='attribute'}">Click me</a>
<a id="attr_3" onclick="${xsspojo.jsCode @ context='attribute'}">Click me to do JS</a>

The tests should be modified to:

<a id="attr_2" onclick="${xsspojo.javaScriptUri}">Click me</a>
<a id="attr_3" onclick="${xsspojo.javaScriptCode}">Click me to do JS</a>

Test multiple versions of the same language for the i18n filter

The locale to identify a language can provide more information than just the language code, like the country code or even a variant. Some tests should be added to make sure an implementation obeys at least the country code locale information when trying to localise a String.

tck compatibility with sightly spec

I'm planning on a js implementation of sightly to facilitate a front-end workflow and wanted to confirm, is this TCK up to date with the sightly 1.1 spec? From the tickets that have been closed (at brief glance) it appears it may be, but the readme only appears to reference 1.0.

If it is, could we please get some tagged releases tied to sightly versions for easy reference?

Thanks!

Extend tests for URI manipulation options

More tests should be added for the URI manipulation options to make sure that path-dependent processing (e.g. path, extension and fragments manipulations) only changes the resulting URI if the initial one provided a path segment.

Add more tests for the string formatting fallback

The specification mentions the following details about the formatting type [0]:

Type of formatting will be decided based on:
* the type option, if present (accepted values are string, date and number)
* placeholders (eg: {0}) in the pattern, triggers string formatting
* type of format option object, when the type is a Date or a Number
* default, fallback to string formatting

However, the fallback is not completely tested.

[0] - https://github.com/adobe/htl-spec/blob/1.4/SPECIFICATION.md#122-format

Allow builds with Java 11

Due to the default version of the maven-compiler-plugin (3.1), the project cannot be built on Java 11.

Add tests for void elements in data-sly-element

The currently available data-sly-element tests only check element replacements for non-void elements (e.g. div tags). It would be useful to have a couple of tests with void elements and also with different combinations of closing tags.

The tests for data-sly-resource and data-sly-include path options are underspecified

Both data-sly-include and data-sly-resource allow performing some path manipulation for the included resource / script through the appendPath and prependPath options, as well as though the path option (for data-sly-resource) and file option (for data-sly-include).

However, the tests which are currently in the TCK do not test if path normalisation is performed correctly by an implementation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.