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.
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.
Releases
DONE Java Release 0.2.0
- State "DONE" from "TODO"
DONE Deep Fixing of Bout
- State "DONE" from "TODO"
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"
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"
DONE Write some benchmarks to see how fast/slow Toxic is
- State "DONE" from "TODO"
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"
-
State "WAIT" from "TODO"
Have a working compromise - it's just a hack!
- Description
-
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>
. - Fix
-
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"
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; }
Depenedncies
DONE Specific Exceptions
- State "DONE" from "TODO"
Instead of throwing RuntimeException
everywhere use specific
ToxicExceptions
.
DONE Java Release 0.1.a
- State "DONE" from "TODO"
Make an initial release
Date: May 25, 2014
HTML generated with emacs org-mode & Toxic by [qb]