Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41F3D7EE.80005@nada.kth.se>
Date: Sun, 23 Jan 2005 17:59:26 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: dynamic macro junit test [was: jx : cocoon.request object ??]
References: <cso8cc$blt$2@sea.gmane.org> <41EFB2FB.3020608@mobilebox.pl>
 <csogis$6i3$2@sea.gmane.org> <41EFCBFF.1090306@mobilebox.pl>
 <41EFD05E.6010309@schaubroeck.be> <41EFD0F3.3090106@mobilebox.pl>
 <41EFD3AC.6090308@nada.kth.se> <41F1188F.7030003@mobilebox.pl>
 <41F25DF1.8040404@nada.kth.se> <41F29C27.4070406@mobilebox.pl>
 <41F3731A.2040101@nada.kth.se> <41F39146.5040301@mobilebox.pl>
In-Reply-To: <41F39146.5040301@mobilebox.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>> Leszek Gawron wrote:
>>> Daniel Fagerstrom wrote:
>>>> Leszek Gawron wrote:
>>>>> Daniel Fagerstrom wrote:
>>>>>
>>>>>> Your (and others) work is needed, so that we can make the 
>>>>>> refactored JXTG stable enough for production use soon.
>>>>>
>>>>> I've been trying to trace down the problem with non working dynamic 
>>>>> macro test case. Funny thing is the same exception 
>>>>> (NumberFormatException) gets thrown for "old" JXTG.
>>>>
>>>> That at least means that I haven't broke it ;) It might even be good 
>>>> that it doesn't work as that could mean that nobody use it and it 
>>>> would be easier to deprecate and replace with something better.
>>>
>>> I am using it in my projects - and it works! This is one of most 
>>> common technique of mine to write more advanced macros. Magic? I 
>>> guess :)
>>
>> Ok, then it would be good if you wrote a test case that works in the 
>> original JXTG so that we can check that it still work in the 
>> refactored version. I just took the example from the documentation and 
>> made a test case from it.
> 
> I checked it - works only when the pipeline is invoked from flow. Still 
> I have no idea how that affects parsing ${tags.example} expression.

Neither have I, the test case only acceses variables that are defined in 
the current context, so how what it got (or not got) from flow can 
affect it is unclear to me.

Just to avoid missunderstandings, exactly what have you tested? Original 
JXTG and refactored JXTG and for both: with and whithout flow?

The problem (or at least one of them), seem to be connected to the 
hashmap. I checked in a new test case: jxSet, that works for a simple 
assignement but not for a hashmap.

/Daniel