Development Plan of Toxic

Toxic now does what I initially planned it to do. So there is currently no plan for a next release. As long as there are no new ideas for features, feature requests or whatever I will fix any bugs I get to know.

Feedback is welcome

Table of Contents

Unassigned Ideas

TODO Write more Unit Test

Toxic needs many more unit test, at least to cover the Toxic core package.

TODO Write more API Docs, Examples

To make it easier for people to get started with using Toxic much more documentation is needed.

TODO Port to Java 8 and use lambda expressions

Java 8's lambda expressions give a nice syntax to implement template content in place.


DONE Java Release 0.2.0

  • State "DONE" from "TODO" 2013-03-02 Sa 12:00

DONE Deep Fixing of Bout

  • State "DONE" from "TODO" 2013-02-10 So 10:43

Using Bount.fix() proved to be a valuable tool to optimize dynamically assembled templates. Unfortunately the v0.1.b implementation only fixes Bounts with unbound names on the first level. If there are deeply nested unbound placeholders it does not work.

Bount.fix() is redesigned to deeply fix bound placeholders.

DONE Make a back-port to Java 1.6

  • State "DONE" from "TODO" 2013-03-02 Sa 12:00

Actually there are not so many places where Java 7 special features are used. With Java 1.6 as the target platform Toxic might get interesting to a broader audience.

DONE Java Release 0.1.b

  • State "DONE" from "TODO" 2013-01-13 So 14:10

DONE Write some benchmarks to see how fast/slow Toxic is

  • State "DONE" from "TODO" 2013-01-13 So 14:08

Measuring for pure rendering speed, i.e. write the content to the output stream.

DONE B1.0.a-1 Empty XML Element BUG

  • State "DONE" from "WAIT" 2013-01-09 Mi 22:03
  • State "WAIT" from "TODO" 2013-01-07 Mo 22:20
    Have a working compromise - it's just a hack!
The XmlTemplateParser creates "wrong" output from empty-element tags. Though the XML 1.0 specification defines both forms <br/> and <br></br> to be empty elements, this is not really useful to generate HTML. At last Firefox and Chromium issue two line breaks for <br></br> when using XML as HTML. Perhaps generating real XHTML could help.

Unfortunately this seems to be not easy to control: See this discussion at stackoverflow. Current compromise: Prefer <br/> over <br></br>.

The XmlTemplateParser will produce only the short variant of empty elements. For XML both variants are considered equivalent. When using XML for HTML (not XHTML) converting <br></br> to <br/> is not a real drawback.

Current implementation is not really nice but the behavior of the XmlStreamWriter regarding this is not easy to control. However its not that much of a hack nay more.

DONE Refactor API of TemplateParser and TemplateSet

  • State "DONE" from "TODO" 2013-01-09 Mi 22:14

It is not the task of the both classes to create Template object but only to initialize them based on template definitions. If the user, or some factory, creates templates it is easier to create specialized templates and also specializations of Bount that have specific binders. This could support better OO style coding:

class TableRow extends Bount {
    public TableRow( Template t ) {
        super( t );
        phCol1 = t.getIndices( "col1" );
        phCol2 = t.getIndices( "col2" );

    public void bindCol1( ContentFrom<ABean> c ) {
        bind( phCol1, c );

    public void bindCol2( Content c ) {
        bind( phCol2, c );

    private int[] phCol1;
    private int[] phCol2;


DONE Specific Exceptions

  • State "DONE" from "TODO" 2013-01-09 Mi 22:14

Instead of throwing RuntimeException everywhere use specific ToxicExceptions.

DONE Java Release 0.1.a

  • State "DONE" from "TODO" 2013-01-02 Mi

Make an initial release

Author: Marcus Perlick

Date: May 25, 2014

HTML generated with emacs org-mode & Toxic by [qb]