Bugs discovered by me
2009-05-26 Argument checking is inconsistent
Loading via one of the ctors that take a Reader does cause requirement for arguments matches...sometimes. Here's what seems to happen:
| Condition |
Attrib set by caller |
Arg declared in template |
Arg/attrib used in expression |
Result |
|---|---|---|---|---|
| Correct |
Yes |
Yes |
Yes |
OK |
| Missing arg declaration |
Yes |
No |
n/a |
Exception "no such attribute" |
| Yes |
Yes |
No |
No message, maybe don't care | |
| Needed attrib not supplied |
No |
Yes |
Yes |
No error message, attrib acts like null string. (But this could be desirable behavior.) |
| No |
No |
Yes |
In simple expression: Treat as null: This seems like a bug Passed to other template: Exception: "no such attribute" |
|
| No |
Yes |
No |
No message, maybe don't care |
|
| No |
No |
No |
Don't care |
Abberations:
| Case 1 |
Case 2 |
Case 3 |
Case 4 |
|---|---|---|---|
| arg2 used in expression but not in arg list |
arg2 not in arg list, but passed to called template: fails |
Called template uses arg that's not in its own arg list, but gets it from caller template's context. |
Called template references arg2, fails. |
| |
|
|
|
| Result: arg1: [ Value1 ] arg2: [ ] inner: [ X Value1 X ] |
Error: no such attribute: arg2 in template context [outer <invoke inner arg context>] |
arg1: [ Value1 ] arg2: [ ] inner: [ X Value1 X ] |
Error: no such attribute: arg2 in template context [outer inner] |
ie: Does NOT object to undeclared use of $arg2$ in outer, but does object to it not being available to inner!
Bottom line: Seems like inconsistent coverage of error cases.
MoreAbberations?
| Case 5 |
Case 6 |
Case 7 |
Case 8 |
|---|---|---|---|
| a |
a |
C |
C |
| |
|
|
|
| Result: arg1: [ Value1 ] inner: [ X X ] |
Error: no such attribute: argX in template context [outer <invoke inner arg context>] |
a |
E |
2009-05-26 In STG file: Declared arguments ignored when loaded by grouploader.
If an stg file is loaded by grouploader, the templates' argument lists seem to have ne effect. Subsequent invocation of the templates ignores the arguments, behaves like *.st behavior.
2009-05-26 group file name <> group name: No warning or errror
Once loaded, the name provided to the internal group statement seems to prevail?
2009-05-26 PathGroupLoader.loadGroup doesn't honor STG.registerDefaultLexer
2009-05-25 Possible wrong delims for supergroup
2009-05-22: Flaky handling of defaultGroup objects
a) StringTemplate(java.lang.String template, java.lang.Class lexer)
On each call, the lexer-setting constructor creates a instance of StringTemplateGroup all named "defaultGroup". Each successive one bumps previous ones out of the singleton static StringTemplateGroup.nameToGroupMap. (This map is used to find supergroups by name when a new STG is given a supergroup.) So now there are multiple default STGs, only the most recent one in the map, the rest referenceable only through their member templates?
b) Putting an STG named defaultGroup into nameToGroupMap seems asking for trouble anyway, from some situation where someone decides to assign an STG a supergroup called "defaultGroup".
2009-05-22: Calling StringTemplate.setName() doesn't update Group's templates HashMap
... so subsequent scripts can only find this template by its old name, if any. This effectively prevents StringTemplates created using the StringTemplate constructor from having useful names and being mutually callable, even if made a member of a group. It also defeats a scenario that the API seems to suggest - assembling a group in an STG from multiple individual STs.
I'm coming to the conclusion that STG.defineTemplate is the way to go.