GithubHelp home page GithubHelp logo

bootique / bootique-mvc Goto Github PK

View Code? Open in Web Editor NEW
6.0 6.0 4.0 346 KB

MVC framework for Bootique and Mustache Template Engine integration

License: Apache License 2.0

Java 89.48% FreeMarker 3.59% Mustache 6.93%
bootique freemarker mustache mvc

bootique-mvc's Introduction

build test deploy Maven Central

Bootique is a minimally opinionated java launcher and integration technology. It is intended for building container-less runnable Java applications. With Bootique you can create REST services, webapps, jobs, DB migration tasks, etc. and run them as if they were simple commands. No JavaEE container required! Among other things Bootique is an ideal platform for Java microservices, as it allows you to create a fully-functional app with minimal setup.

Each Bootique app is a collection of modules interacting with each other via dependency injection. This GitHub project provides Bootique core. Bootique team also develops a number of important modules. A full list is available here.

Quick Links

Support

You have two options:

  • Open an issue on GitHub with a label of "help wanted" or "question" (or "bug" if you think you found a bug).
  • Post a question on the Bootique forum.

TL;DR

For the impatient, here is how to get started with Bootique:

  • Declare the official module collection:
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.bootique.bom</groupId>
            <artifactId>bootique-bom</artifactId>
            <version>3.0-M4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency> 
    </dependencies>
</dependencyManagement>
  • Include the modules that you need:
<dependencies>
    <dependency>
        <groupId>io.bootique.jersey</groupId>
        <artifactId>bootique-jersey</artifactId>
    </dependency>
    <dependency>
        <groupId>io.bootique.logback</groupId>
        <artifactId>bootique-logback</artifactId>
    </dependency>
</dependencies>
  • Write your app:
package com.foo;

import io.bootique.Bootique;

public class Application {
    public static void main(String[] args) {
        Bootique
            .app(args)
            .autoLoadModules()
            .exec()
            .exit();
    }
}

It has main() method, so you can run it!

For a more detailed tutorial proceed to this link.

Upgrading

See the "maven-central" badge above for the current production version of bootique-bom. When upgrading, don't forget to check upgrade notes specific to your version.

bootique-mvc's People

Contributors

aarrsseni avatar andrus avatar const1993 avatar elena-bondareva avatar irus avatar lukaszbachman avatar stariy95 avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bootique-mvc's Issues

Mustache template caching and controlled reload

Currently Mustache templates are reloaded on every render call, which is rather inefficient. Let's support caching of compiled templates in MustacheTemplateRenderer, with reload interval configurable via YAML:

mvc:
   templateTtl: 30s

For backwards compatibility, the default (if TTL is unset) will be "reload every time". This configuration is not Mustache-specific, so we will need to open a task to support it in Freemarker provider as well.

Mustache templates for "partials" should resolve against "templateBase"

The main Mustache template loading mechanism is controlled by Bootique, while loading templates for "partials" (i.e. includes) happens via built-in Mustache mechanism implemented in com.github.mustachejava.resolver.DefaultResolver (cascading lookup in classpath, filesystem, and URL).

This appears to work most fo the time (especially for classpath templates), but in general it is really undeterministic. We should implement a more controlled approach:

  • if a "partial" resource location is an asbolute URI, resolve it as such
  • otherwise resolve it against the app "templateBase"

Cache template pointers

MVC Template object is just a pointer to a template location. It never changes, so there's no reason to create it every time. If we can cache it, it can precalculate template URL and resolve the real template much faster.

Allow to align template location with an arbitrary class

Currently MVC template location is tied to the REST resource package path. This may be a good default occasionally, still I find it annoying and prefer to ties templates to the view classes that are separate from REST API (controller). So redoing the TemplateResolver API to take an arbitrary class, and using view as the default.

Add template live reloading

For now you need to restart server after template change or use some other tools for prototyping. It will be really great if bootique-mvc can reload template in runtime. This may be configurable, to disable on production.

Unified template resolving mechanism

Currently we don't have a unified template resolving mechanism that works the same way for Mustache and Freemarker and for root templates and included templates (see #24) . This causes confusion as well as security concerns. Let's implement a single mechanism across the board that works the following way:

  • (current behavior) the app must define a single "templateBase" that can be a web URL, a filesystem path or a classpath base
  • (current behavior) Root templates associated with the views should resolve against "templateBase" by building a path based on the view package (e.g. for org.example.MyView the path for the root template may be org/example/xyz.mustache or org/example/xyz.ftl)
  • A subtemplate specified with an absolute path (starting with a "/") will be resolved against "templateBase"
  • A subtemplate with a relative path will be resolved against the view path. E.g. my/subtemplate.mustache will be resolved as org/example/my/subtemplate.mustache
  • Perform security checks to avoid breaking out of the "templateBase" by using otherwise permissible ../

Upgrade Notes

  • Root template names starting with / may no longer work, as the package name will not be prepended to them. You will need to remove the slash if you want them resolved relative to the view Java class.

JakartaEE-compatible version

Now that we have both Jetty and Jersey module versions compatible with Jakarta EE, let's provide bootique-mvc-jakarta* versions of the MVC packages.

Add multi-threaded rendering options to Mustache

Mustache-java supports multi-threaded template rendering. Model writers will need to provide Callable return types for this to happen. But the framework also needs to be configured with a thread pool according to this:

If you change description to return a Callable instead it will automatically be executed in a separate thread if you have provided an ExecutorService when you created your MustacheFactory [..] This enables scheduled tasks, streaming behavior and asynchronous i/o..

Mustache Integration

Create a module supporting Mustache templates. The actual integration will be based on Jersey MVC. Late we may create modules for Freemarker and JSP templates.

This module will depend on bootique-jersey, and template rendering will be done via JAX-RS.

Better template resolving mechanism

Current template resolving mechanism inherited from jersey-mvc is not very user-friendly. Per Jersey AbstractTemplateProcessor.resolve, it looks for a package with the name of the resource Java class (e.g. com.foo.MyResource results in com/foo/MyResource/template.mustache).

We should probably use an algorithm like this:

template_path = basePath + resource_package_path + template_name_with_ext

and then the lookup strategy should be based on 'basePath' value... If it has a URL prefix, resolve it as a URL, if it starts with classpath:, resolve as classpath, otherwise treat it like a file. (analogous to staticResourceBase in JettyModule). This will ensure predictability of the template resolution.

Perhaps we can drop Jersey MVC all together, avoiding its APIs like Viewable and @Template

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.