You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by jeff <jl...@houseofdistraction.com> on 2000/12/21 23:50:32 UTC

Context caveat: StringBuffer vs String

I just discovered that StringBuffer is not automatically coerced into a
string when calling functions from within a template.  E.g. for a
function
	String func( String arg );
on an object $foo, a call in the template of
	$foo.func( $bar )
will fail if $bar is a StringBuffer but not if $bar is a String.

I'm not sure if this counts as a bug, but it is good to know.  The
workaround for this is either to not add a StringBuffer directly to the
context or to make sure that all relevant functions accept args of type
Object.

Re: Context caveat: StringBuffer vs String

Posted by j <jv...@periapt.com>.

On Thu, 21 Dec 2000, jeff wrote:

> I just discovered that StringBuffer is not automatically coerced into a
> string when calling functions from within a template.  E.g. for a
> function
> 	String func( String arg );
> on an object $foo, a call in the template of
> 	$foo.func( $bar )
> will fail if $bar is a StringBuffer but not if $bar is a String.
> 
> I'm not sure if this counts as a bug, but it is good to know.  The
> workaround for this is either to not add a StringBuffer directly to the
> context or to make sure that all relevant functions accept args of type
> Object.
> 

You can certainly add a StringBuffer to the context and use
it in a template like the following:

$stringBuffer

The toString() method will be called and it will work fine,
but as far as methods go, why would velocity coerce any
parameters? If the signature of your method is

String func (String a)

Then you have to pass in a String object to your
method? If you're adding something to the context
and you want it to be a string then you convert it :-)

jvz.