On Mon, Dec 8, 2008 at 8:36 AM, Steve O'Hara
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> We have upgraded to 1.6 but still have this issue.
> I've condensed it down to the following;
>
> #set($steve="old value")
> #macro(tmpMacro $steve)
> #set($steve="new value $steve")
> $steve
> #end
> #tmpMacro("dave")
What are your velocity.properties?
> As you can see, there is some messing with the scope going on here but
> this is in essence what is occurring in our application on a much larger
> scale.
> I would expect the result to be "new value dave" but it's not, bizarrely
> it's "dave"
>
> Are we running foul of some golden rules here concerning scope and
> variable names?
>
> Steve
>
> Nathan: I didn't re-open the JIRA issue just in case this is down to our
> own stupidity
that's fine, but it probably is better to keep track of things in one
spot. why don't you go ahead and re-open it and post this
re-assertion of the problem (along with your velocity.properties
settings) there.
>
>
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> .org] On Behalf Of Steve O'Hara
> Sent: 18 September 2008 11:59
> To: Velocity Users List
> Subject: Caching Problem with Macros
>
> Hi All,
>
> I'm re-raising this issue because it has just bitten us in the backside
> again.
>
> Here's the scenario; we have a framework that allows us to reload the
> Velocity runtime so that we can tinker with caching etc at runtime. We
> normally run development with template caching turned off and deliver to
> the client with caching turned on.
>
> There is a problem with inline macros (probably macro libraries too, not
> sure) whereby they will behave differently once they are compiled and
> cached then when they are interpreted at runtime. It is all to do with
> the re-assignment of parameter variables within the macro.
>
> Here is a very simple example;
>
> #macro(tmpMacro $FieldNames)
> #set($FieldNames="ingredient." +
> $FieldNames.replaceAll(",",",ingredient."))
> .....
> #end
>
> #tmpMacro("one,two,three")
>
> This works fine when the template is not cached - as soon as you turn on
> caching, the macro becomes unreliable.
> My original prognosis was that we were upsetting the variable types by
> converting strings into lists but as you can see, that isn't the case in
> this example. The problem is solved by changing the assignment to;
>
> #set($Names="ingredient." +
> $FieldNames.replaceAll(",",",ingredient."))
>
> I can appreciate that maybe this type of "re-assignment" of parameters
> might be an issue, but the real problem is the inconsistency between the
> cached and non-cached behaviours.
>
> I'll raise this as a bug.
>
> Regards,
>
> Steve
>
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> .org] On Behalf Of Steve O'Hara
> Sent: 26 June 2008 18:58
> To: Velocity Users List
> Subject: RE: Strange Caching Problem with Macros - RESOLVED
>
> Hi Nathan,
>
> By cutting down the example to it's bare bones, I've discovered the
> problem.
>
> The following statement causes some sort of error within Velocity (not
> announced in the logger) that only occurs when the template is cached.
>
> #set($FieldNames="one,two,three")
> .......
> #set($FieldNames=$utils.splitToList($FieldNames,","))
>
> I think that maybe we're playing fast and loose with velocity and it's
> type management, because what we're doing here is assigning a List to
> the same variable that formerly contained a String.
>
> When this is run without caching it works fine but once caching is on,
> it fails.
> By changing the statement to this, it works fine.
>
> #set($FieldNamesList=$utils.splitToList($FieldNames,","))
>
> Perhaps not really a bug, more of a nudge for us to remember that
> velocity is not type-less?
>
> Thanks,
> Steve
>
>
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> .org] On Behalf Of Nathan Bubna
> Sent: 24 June 2008 03:32
> To: Velocity Users List
> Subject: Re: Strange Caching Problem with Macros
>
> can you replicate this with a simpler example at all? it's a bit hard
> to spot the tree in the forest. :) it's not obvious to me what the
> problem is, and i can't run your example, so it's rather hard to track
> down. could you also let us know what version of Velocity this is and
> perhaps what your velocity.properties are when you experience this?
>
> On Sun, Jun 22, 2008 at 4:55 AM, Steve O'Hara
> <[EMAIL PROTECTED]> wrote:
>>
>> I'm getting a problem when caching is turned on whereby a method call
> is
>> not being run consistently.
>>
>> I have a macro as per below;
>>
>> #macro(macroShowGrid $FieldNames $SortFieldName)
>>
>> #set($Rows=$Entity.getConstituentGrid($FieldNames,$SortFieldName))
>> #if ($PreviousBrand)
>>
> #set($OldRows=$PreviousBrand.getConstituentGrid($FieldNames,$SortFieldNa
>> me)) #end
>> #set($FieldNames=$utils.splitToList($FieldNames,","))
>>
>> #foreach($Row in $Rows)
>> <tr>
>> #foreach($Field in $FieldNames)
>> #if ($velocityCount==1) #macroWriteImage($Row
> $Field
>> "") #end
>> <td
>> style="background-color:white;vertical-align:top;">
>> #if ($velocityCount==1)
>> #set($Number=$Row.get($Field))
>> #if($Number.matches("[0-9]+"))
>>
>>
> #set($Url="$AppPath/$PageType/explorer?datasrc=$DataSource&new&view=bran
>> d&key=$Number")
>> #else
>>
>>
> #set($Url="$AppPath/$PageType/explorer?datasrc=$DataSource&new&view=inde
>> x&minutenumber=$Number")
>> #end
>> <a href="$Url" target="_blank"
>> #macroMouseOver("View this record")>$Row.get($Field)</a>
>> #else
>> $Row.get($Field)
>> #end
>> </td>
>> #end
>> </tr>
>> #end
>> #end
>>
>> This macro is called from with another macro;
>>
>> #macro(macroShowProductIngredients $FieldName $FieldTitle
>> $FieldComment $FieldList $FieldOrder)
>> #if ($Entity.getValue($FieldName).length()>0 ||
>> $Entity.getValue($FieldComment).length()>0)
>> <table border="1" bordercolor="#CDCB99" cellspacing="0"
>> cellpadding="3" bgcolor="#E2E0C8"
>> style="margin-top:8px;margin-left:4px">
>> <tr>
>> <td colspan="5">$FieldTitle</td>
>> </tr>
>> <tr>
>> #set($Fields=$utils.splitToList($FieldList,","))
>> <td nowrap width="100" colspan="2"align="center">Minute
>> Number</td>
>> <td nowrap width="100%">Description</td>
>> <td nowrap align="center">Level (%)</td>
>> <td nowrap width="150" align="left">Supplier</td>
>> </tr>
>> #macroShowGrid($FieldList $FieldOrder)
>> #set($PreviousFieldValue="")
>> #set($FieldValue="")
>> #if ($PreviousBrand)
>> #set($PreviousFieldValue=$PreviousBrand.getValue($FieldComment)) #end
>> #set ($FieldValue=$Entity.getValue($FieldComment))
>> #if ($FieldValue.length()>0 || $PreviousFieldValue.length>0
>> || $PreviousBrand)
>> <tr>
>> <td bgcolor="#FFFFFF" valign="top" colspan="5">
>> #macroShowValue($FieldValue
> $PreviousFieldValue)
>> </td>
>> </tr>
>> #end
>> </table>
>> #end
>> #end
>>
>>
>>
>> All works fine when caching is turned off but when I turn it on, the
>> method call $Entity.getConstituentGrid($FieldNames,$SortFieldName) is
>> not being run. The value of $Rows is always undefined. I say always,
> I
>> don't mean always, it seems to be a bit intermittent.
>> These macros are inline and I'm using a custom file based resource
>> loader.
>>
>> My understanding of caching was that it cached the structure of the
>> template in an AST, not the contents?
>> I've checked that the $Entity object is valid, which it is and that it
>> has a different Class ID each call, which it does which would indicate
>> the Context is definitely getting given a different Entity each call.
>> The parameters are correct for the call too.
>>
>> Thanks,
>> Steve
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]