On Tue, 14 Sep 2004 17:31:17 -0400, Ross, Douglas <[EMAIL PROTECTED]> wrote:
> Nic,
>
> I don't know how Struts or JSTL deals with arrays of request parameters
> but the following might be helpful:
>
>
>
>
>
>
>
>
>
>
> On the server, you can access the arrays as follows:
>
> <%
>
Would be useful to do this:?
...${param[theIndex].value}...
At 14:07 14/09/2004 -0700, you wrote:
I had to depend on the order in my instance. I had 15 params that were
repeated three times (each for a different variant), so I wanted to loop
through each param, and also know if I was on the fi
Nic,
I don't know how Struts or JSTL deals with arrays of request parameters
but the following might be helpful:
On the server, you can access the arrays as follows:
<%
String[] colors = request.getParameterValues("colors");
String[] textures = request.getParameterValues
I had to depend on the order in my instance. I had 15 params that were
repeated three times (each for a different variant), so I wanted to loop
through each param, and also know if I was on the first,second or third
set of data. So basically, I wanted param.currentparam[current_set].value.
I co
In this case, ignoring the order the order is not defensive programming
(avoiding not expectable bad cases) but avoiding coupling with the
implementation of the server (Tomcat) and avoiding extra requiriments for
the calling entity (call me with this params *and in this order*).
[9] works if th
Defensive programming might suggest that one presume the worst not the
spec.
At any rate, presuming you intend and design the nth element is *always*
the one you use from the request, does the following work?
I don't use el enough to remember all the nuances.
Doug
-Original Message-
On Tue, 14 Sep 2004 15:18:24 -0400, Kris Schneider <[EMAIL PROTECTED]> wrote:
> I was thinking more along the lines of the HTTP spec not guaranteeing the order.
> So that if you made the same request with parameters "foo" and "bar", in some
> cases "foo" might be first and in other cases it might b
Hi Kris,
Thanks!
I thought I had tested it under the app's WEB-INF/lib, but the jars were
also in tomcat's shared/lib at the time. I also got it working via a
tagPlugins.xml in the app's WEB-INF, but this way is much cleaner.
Serves me right for deviating from the docs.
Cheers,
Patrick.
Kris Sc
If you dump stuff in $CATALINA_HOME/shared/lib, then Tomcat internal classes
can't "see" it:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
Generally speaking, it's best to keep taglib JAR files in the app's WEB-INF/lib
directory.
Quoting Patrick Bourke <[EMAIL PROTECTED
There is another factor: the submitting form. If the form change the
order of the inputs (or includes or excludes something) the indexed access
is lost.
It is, if you assume ordering on the parameters, you are adding a lot of
coupling with the referrer.
At 11:57 14/09/2004 -0700, you wrote:
I was thinking more along the lines of the HTTP spec not guaranteeing the order.
So that if you made the same request with parameters "foo" and "bar", in some
cases "foo" might be first and in other cases it might be "bar".
Quoting Martin Cooper <[EMAIL PROTECTED]>:
> On Tue, 14 Sep 2004 13:31:22
On Tue, 14 Sep 2004 13:31:22 -0400, Kris Schneider <[EMAIL PROTECTED]> wrote:
> Well, even if you could do it cleanly, there's no guarantee on the ordering of
> request parameters.
Although the Servlet spec doesn't state it explicitly, it does
actually specify that the order of values for a given
Hi all,
I'm trying to get up and running with the JSTL standard tags, and am
receiving a compile error that I can't sort out. I've got a simple page
with which I'm tying to use the JSTL core and fmt namespaces. Here is my
JSP page:
<[EMAIL PROTECTED] language="java" contentType="text/html" %>
<
Increasing the buffer size may only mask the problem. You have to be
careful to understand what is happening: once any content in the buffer
has been commited to the response, a redirect may not be valid.
You definitely need to decide on the "view" (which redirect you want)
before you get to your
Nic Werner wrote:
Greetings again,
I've noticed a problem with redirect if I have a good chunk of code,
where it won't redirect and I get this log error:
- Root Cause -
java.lang.IllegalStateException
at
org.apache.coyote.tomcat4.CoyoteResponseFacade.sendRedirect(CoyoteResponse
The "better pattern" is don't use a JSP to issue a redirect (or a forward for
that matter). This is much better suited to a Filter or a Servlet or a
controller component of an MVC framework (like Struts).
Quoting Nic Werner <[EMAIL PROTECTED]>:
> Greetings again,
> I've noticed a problem with
Well, even if you could do it cleanly, there's no guarantee on the ordering of
request parameters. Are you really just checking to see if a particular
parameter has been passed? If so, you should be able to do that with just:
...
Quoting Nic Werner <[EMAIL PROTECTED]>:
> Thanks everyone for
Greetings again,
I've noticed a problem with redirect if I have a good chunk of code,
where it won't redirect and I get this log error:
- Root Cause -
java.lang.IllegalStateException
at
org.apache.coyote.tomcat4.CoyoteResponseFacade.sendRedirect(CoyoteResponseFacade.java:338)
Thanks everyone for the help. I ended up taking your examples, and just
'on the side' iterating through the paramValues until I found the
matching one, and then setting a temp flag. Its unfortunate that I
couldn't just use an index to access the nth param and its nth value.
- Nic.
Helios Alonso
Helios -- you're pretty much right. My reason is basically academic; let
me exlain -- The Struts bean:write tag applies the pattern as a
localized pattern if the pattern is retrieved using the formatKey
attribute. I was basically trying to find out if there was a way to
emulate this behavior in
Maybe you have to explain why you need to localize your pattern. I mean,
can't you use a non-localized pattern even if you have one for each locale?
At 16:50 13/09/2004 -0400, you wrote:
Is it possible to apply a localized pattern when using the
fmt:formatNumber tag?
In other words, I would li
21 matches
Mail list logo
