pvdung / jmte Goto Github PK

Hello!

  Here is attached pom.xml for JMTE to allow build with Maven (tested on Maven 2.0.9 + JDK 1.6). Tested on SVN version of JMTE (3.0pre)

Known Bugs/Features:
 - Caliper Tests are skipped (there is currently no maven repository providing caliper and no test plugin for maven)
 - some tests fail when timezone is different from MEZ (well, this is not maven bug)

To build/install to local repo use this command:

mvn clean install -Dmaven.test.skip=true

After install you can use this dependency in your project pom.xml:
...
   <dependency>
     <groupId>com.floreysoft</groupId>
     <artifactId>jmte</artifactId>
     <version>3.0-SNAPSHOT</version>
   </dependency>
...

Hello!

  I would like to make final release 3.0 so there would exist official jar in Public Maven repository (they allow only final releases to propagate into repo1.maven.org - development snapshot is already available on https://oss.sonatype.org/content/groups/public/com/floreysoft/jmte/ )

TODO to make release:

* Add fixed issues to Releasenotes.txt
* Update version=3.0 in common.properties
* make release (this automatically Tags release)

TODO after release:
* Add 3.1 pre to Releasenotes.txt
* Update version=3.1pre in common.properties

Oliver, please let me know, if you agree on making release (if yes, please 
reassing this ticket to me).

Hello!

 Current version of JMTE produces output into StringBuilder. This can be unsuitable for large output (for example large List Box created in some JSP page).

 My plan is to create new version of Template.transform which could utilitize java.lang.Appendable interface. This interface provide both of:
- String output like: StringBuilder, StringBuffer, StringWriter, CharBuffer...
- Stream output including: Writer, FileWriter...

All existing Appendable JDK implementations are listed on: 
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Appendable.html

Here are 2 things that need to be figured out:

1. Should I keep existing String transform methods for backward compatibility? 
Or replace them with Appendable?

2. Appendable declares checked IOException (because IO implementations throws 
it). There are two possible solutions:
a) Create RuntimeExAppendable wrapper and use it internaly (in both 
DynamicBytecodeCompiler and InterpretedTemplate to avoid code clutter). 
b) Declare IOException in AbstractTemplate (but it would clutter existing 
applications).

This Enhancement will start in its own branch.

http://repo1.maven.org/maven2/com/floreysoft/jmte/3.0/jmte-3.0.pom

states a hard dependency on asm and junit, but they are both optional.

the following template:

Title: <input type='text' name='title' value=${book.title}/>

produces:  value=symmetry/

and that :
Title: <input type='text' name='title' value=${book.title} />

produces the correct:  value=symmetry

that is when the / is adjacent to the end of the expression it becomes part of 
the value.



Please provide any additional information below.

Hello!

  My plan is to publish JMTE releases to public Maven repository (repo1.maven.org) using instructions on https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

In the documentation we read at several places:
"... It has no external dependencies (except when running in compilation mode) 
..."
However, in the basic "Hello World Example" there is already a dependency on 
asm. Please remove it, because a BIG advantage of this library is its small 
footprint.

BTW Well done this library!

Right now you can only iterate over arrays of Objects Object[], but not int[] 
char[] etc.

It would be great if I could set up an ant task to compile my templates into 
Java code ahead of time. That way, I can tell exactly what the code is doing 
and potentially have no runtime requirement on jmte or any other library at all.

Do you think this might be possible?

Hello!

AbstractTemplate contains:

    protected Engine engine;
    protected String template;
    protected String sourceName;


However even InterpretedTemplate (which inherits AbstractTemplate) contains:

    protected final String template;
    protected final Engine engine;
    protected final String sourceName;

This may cause NullPointerException after some refactoring, for example, when I 
changed original abstract transform method to final:

    public final String transform(Map<String, Object> model, Locale locale,
            ModelAdaptor modelAdaptor, ProcessListener processListener);

  and used another method as abstract:

    public abstract Appendable transformAppendable(Appendable out,Map<String, Object> model, Locale locale,
            ModelAdaptor modelAdaptor, ProcessListener processListener);

This caused such method to use its own (unititalized) "engine" field from 
AbstractTemplate and results in NullPointerException.

Proposed fix: removing duplicate fields:

    protected final String template;
    protected final Engine engine;
    protected final String sourceName;
from InterpretedTemplate.

Please let me know, if you agree - I can commit this change (to current trunk).

What steps will reproduce the problem?
1. No way to identify the index in an interation.

What is the expected output? What do you see instead?
${foreach array item}
${index_item}. ${item}
${end}

1. item A
2. item B
3. item C

What version of the product are you using? On what operating system?
3.0

Please provide any additional information below.
Added ${index_???} function the com.floreysoft.jmte.template.AbstractTemplate . 

Hello!

Here is attached new pom.xml with one fix and one enhancement:
1. binary containted sources by mistake
2. configured proper javadoc goal

  Also added description element with build instructions.

We an ANT build file to
- build
- create jars
- create Javadoc API
- create distribution (full only including jar, src, doc)

Even though expression shall remain minimal a not operator "!" would simplify 
quite a number of statements without adding too much complexity.

- Engine (incomplete)
- ErrorHandler (missing)
- Tool (missing)

What steps will reproduce the problem?
1.
Create model data, which contains back-slashes, for examle:
Map<String, Object> model = new HashMap<String, Object>();
model.put("str", "Hello \\ world!");
2.
Transform them:         String output = newEngine()
                .transform(
                        "${str}",
                        model);

The output incorrectly strips backslash in data.

3. What is the expected output? What do you see instead?
Output: Hello  world!
Assumed output: Hello \ world!

What version of the product are you using? On what operating system?
3.0pre, Win XP, JDK 1.6

Please provide any additional information below.
It seems that Template.transform(), improperly call:
            String unescaped = Util.NO_QUOTE_MINI_PARSER.unescape(transformed);

for both - template and model data.

But it should be called for template only (data should be always left intact).

Enhanced JUnit test (patch) attached bellow.

A common requirement is to have a dependency of the format of rows in a 
foreach loop to the rows position in the iterated items.

E.g. the first item shall be fett, the last one grey. Or rows in a table 
shall have alternating format depending whether their row number is even or 
odd. 

There already is a very special case of format depending on position in the 
itmes: The separator.

It might be a good idea to have a more general concept that includes what 
you can do using a separator, but goes beyong it. The separator concept 
should remain unchanged, though. 

Possible list of special variables
- first
- last
- odd 
- even

Special variables shall be suffixed by the name of the item variable.

Example:

${foreach items item}
  ${if first_item}
    <em>${item}</em>
  ${else}
    ${item}
  ${end}
${end}

Looking at the sources for Engine (JMTE v3.0) I see this at line 114:

// compiler plus all compiled classes live as long as this engine
private TemplateCompiler compiler = new DynamicBytecodeCompiler();

should be replaced by setting the compiler only when actually needed

Please make a way to use Util.RAW_MINI_PARSER as a final filter for the 
substituted data.

What steps will reproduce the problem?
1. ${model.property} works
2. ${model.callMethod(withParameter)} does not.

What is the expected output? What do you see instead?
Output results of the method call.

What version of the product are you using? On what operating system?
3.0

Please provide any additional information below.
This function uses beanshell to perform script evaluation .

Please publish the latest version (3.1) in Central Maven (now only 3.0 is 
available)

What steps will reproduce the problem?
1.
Run JUnit tests on other Locale than Germany, or other Timezone than MEZ, for 
example on English Windows with CET Timezone run:

mvn clean test
2.
The date based tests will fail with message like:

org.junit.ComparisonFailure: expected:<...1970.01.01 01:00:00 [MEZ]" and 
"01.01.1970 01...> but was:<...1970.01.01 01:00:00 [CET]" and "01.01.1970 01...>

(Note: the "but was:" part may be different on another system).

What is the expected output? What do you see instead?

Expected Central European Time: 1970.01.01 01:00:00 [MEZ]

Got local Zone/name: 1970.01.01 01:00:00 [CET]

Please use labels and text to provide additional information.

There are basically two problems:
1. NamedDateRendered produce date/time with current TimeZone, but JUnit tests 
assume MEZ
2. Java use OS based TimeZone names which are very difficult to change (CET is 
technically equivalent to MEZ, but I don't found a way how to force Java to use 
MET on non-Germany OS).

The 1. could be easilly solved using one of two:
a) JUnit test comparing date/time using current timezone
b) change NamedDateRenderer to use hardcoded TimeZone (but it is desireable?)

The 2. is more complex - I tried to inititalize DateFormat with locales, 
calendars, etc... but have never chance to change "CET" timezone name into 
"MEZ"...

It's not a bug, just a little observation. 
While trying to get desired result from 'foreach' I've collected 4 use cases. 
It's exemplarily to understand from where the empty strings come in each case. 
The result I needed is in 'use case 2', but I started from template of 'use 
case 3' because visually it looked natural.
Use case 1:
Template:
Users:
${foreach users item}${item.Number}.
Name: "${item.Name}"
Password: "${item.Password}"                           
${end}
Bye
Result of transforming:
Users:
1.
Name: "Name1"
Password: "Password1"                           
2.
Name: "Name2"
Password: "Password2"                           

Bye
Use case 2:
Template:
Users:${foreach users item}
${item.Number}.
Name: "${item.Name}"
Password: "${item.Password}"                           
${end}
Bye
Result of transforming:
Users:
1.
Name: "Name1"
Password: "Password1"                           

2.
Name: "Name2"
Password: "Password2"                           

Bye
Use case 3:
Template:
Users:
${foreach users item}${item.Number}.
Name: "${item.Name}"
Password: "${item.Password}"

${end}
Bye
Result of transforming:
Users:
1.
Name: "Name1"
Password: "Password1"

2.
Name: "Name2"
Password: "Password2"


Bye
Use case 4:
Template:
Users:${foreach users item}

${item.Number}.
Name: "${item.Name}"
Password: "${item.Password}"                           
${end}
Bye
Result of transforming:
Users:

1.
Name: "Name1"
Password: "Password1"                           


2.
Name: "Name2"
Password: "Password2"                           

Bye