two remarks about the ParameterParser :
1/
I did not catch why ParameterParser was not a ViewTool. Is it because Struts can't
give away access to the servlet context ? (sorry,
I'm not [yet?] very aware of Struts, maybe 'cause I like lightweight tools rather than
heavy multipurpose frameworks).
2/
(supposing that the response to 1/ is that it would be possible for the
ParameterParser to access the servlet request at some
initialization time)
since most of the time parameters are strings (or string numbers that will have a
chance to be converted back to numbers anywhere in
higher layers in the controller, where this conversion should be more accurate than in
the view), why not include a generic getter
that would allow "dotted" vtl referencement of parameters, a la "$query.myparam", with
something like :
init method
{
Enumeration params = request.getParameterNames();
while (params.hasMoreElements()) {
String param = (String)params.nextElement();
String values[] = request.getParameterValues(param);
if (values.length == 1) innerMap.put(param,values[0]);
else innerMap.put(param,Arrays.asList(values));
}
}
public void get(String key) {
return innerMap.get(key);
}
CloD
----- Original Message -----
From: "Nathan Bubna" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[EMAIL PROTECTED]>
Sent: vendredi 12 juillet 2002 16:29
Subject: Re: Is there a target release date for the VelocityStrutssubproject?
> Claude said:
> >
> > > Is everyone happy with the toolbox stuff?
> >
> > Are we speaking of the veltools subproject, or of the velstruts
> subsubproject ?
> >
> > (release grannulosity annoying question ?)
>
> a good question. this does make a difference for me. i'm very happy with
> the velocity-struts package. i think that's working great. as for the rest
> of the tools subproject, i still have a few changes i'd really like to see.
> the biggest one is the ParameterParser in the tools package. i still find
> its current state to be needlessly unwieldy. i submitted a patch to make
> it more user-friendly and fix a bug in getNumber(String), but i haven't
> gotten any feedback on it nor seen it committed.
>
> apart from that, the only other issue i know of is Tim's question:
>
> Tim said:
> > How would I disallow an HTML designer from invoking any public method
> > they please on that $application variable? (ex.
> > $application.removeAttribute("it_would_be_bad_to_remove_me")
>
> i also submitted a more hesitant patch/answer for this. it worked for me,
> but perhaps it needs further review/discussion?
>
> overall, i'm pretty happy with things. i did a fairly simple
> proof-of-concept app with velocity tools/struts some time back, and now i'm
> actually in the middle of rewriting a very large/complex app with it. it's
> going quite well so far. this time i've had to extend the VVS to do some
> more fancy things (layouts, custom error screen, etc.), but the rest is
> pretty much sufficient as is (except, of course, the current
> ParameterParser. i'm using my patched version.).
>
> Nathan Bubna
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
