Yes. Started looking at it last night.
Not sure what all the fuss is about with XML-RPC. It's just sending XML
via post... I've been doing that just using JSP and taglibs for a while.
It's just that, because we don't follow a standard, our protocol is
technically a hack, so I need to evaluate
I need to do that kind of thing a lot.
Here's my boilerplate:
select name=Select Name Here size=1
c:forEach var=varNameHere items=${varsVector} varStatus=current
c:choose
c:when test=${your_test_here}
option selected value=your_value_here Your Display Text Here /option
quote who=Don Albertson date=[041005 09:32]/
I need to do that kind of thing a lot.
Here's my boilerplate:
select name=Select Name Here size=1
c:forEach var=varNameHere items=${varsVector} varStatus=current
c:choose
c:when test=${your_test_here}
option selected
I'm writing a custom tag, and using 'JavaServer Pages' as a good guide.
Its helpful, but I'm confused about the difference between Simple Tag
Handlers and Classic ones.
The book states that a Simple handler 'cannot contain Java code
(scripting elements)', but I'm seeing Java in these
Nic Werner wrote:
I'm writing a custom tag, and using 'JavaServer Pages' as a good guide.
Its helpful, but I'm confused about the difference between Simple Tag
Handlers and Classic ones.
The book states that a Simple handler 'cannot contain Java code
(scripting elements)', but I'm seeing
Why use the otherwise clause? I just use an 'if' tag inline.
select name=Select Name Here size=1
c:forEach var=varNameHere items=${varsVector} varStatus=current
option c:if test=${your_test_here} selected /c:if value=your_value_here Your Display Text Here /option
/c:forEach
I have my boilerplate set up that way because sometimes there is more
that is different than just the selected. More importantly it makes
it absolutely clear to someone else what my intent is. Having spent a
lot of time doing maintenance on other peoples' code, I find it more
efficient in the
And
option c:if...
is not XML.
At 14:47 05/10/2004 -0400, you wrote:
I have my boilerplate set up that way because sometimes there is more
that is different than just the selected. More importantly it makes
it absolutely clear to someone else what my intent is. Having spent a
lot of time doing
Hi,
I upgraded to JSTL 1.1 because we are now using Tomcat 5. At first I tried
the c.tld taglib. But this did not work. For example the result of c:out
value=${aVariable} / for aVariable set to 100 was simply ${aVariable}
instead of 100.
When I changed the c taglib to c-1_0.tld I got the
Hi,
I'm battling what seems to be a pretty elementary problem:
x:parse var=xrpcResponse
person
firstname nickname=falseBen/firstname
lastnameAnderson/lastname
/person
/x:parse
x:out select=$xrpcResponse//firstname/
This should work, correct? I've been trying so many variations of this
Ben Anderson wrote:
I'm battling what seems to be a pretty elementary problem:
x:parse var=xrpcResponse
person
firstname nickname=falseBen/firstname
lastnameAnderson/lastname
/person
/x:parse
x:out select=$xrpcResponse//firstname/
This should work, correct?
Confirmed that it works on
Thanks for the sanity check. I got it fixed. It was a dependency
issue. For someone reason I had placed jaxen in one of the
classloaders. Not too sure why I did that - but deleting it fixed my
problem.
-Ben
Hassan Schroeder wrote:
Ben Anderson wrote:
I'm battling what seems to be a pretty
On Tue, 2004-10-05 at 20:03, Dirk Manske (Mailing list) wrote:
I upgraded to JSTL 1.1 because we are now using Tomcat 5. At first I tried
the c.tld taglib. But this did not work. For example the result of c:out
value=${aVariable} / for aVariable set to 100 was simply ${aVariable}
instead of
13 matches
Mail list logo