janscheible/knorxx

A framework for HTML/CSS/JavaScript frontend development in pure Java.

knorxx's Issues

Add Java 8 support to JavaSourceDependencyCollector

The currently used com.google.code.javaparser only supports Java 5 sources. Replacing it by a newer parser (e.g. the Java 8 parser of PMD) would allow the usage of Java 8 (st-js already supports Java 8).
The implementation of this ticket is a prerequesite for #4.

Generate constants instead of functions for the CSS class names in JavaScript

Currently functions are generated to return the CSS class names. This seems to work with jQuery (it must contains some logic to simply call the function). In other places this causes problems because a String is assumed.

Provide an easier way to make JDK's tools.jar available

Currently the recommended appraoch is to copy tools.jar from $JDK_HOME/lib/tools.jar to $JDK_HOME/jre/lib/ext. But this is a ugly workaround... :-(

Enum types cause an error in StaticUsageOrderSorter

The dependency collector reports references to itself for enum types. This is not allowed in the dependency graph construction.

Missing namespace of enum types without source

Because the enum types outside of the web project are not reloaded by the ReloadingClassLoader they receive no @Namespace annotation and therefore st-js treats them as default package residents.

Source Map support

• There is already Source Map support in st-js --> just collect & expose them
• Source Map info see: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?pli=1

EnumGenerator should also support arbitrary additional fields

The EnumGenerator class should also support enum fields with a getter. For a enum like

public enum TestEnumWithValues {    
    FIRST("Test");

    private final String text;

    private TestEnumWithValues(String text) {
        this.text = text;
    }

    public String getText() {
        return text;
    }
}

it should be possible to use TestEnumWithValues.FIRST.getText() in the classes which are transpiled to JavaScript.

Library detectors should work on sets instead of lists

This simplifies the detector implementations.

Error in Spring adapter when having a project without RPC services

Enum types from other JARs still need the Java source in the JARs

This is related to #10 which indeed allows the usage of enum types from other JARs.
But the other JARs still need the Java source embedded. This is not the fault of the EnumGenerator but a problem in the JavaScriptGenerator. It looks up the source with new JavaFileWithSource<>(javaClass, generationRoots); even if it is not needed for EnumGenerator.

This bug is not a real problem for own JARs for which we simple can embed the Java source. But for third-party JARs it's a problem...

Dependent class not found by ByteCodeDependencyCollector

The ByteCodeDependencyCollector is not able to identify the usage of the class StaticHelperClass in the following example:

package knorxx.framework.generator.dependency.testclass.bytecode;

public class AnonymousInnerClassWithStaticHelperInSamePackage {

    public void test() {
        System.out.println(new Runnable() {

            @Override
            public void run() {
                StaticHelperClass.doIt();
            }
        });
    }
}

Dependency collections in JavaScriptGenerator should also consider super classes

The dependency collection in JavaScriptGenerator is used to identify allowed packages for the st-js generation. Therefore it must also consider the super classes because their packages have to be also allowed for st-js.

Add an annotation for defining a scope for the generated CSS rules

@StyleScope(".myApplication")
public class Appearance extends CssDefinition {
    String HEADING_STYLE = build(Properties.builder()
            .setBackground(convertColor(DEFAULT_COLOR))
            .setColor(convertColor(Color.WHITE)));
}

This should still lead to the corresponding generated JavaScript for referencing the rule:

Appearance.HEADING_STYLE = 'headingStyle';

But to an additional selector for the generated CSS rules:

.myApplication .headingStyle {
    background-color: #ff0000;
    color: #ffffff;
}

Enum types without sources are not generatable

St-js needs the source of classes to generate available. Unfortunately for enum types in JAR libraries this is not possible. The special generator EnumGenerator will do that instead of st-js. The EnumGenerator will only rely on the byte code, no source is needed.

Automatic namespace assignment should be omittable

This is useful for bridge classes which are in the global namespace (e.g. Websocket).

PMD Java 8 Lambda parse error on direct field access

The PMD Java 8 parse (which is used in the class JavaSourceDependencyCollector) fails on code like that:

object.event = () -> {
    Request request = new Request();
    request.id = 42;
};

The bug is reported to the PMD guys as #1258 Java 8 Lambda parse error on direct field access .

Add a convenient way to save the generated JavaScript for production mode

In production mode it is not needed anymore to generate the JavaScript dynamically.
Currently saving and minimizing the JavaScript can be done manually but there's no support to do that automatically.

@Template("propertyAccess") should also support boolean isSomething() like methods

It would be nice if @Template("propertyAccess") could also translate obj.isSomething() to obj.something.

Usage of Spring Boot for sample application

Allow dynamic reloading of HTML generation in a PageArranger

It would be nice to also reload instances of PageArranger with the ReloadingClassLoader. This might be useful for page arrangers which render only static HTML in the renderOn method (e.g. for generating a GUI).

CSRF protectionfor for RPC service

• Add protection against CSRF attacks
• e.g. 'Double Submit Cookies' strategy of https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

Removal of default <table>...</table> tag from generated HTML frame

The file presentation.jsp contains a <table> tag which is included for every web page.
This should be removed because it should be the responsibility of each web page to build up the needed HTML tags.

RTTI JavaScript URL tag is inserted before the URL of the class definition

As a result the class definition overrides the RTTI static members.
This is a regression introduced by #12.

Modified st-js version must be available as Maven repository

The modified st-js version must be available in some repository. At least via GitHub.
This will provide a easier way to create a new Knorxx application. No local compilation of other modules should be needed.

Upgrade to st-js 3

Mainly because of the Java 8 support (and a few bug fixes).