Maybe I'm crazy, but here is an idea. When using a template variable
which happens to be an array or list as a scalar, instead of using
toString() as the value, use the first item's toString(). If I have a
string array of size one under key 'name', ${name} will be replaced
with, say, "[Ljava.lang.String;@4dd1b". Which is useful only insofar as
it tells me, the template author, that I need to use #foreach.
I suggest this because it would be useful to create a per-request
VelocityContext object that takes as its first constructor argument the
result of 'new HashMap(request.getParameterMap())'. This effectively
allows me to treat request parameters the same as request scoped
objects, which greatly reduces the mundaneity of writing a typical
webapp. The most annoying common thing I find myself doing is
ctx.put(paramName, request.getParameter(paramName)), just so the values
that are posted are available not only to my request handler, but also
to the resulting template page. This is incredibly useful for
maintaining relatively stateless pages.
Anyway, the javadoc for ServletRequest.getParameterMap() says this:*
*
--
Returns an immutable java.util.Map containing parameter names as keys
and parameter values as map values. The keys in the parameter map are of
type String. The values in the parameter map are of type String array.
--
Thus back to my original suggestion. Right now of course, I get
[Ljava.lang.String;@xxxxxx for all my request parameters that I try to
access on my template, unless I wrap them with an impotent foreach:
#foreach($myvar)$myvar#end.
Am I goofy? Would it break anything to treat lists as scalars when they
are in scalar context in a template? I can't imagine anyone uses the
current output of such a variable, other than for debugging purposes.
Jason Pettiss
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
