[OS-webwork] validator for the optional int field
How should I write a validator for the optional int field in ww2?
I have getter and setter in my action:
public int getYear(){ return year; }
public void setYear( int year ){ this.year = year; }
input field is defined like this:
#tag( TextField label='year' name='year' value=year size='5' )
What should I put into action-validation.xml?
Taavi
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] validator for the optional int field
What do you want to validate about that field?
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 8:04 AM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] validator for the optional int field
How should I write a validator for the optional int field in ww2?
I have getter and setter in my action:
public int getYear(){ return year; }
public void setYear( int year ){ this.year = year; }
input field is defined like this:
#tag( TextField label='year' name='year' value=year size='5' )
What should I put into action-validation.xml?
Taavi
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Lost in the woods once again...
Title: Message
You
can't embed one JSP tag in the attribute value of another JSP page...
Take a
look at the iterator examples that ship with WebWork to see how this could be
done w/ all WW tags (I don't know JSTL that well)
-Original Message-From: Peter White
[mailto:[EMAIL PROTECTED] Sent: Saturday, November 22, 2003 8:17
PMTo: [EMAIL PROTECTED]Subject:
[OS-webwork] Lost in the woods once again...
I'm trying to convert one of the pages of my old
JSP-based wizard over to webwork and I'm at a loss since it doesn't appear
that the ww:iterator tag supports what I'm trying to do. If anyone has any
ideas, I'd be more than willing to try them out since nothing I've tried has
worked so far. Here's what I'm trying to do
Wizard page #1 asks how many items I want to chose
and stores it in model.numItems Wizard page
#2 needs to do something along the lines of:
c:forEach begin='0' end='${model.numItems-1}'
varStatus='status'
ww:set name="count" value='c:out value="${status.count}"/'
scope="webwork" /
ww:set name="index" value='c:out value="${status.index}"/'
scope="webwork" /
trww:select label="Credit Traunch ${#count}"
name="model.creditTraunch[${#index}]"
list="@[EMAIL PROTECTED]()" listKey="['label']"
listValue="['id']" defaultKey="Select"
defaultValue=""//tr
/c:forEach
In this mix of WW JSTL, the JSTL iterator
works correctly and renders the ww:select fields. However, the
ww:set tag isn't taking the value from the JSTL c:out tag. If
anyone knows how to get a JSTL value into WW that would be perfect. As a side
note, I'm using the JSTL request wrapper that was posted to the
list.
Thanks! Peter
Re: [OS-webwork] validator for the optional int field
Sorry for not being clear )
I would like to specify field error message, if the field is filled
with a value but this value is outside of some min-max range.
And I would like to see this field pass this valiation rule if the
field is left empty.
So something like this comes to my mind:
field name=year
field-validator type=optional-int
param name=min6/param
param name=max10/param
messagebar must be between ${min} and ${max}, current value is
${bar}./message
/field-validator
/field
What do you want to validate about that field?
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 8:04 AM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] validator for the optional int field
How should I write a validator for the optional int field in ww2?
I have getter and setter in my action:
public int getYear(){ return year; }
public void setYear( int year ){ this.year = year; }
input field is defined like this:
#tag( TextField label='year' name='year' value=year size='5' )
What should I put into action-validation.xml?
Taavi
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] validator for the optional int field
Did you try the IntRangeFieldValidator? It doesn't require a value...
Actually, if you have a primitive int, it will always get a value and
validate it... If it's an Integer you can have a null value, in which
case it would ignore it.
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 8:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] validator for the optional int field
Sorry for not being clear )
I would like to specify field error message, if the field is
filled with a value but this value is outside of some min-max range.
And I would like to see this field pass this valiation rule
if the field is left empty.
So something like this comes to my mind:
field name=year
field-validator type=optional-int
param name=min6/param
param name=max10/param
messagebar must be between ${min} and ${max}, current
value is ${bar}./message
/field-validator
/field
What do you want to validate about that field?
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 8:04 AM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] validator for the optional int field
How should I write a validator for the optional int field in ww2?
I have getter and setter in my action:
public int getYear(){ return year; }
public void setYear( int year ){ this.year = year; }
input field is defined like this:
#tag( TextField label='year' name='year' value=year
size='5'
)
What should I put into action-validation.xml?
Taavi
---
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive? Does it help you
create better code? SHARE THE LOVE, and help us help YOU! Click
Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive? Does it help
you create
better code? SHARE THE LOVE, and help us help YOU! Click Here:
http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] validator for the optional int field
This is the problem of empty form fields causing type conversion field
errors that I fixed last night... Try the latest
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 10:15 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] validator for the optional int field
I am using Integer instead of int now but whenever
the input field is left blank I am still getting this
Invalid field value for field year message.
So my results so far are like this:
these behave as expected:
validationtest.action
validationtest.action?year=12312313
this gives Invalid field value for field year message:
validationtest.action?year=
I feel that it should not give that error. Removing
year= from url is not an option because this kind
of url is what we get if there is an input form field
that is left blank.
So, what to you think what should be the ww2 way
of validating this kind of field?
best wishes,
Taavi
- Original Message -
From: Jason Carreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 4:15 PM
Subject: RE: [OS-webwork] validator for the optional int field
Did you try the IntRangeFieldValidator? It doesn't require
a value...
Actually, if you have a primitive int, it will always get a
value and
validate it... If it's an Integer you can have a null
value, in which
case it would ignore it.
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 8:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] validator for the optional int field
Sorry for not being clear )
I would like to specify field error message, if the field is
filled with a value but this value is outside of some
min-max range.
And I would like to see this field pass this valiation rule
if the field is left empty.
So something like this comes to my mind:
field name=year
field-validator type=optional-int
param name=min6/param
param name=max10/param
messagebar must be between ${min} and ${max}, current
value is ${bar}./message
/field-validator
/field
What do you want to validate about that field?
-Original Message-
From: Taavi Tiirik [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 8:04 AM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] validator for the optional int field
How should I write a validator for the optional int field in
ww2?
I have getter and setter in my action:
public int getYear(){ return year; }
public void setYear( int year ){ this.year = year; }
input field is defined like this:
#tag( TextField label='year' name='year' value=year
size='5'
)
What should I put into action-validation.xml?
Taavi
---
This SF.net email is sponsored by: SF.net Giveback
Program. Does
SourceForge.net help you be more productive? Does it
help you
create better code? SHARE THE LOVE, and help us help
YOU! Click
Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive? Does it help
you create
better code? SHARE THE LOVE, and help us help YOU! Click Here:
http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webw
ork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive? Does it help you create
better code? SHARE THE LOVE, and help us help YOU! Click Here:
http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OGNL madness - evaluated tag attributes
Patrick Lightbody wrote:
Hmm this is pretty interesting. Id like to hear the opinion from the
1.4 guys on this as well.
I for one dispise the ${} JSTL/whatever syntax above all else. It's just
plain retarded. Now, I realize that having to put ' around strings can
be seen as annoying (although I find the term tripleqouting to be
somewhat misleading), but a way around that could be to introduce a more
obvious syntax like String(my literal string). This is to me much better
than the JSTL way where I have to put ${} around all variables.
Introducing the JSTL syntax will lead to MORE typing, not less.
Maybe the EL parser should be more intelligent with this though. If you
write: ww:property value=foo bar/ it is obvious that this is not a
valid variable name, so the page could just return a big and obvious
error message. This later approach is also backwards compatible.
Anders Hovmller
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] validator for the optional int field
This is the problem of empty form fields causing type conversion field errors that I fixed last night... Try the latest Excellent. Thanks! Now there is still this null pointer exception that happens if I use validator of type fieldexpression and if the field is left blank i.e. when I call validationtest.action?year= java.lang.NullPointerException at ognl.OgnlOps.doubleValue(OgnlOps.java:97) at ognl.OgnlOps.greater(OgnlOps.java:395) at ognl.ASTGreater.getValueBody(ASTGreater.java:51) at ognl.SimpleNode.getValue(SimpleNode.java:167) at ognl.Ognl.getValue(Ognl.java:335) at ognl.Ognl.getValue(Ognl.java:310) at com.opensymphony.xwork.util.OgnlValueStack.findValue(OgnlValueStack.java:92) at com.opensymphony.xwork.validator.validators.ValidatorSupport.getFieldValue(V alidatorSupport.java:90) at com.opensymphony.xwork.validator.validators.FieldExpressionValidator.validat e(FieldExpressionValidator.java:37) at com.opensymphony.xwork.validator.ActionValidatorManager.validate(ActionValid atorManager.java:69) at com.opensymphony.xwork.validator.ActionValidatorManager.validate(ActionValid atorManager.java:55) at com.opensymphony.xwork.validator.ValidationInterceptor.before(ValidationInte rceptor.java:36) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterce ptor.java:36) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.TimerInterceptor.intercept(TimerIntercept or.java:62) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocatio n.java:169) at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:11 6) at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceAction(ServletD ispatcher.java:182) at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatc her.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at com.opensymphony.webwork.lifecycle.RequestLifecycleFilter.doFilter(RequestLi fecycleFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at cmw.filter.SetCharacterEncoding.doFilter(SetCharacterEncoding.java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at cmw.filter.Persistence.doFilter(Persistence.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:171) at
RE: [OS-webwork] validator for the optional int field
What's the expression you're applying to the field? I'll see if I can figure out what the issue is... -Original Message- From: Taavi Tiirik [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] validator for the optional int field This is the problem of empty form fields causing type conversion field errors that I fixed last night... Try the latest Excellent. Thanks! Now there is still this null pointer exception that happens if I use validator of type fieldexpression and if the field is left blank i.e. when I call validationtest.action?year= java.lang.NullPointerException at ognl.OgnlOps.doubleValue(OgnlOps.java:97) at ognl.OgnlOps.greater(OgnlOps.java:395) at ognl.ASTGreater.getValueBody(ASTGreater.java:51) at ognl.SimpleNode.getValue(SimpleNode.java:167) at ognl.Ognl.getValue(Ognl.java:335) at ognl.Ognl.getValue(Ognl.java:310) at com.opensymphony.xwork.util.OgnlValueStack.findValue(OgnlValue Stack.java:92) at com.opensymphony.xwork.validator.validators.ValidatorSupport.g etFieldValue(V alidatorSupport.java:90) at com.opensymphony.xwork.validator.validators.FieldExpressionVal idator.validat e(FieldExpressionValidator.java:37) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:69) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:55) at com.opensymphony.xwork.validator.ValidationInterceptor.before( ValidationInte rceptor.java:36) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:36) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.TimerInterceptor.intercept( TimerIntercept or.java:62) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActio nProxy.java:11 6) at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceA ction(ServletD ispatcher.java:182) at com.opensymphony.webwork.dispatcher.ServletDispatcher.service( ServletDispatc her.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at com.opensymphony.webwork.lifecycle.RequestLifecycleFilter.doFi lter(RequestLi fecycleFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.SetCharacterEncoding.doFilter(SetCharacterEncoding. java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.Persistence.doFilter(Persistence.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardC ontextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at
Re: [OS-webwork] validator for the optional int field
one thing i noticed (from lates cvs head as of a few minutes from sending this email) is that urls like foo.action?myInt=breakMe (myInt is an int, surprised?) are causing INPUT to be returned, i dont think that was happening before, same thing with Date Long Integer long propertys, Jason Carreira wrote: What's the expression you're applying to the field? I'll see if I can figure out what the issue is... -Original Message- From: Taavi Tiirik [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] validator for the optional int field This is the problem of empty form fields causing type conversion field errors that I fixed last night... Try the latest Excellent. Thanks! Now there is still this null pointer exception that happens if I use validator of type fieldexpression and if the field is left blank i.e. when I call validationtest.action?year= java.lang.NullPointerException at ognl.OgnlOps.doubleValue(OgnlOps.java:97) at ognl.OgnlOps.greater(OgnlOps.java:395) at ognl.ASTGreater.getValueBody(ASTGreater.java:51) at ognl.SimpleNode.getValue(SimpleNode.java:167) at ognl.Ognl.getValue(Ognl.java:335) at ognl.Ognl.getValue(Ognl.java:310) at com.opensymphony.xwork.util.OgnlValueStack.findValue(OgnlValue Stack.java:92) at com.opensymphony.xwork.validator.validators.ValidatorSupport.g etFieldValue(V alidatorSupport.java:90) at com.opensymphony.xwork.validator.validators.FieldExpressionVal idator.validat e(FieldExpressionValidator.java:37) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:69) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:55) at com.opensymphony.xwork.validator.ValidationInterceptor.before( ValidationInte rceptor.java:36) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:36) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.TimerInterceptor.intercept( TimerIntercept or.java:62) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActio nProxy.java:11 6) at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceA ction(ServletD ispatcher.java:182) at com.opensymphony.webwork.dispatcher.ServletDispatcher.service( ServletDispatc her.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at com.opensymphony.webwork.lifecycle.RequestLifecycleFilter.doFi lter(RequestLi fecycleFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.SetCharacterEncoding.doFilter(SetCharacterEncoding. java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.Persistence.doFilter(Persistence.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardC ontextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at
RE: [OS-webwork] OGNL madness - evaluated tag attributes
I suppose retarded is in the eye of the beholder...:)
I don't know about it from a JSTL point of view, but velocity uses this
syntax, as does the evaluation that goes on in the xwork config file, as
does Ant, etc. I find it to be very clear. In brackets led by a $, this is
a variable that should be evaluated. As for your suggestion, I'm not sure,
as I can see how certain things can be obvious to a person, but not easy to
make obvious for a machine.
I do like the idea of allowing the user to determine which method to use,
though.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of boxed
Sent: Sunday, November 23, 2003 8:24 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] OGNL madness - evaluated tag attributes
Patrick Lightbody wrote:
Hmm
this is pretty interesting. Id like to hear the opinion from the
1.4 guys on this as well.
I for one dispise the ${} JSTL/whatever syntax above all else. It's just
plain retarded. Now, I realize that having to put ' around strings can be
seen as annoying (although I find the term tripleqouting to be somewhat
misleading), but a way around that could be to introduce a more obvious
syntax like String(my literal string). This is to me much better than the
JSTL way where I have to put ${} around all variables.
Introducing the JSTL syntax will lead to MORE typing, not less.
Maybe the EL parser should be more intelligent with this though. If you
write: ww:property value=foo bar/ it is obvious that this is not a valid
variable name, so the page could just return a big and obvious error
message. This later approach is also backwards compatible.
Anders Hovmöller
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] validator for the optional int field
Do you have the DefaultWorkflowInterceptor applied? If there's an error, it will return INPUT without executing the action... -Original Message- From: Francisco Hernandez [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 1:23 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] validator for the optional int field one thing i noticed (from lates cvs head as of a few minutes from sending this email) is that urls like foo.action?myInt=breakMe (myInt is an int, surprised?) are causing INPUT to be returned, i dont think that was happening before, same thing with Date Long Integer long propertys, Jason Carreira wrote: What's the expression you're applying to the field? I'll see if I can figure out what the issue is... -Original Message- From: Taavi Tiirik [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] validator for the optional int field This is the problem of empty form fields causing type conversion field errors that I fixed last night... Try the latest Excellent. Thanks! Now there is still this null pointer exception that happens if I use validator of type fieldexpression and if the field is left blank i.e. when I call validationtest.action?year= java.lang.NullPointerException at ognl.OgnlOps.doubleValue(OgnlOps.java:97) at ognl.OgnlOps.greater(OgnlOps.java:395) at ognl.ASTGreater.getValueBody(ASTGreater.java:51) at ognl.SimpleNode.getValue(SimpleNode.java:167) at ognl.Ognl.getValue(Ognl.java:335) at ognl.Ognl.getValue(Ognl.java:310) at com.opensymphony.xwork.util.OgnlValueStack.findValue(OgnlValue Stack.java:92) at com.opensymphony.xwork.validator.validators.ValidatorSupport.g etFieldValue(V alidatorSupport.java:90) at com.opensymphony.xwork.validator.validators.FieldExpressionVal idator.validat e(FieldExpressionValidator.java:37) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:69) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:55) at com.opensymphony.xwork.validator.ValidationInterceptor.before( ValidationInte rceptor.java:36) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:36) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.TimerInterceptor.intercept( TimerIntercept or.java:62) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActio nProxy.java:11 6) at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceA ction(ServletD ispatcher.java:182) at com.opensymphony.webwork.dispatcher.ServletDispatcher.service( ServletDispatc her.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at com.opensymphony.webwork.lifecycle.RequestLifecycleFilter.doFi lter(RequestLi fecycleFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.SetCharacterEncoding.doFilter(SetCharacterEncoding. java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.Persistence.doFilter(Persistence.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:256) at
RE: [OS-webwork] OGNL madness - evaluated tag attributes
I really dislike the option of which syntax to use... Lets choose one and use it...
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 2:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes
I suppose retarded is in the eye of the beholder...:)
I don't know about it from a JSTL point of view, but velocity
uses this syntax, as does the evaluation that goes on in the
xwork config file, as does Ant, etc. I find it to be very
clear. In brackets led by a $, this is a variable that
should be evaluated. As for your suggestion, I'm not sure,
as I can see how certain things can be obvious to a person,
but not easy to make obvious for a machine.
I do like the idea of allowing the user to determine which
method to use, though.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of boxed
Sent: Sunday, November 23, 2003 8:24 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] OGNL madness - evaluated tag attributes
Patrick Lightbody wrote:
Hmm... this is pretty interesting. I'd like to hear the
opinion from the
1.4 guys on this as well.
I for one dispise the ${} JSTL/whatever syntax above all
else. It's just plain retarded. Now, I realize that having to
put ' around strings can be seen as annoying (although I find
the term tripleqouting to be somewhat misleading), but a
way around that could be to introduce a more obvious syntax
like String(my literal string). This is to me much better
than the JSTL way where I have to put ${} around all variables.
Introducing the JSTL syntax will lead to MORE typing, not less.
Maybe the EL parser should be more intelligent with this
though. If you
write: ww:property value=foo bar/ it is obvious that this
is not a valid variable name, so the page could just return a
big and obvious error message. This later approach is also
backwards compatible.
Anders Hovmöller
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OGNL madness - evaluated tag attributes
Jason Carreira wrote: I really dislike the option of which syntax to use... Lets choose one and use it... Definitely agree. Think about the case where many components/projects using WebWork needs to be merged into one big app. Oh that won't work because we used optional method Foo, whereas you used Bar is NOT a good situation. Said it before, and will say it again: What makes a framework powerful is not what it allows, but what it does not allow. This is one of those cases where this is really important to remember. /Rickard --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OGNL madness - evaluated tag attributes
What would be realy nice is if the JSTL's EL had ben written with extensibility in mind to begin with, a lot like what Joe Walnes ended up putting into the FormTags project. What worked there is that you had a ww: prefix to specify that the formtags were to use the expression language for webwork, and other prefixes could have been supported as well. I tried to get the JSTL to work this way, but it didn't quite work out the way I wanted (i.e., they decided that nobody needed such a feature, and handed it off to you guys.) It still might be workable from webwork's perspective to use that kind of prefix idea. On Sun, 23 Nov 2003, [ISO-8859-1] Rickard Öberg wrote: Jason Carreira wrote: I really dislike the option of which syntax to use... Lets choose one and use it... Definitely agree. Think about the case where many components/projects using WebWork needs to be merged into one big app. Oh that won't work because we used optional method Foo, whereas you used Bar is NOT a good situation. Said it before, and will say it again: What makes a framework powerful is not what it allows, but what it does not allow. This is one of those cases where this is really important to remember. /Rickard --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- Joseph B. Ottinger http://enigmastation.com IT Consultant[EMAIL PROTECTED] J2EE Editor - Java Developer's Journal [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Lost in the woods once again...
Title: Message
Unless I missed it, the iterator is only capable of
iterating over a collection vs. being able to iterate between a range of
numbers.I believe a valuable enhancement would be to change the
ww:set tag to extend BodySupport instead of TagSupport so you could do
something like this:
c:forEach begin='0' end='${model.numItems-1}'
varStatus='status' cf:set
name="label"'c:out value="Item
${status.count}"/'/cf:set cf:set
name="name"'c:out
value="model.items[${status.index}].id"/'/cf:set
trww:select label="#label" name="#name"
list="@[EMAIL PROTECTED]()" listKey="id" listValue="label"
headerKey="''"
headerValue="'Select'"//tr/c:forEach
This would allow for much more flexible UI's, IMHO. In
fact, you'll notice the cf:set tag in my example - I eventually ended up
rewriting the ww:set tag to extend BodyTagSupport instead of
WebWorkTagSupport and then merged in the necessary code from WebWorkTagSupport
after writing my own doAfterBody(). I'm not sure if modifying WebWorkTagSupport
to extend BodyTagSupport instead of TagSupport would create any problems (it
was4:30 amand I had to call it a night) but is there any reason
SetTag has to extend WebWorkTagSupport? As a side note, I'd send you my version
of SetTag if it weren't for a minor bug... I've got my version working the the
value in the body but I've got to debug an issue with being about to use the
value attribute, if it exists, or the body content, if not. I can debug this
issue and post my version to the list after I meet my deadline in the next day
or two.
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jason CarreiraSent: Sunday, November 23, 2003 5:30
AMTo: [EMAIL PROTECTED]Subject:
RE: [OS-webwork] Lost in the woods once again...
You
can't embed one JSP tag in the attribute value of another JSP page...
Take
a look at the iterator examples that ship with WebWork to see how this could
be done w/ all WW tags (I don't know JSTL that well)
-Original Message-From: Peter White
[mailto:[EMAIL PROTECTED] Sent: Saturday, November 22, 2003 8:17
PMTo:
[EMAIL PROTECTED]Subject: [OS-webwork]
Lost in the woods once again...
I'm trying to convert one of the pages of my old
JSP-based wizard over to webwork and I'm at a loss since it doesn't appear
that the ww:iterator tag supports what I'm trying to do. If anyone has any
ideas, I'd be more than willing to try them out since nothing I've tried has
worked so far. Here's what I'm trying to do
Wizard page #1 asks how many items I want to
chose and stores it in model.numItems Wizard page #2 needs to do something along the lines of:
c:forEach begin='0' end='${model.numItems-1}'
varStatus='status'
ww:set name="count" value='c:out value="${status.count}"/'
scope="webwork" /
ww:set name="index" value='c:out value="${status.index}"/'
scope="webwork" /
trww:select label="Credit Traunch ${#count}"
name="model.creditTraunch[${#index}]"
list="@[EMAIL PROTECTED]()" listKey="['label']"
listValue="['id']" defaultKey="Select"
defaultValue=""//tr
/c:forEach
In this mix of WW JSTL, the JSTL iterator
works correctly and renders the ww:select fields. However, the
ww:set tag isn't taking the value from the JSTL c:out tag.
If anyone knows how to get a JSTL value into WW that would be perfect. As a
side note, I'm using the JSTL request wrapper that was posted to the
list.
Thanks! Peter
Re: [OS-webwork] validator for the optional int field
i do have the workflow interceptor on and it was returning input because theres a fieldError on myDate: Invalid field value for field myDate. so whats going to happen with this validation stuff, shouldnt validation framework or validate() handle the conversion errors? on conversion failure the property should be set to null if its an Object and 0 for primitive? Jason Carreira wrote: Do you have the DefaultWorkflowInterceptor applied? If there's an error, it will return INPUT without executing the action... -Original Message- From: Francisco Hernandez [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 1:23 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] validator for the optional int field one thing i noticed (from lates cvs head as of a few minutes from sending this email) is that urls like foo.action?myInt=breakMe (myInt is an int, surprised?) are causing INPUT to be returned, i dont think that was happening before, same thing with Date Long Integer long propertys, Jason Carreira wrote: What's the expression you're applying to the field? I'll see if I can figure out what the issue is... -Original Message- From: Taavi Tiirik [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] validator for the optional int field This is the problem of empty form fields causing type conversion field errors that I fixed last night... Try the latest Excellent. Thanks! Now there is still this null pointer exception that happens if I use validator of type fieldexpression and if the field is left blank i.e. when I call validationtest.action?year= java.lang.NullPointerException at ognl.OgnlOps.doubleValue(OgnlOps.java:97) at ognl.OgnlOps.greater(OgnlOps.java:395) at ognl.ASTGreater.getValueBody(ASTGreater.java:51) at ognl.SimpleNode.getValue(SimpleNode.java:167) at ognl.Ognl.getValue(Ognl.java:335) at ognl.Ognl.getValue(Ognl.java:310) at com.opensymphony.xwork.util.OgnlValueStack.findValue(OgnlValue Stack.java:92) at com.opensymphony.xwork.validator.validators.ValidatorSupport.g etFieldValue(V alidatorSupport.java:90) at com.opensymphony.xwork.validator.validators.FieldExpressionVal idator.validat e(FieldExpressionValidator.java:37) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:69) at com.opensymphony.xwork.validator.ActionValidatorManager.valida te(ActionValid atorManager.java:55) at com.opensymphony.xwork.validator.ValidationInterceptor.before( ValidationInte rceptor.java:36) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:36) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept (AroundInterce ptor.java:37) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.interceptor.TimerInterceptor.intercept( TimerIntercept or.java:62) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA ctionInvocatio n.java:169) at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActio nProxy.java:11 6) at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceA ction(ServletD ispatcher.java:182) at com.opensymphony.webwork.dispatcher.ServletDispatcher.service( ServletDispatc her.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at com.opensymphony.webwork.lifecycle.RequestLifecycleFilter.doFi lter(RequestLi fecycleFilter.java:62) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.SetCharacterEncoding.doFilter(SetCharacterEncoding. java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at cmw.filter.Persistence.doFilter(Persistence.java:70) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at
RE: [OS-webwork] OGNL madness - evaluated tag attributes
I agree, and I think that it should be the ${} syntax. The reason I like the
optional syntax is solely for backwards compatibility.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rickard Öberg
Sent: Sunday, November 23, 2003 11:34 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] OGNL madness - evaluated tag attributes
Jason Carreira wrote:
I really dislike the option of which syntax to use... Lets choose one and
use it...
Definitely agree.
Think about the case where many components/projects using WebWork needs to
be merged into one big app. Oh that won't work because we used optional
method Foo, whereas you used Bar is NOT a good situation.
Said it before, and will say it again:
What makes a framework powerful is not what it allows, but what it does not
allow.
This is one of those cases where this is really important to remember.
/Rickard
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Lost in the woods once again...
maybe this will work:
ww:iterator value=model.numItems status=rowstatus
trww:select label='Item ' + #rowstatus.count
name=model.items.get(#rowstatus.index).id
list=@[EMAIL PROTECTED]() listKey=id listValue=label
headerKey='' headerValue='Select'//tr
/ww:iterator
Peter White wrote:
Unless I missed it, the iterator is only capable of iterating over a
collection vs. being able to iterate between a range of numbers. I
believe a valuable enhancement would be to change the ww:set tag to
extend BodySupport instead of TagSupport so you could do something like
this:
c:forEach begin='0' end='${model.numItems-1}' varStatus='status'
cf:set name=label'c:out value=Item ${status.count}/'/cf:set
cf:set name=name'c:out
value=model.items[${status.index}].id/'/cf:set
trww:select label=#label name=#name
list=@[EMAIL PROTECTED]() listKey=id listValue=label
headerKey='' headerValue='Select'//tr
/c:forEach
This would allow for much more flexible UI's, IMHO. In fact, you'll
notice the cf:set tag in my example - I eventually ended up rewriting
the ww:set tag to extend BodyTagSupport instead of WebWorkTagSupport
and then merged in the necessary code from WebWorkTagSupport after
writing my own doAfterBody(). I'm not sure if modifying
WebWorkTagSupport to extend BodyTagSupport instead of TagSupport would
create any problems (it was 4:30 am and I had to call it a night) but is
there any reason SetTag has to extend WebWorkTagSupport? As a side note,
I'd send you my version of SetTag if it weren't for a minor bug... I've
got my version working the the value in the body but I've got to debug
an issue with being about to use the value attribute, if it exists, or
the body content, if not. I can debug this issue and post my version to
the list after I meet my deadline in the next day or two.
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf
Of *Jason Carreira
*Sent:* Sunday, November 23, 2003 5:30 AM
*To:* [EMAIL PROTECTED]
*Subject:* RE: [OS-webwork] Lost in the woods once again...
You can't embed one JSP tag in the attribute value of another JSP
page...
Take a look at the iterator examples that ship with WebWork to see
how this could be done w/ all WW tags (I don't know JSTL that well)
-Original Message-
*From:* Peter White [mailto:[EMAIL PROTECTED]
*Sent:* Saturday, November 22, 2003 8:17 PM
*To:* [EMAIL PROTECTED]
*Subject:* [OS-webwork] Lost in the woods once again...
I'm trying to convert one of the pages of my old JSP-based
wizard over to webwork and I'm at a loss since it doesn't appear
that the ww:iterator tag supports what I'm trying to do. If
anyone has any ideas, I'd be more than willing to try them out
since nothing I've tried has worked so far. Here's what I'm
trying to do
Wizard page #1 asks how many items I want to chose and stores it
in model.numItems
Wizard page #2 needs to do something along the lines of:
c:forEach begin='0' end='${model.numItems-1}' varStatus='status'
ww:set name=count value='c:out
value=${status.count}/' scope=webwork /
ww:set name=index value='c:out
value=${status.index}/' scope=webwork /
trww:select label=Credit Traunch ${#count}
name=model.creditTraunch[${#index}]
list=@[EMAIL PROTECTED]() listKey=['label']
listValue=['id'] defaultKey=Select defaultValue=//tr
/c:forEach
In this mix of WW JSTL, the JSTL iterator works correctly and
renders the ww:select fields. However, the ww:set tag isn't
taking the value from the JSTL c:out tag. If anyone knows how
to get a JSTL value into WW that would be perfect. As a side
note, I'm using the JSTL request wrapper that was posted to the
list.
Thanks!
Peter
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Lost in the woods once again...
I need to grab something to eat but I'll give that a shot as soon as I get
back.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Francisco Hernandez
Sent: Sunday, November 23, 2003 1:27 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Lost in the woods once again...
maybe this will work:
ww:iterator value=model.numItems status=rowstatus
trww:select label='Item ' + #rowstatus.count
name=model.items.get(#rowstatus.index).id
list=@[EMAIL PROTECTED]() listKey=id listValue=label
headerKey='' headerValue='Select'//tr /ww:iterator
Peter White wrote:
Unless I missed it, the iterator is only capable of
iterating over a
collection vs. being able to iterate between a range of numbers. I
believe a valuable enhancement would be to change the
ww:set tag to
extend BodySupport instead of TagSupport so you could do something
like
this:
c:forEach begin='0' end='${model.numItems-1}' varStatus='status'
cf:set name=label'c:out value=Item
${status.count}/'/cf:set
cf:set name=name'c:out
value=model.items[${status.index}].id/'/cf:set
trww:select label=#label name=#name
list=@[EMAIL PROTECTED]() listKey=id listValue=label
headerKey='' headerValue='Select'//tr /c:forEach
This would allow for much more flexible UI's, IMHO. In fact, you'll
notice the cf:set tag in my example - I eventually ended up
rewriting the ww:set tag to extend BodyTagSupport instead of
WebWorkTagSupport and then merged in the necessary code from
WebWorkTagSupport after writing my own doAfterBody(). I'm
not sure if
modifying WebWorkTagSupport to extend BodyTagSupport instead of
TagSupport would create any problems (it was 4:30 am and I
had to call
it a night) but is there any reason SetTag has to extend
WebWorkTagSupport? As a side note, I'd send you my version
of SetTag
if it weren't for a minor bug... I've got my version
working the the
value in the body but I've got to debug an issue with being
about to
use the value attribute, if it exists, or the body content,
if not. I
can debug this issue and post my version to the list after
I meet my deadline in the next day or two.
--
--
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf
Of *Jason Carreira
*Sent:* Sunday, November 23, 2003 5:30 AM
*To:* [EMAIL PROTECTED]
*Subject:* RE: [OS-webwork] Lost in the woods once again...
You can't embed one JSP tag in the attribute value of
another JSP
page...
Take a look at the iterator examples that ship with
WebWork to see
how this could be done w/ all WW tags (I don't know JSTL that
well)
-Original Message-
*From:* Peter White [mailto:[EMAIL PROTECTED]
*Sent:* Saturday, November 22, 2003 8:17 PM
*To:* [EMAIL PROTECTED]
*Subject:* [OS-webwork] Lost in the woods once again...
I'm trying to convert one of the pages of my old JSP-based
wizard over to webwork and I'm at a loss since it
doesn't appear
that the ww:iterator tag supports what I'm trying to do. If
anyone has any ideas, I'd be more than willing to
try them out
since nothing I've tried has worked so far. Here's what I'm
trying to do.
Wizard page #1 asks how many items I want to chose
and stores it
in model.numItems
Wizard page #2 needs to do something along the lines of:
c:forEach begin='0' end='${model.numItems-1}'
varStatus='status'
ww:set name=count value='c:out
value=${status.count}/' scope=webwork /
ww:set name=index value='c:out
value=${status.index}/' scope=webwork /
trww:select label=Credit Traunch ${#count}
name=model.creditTraunch[${#index}]
list=@[EMAIL PROTECTED]()
listKey=['label']
listValue=['id'] defaultKey=Select
defaultValue=//tr
/c:forEach
In this mix of WW JSTL, the JSTL iterator works
correctly and
renders the ww:select fields. However, the
ww:set tag isn't
taking the value from the JSTL c:out tag. If
anyone knows how
to get a JSTL value into WW that would be perfect. As a side
note, I'm using the JSTL request wrapper that was
posted to the
list.
Thanks!
Peter
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
[OS-webwork] Select field not displaying selected values when functioning as multi-select fields
Title: Select field not displaying selected values when functioning as multi-select fields I have a mix of select fields in my wizard and the regular select fields are displaying their current values correctly but the selected values don't display when using them as multiple select fields. I'm not much of a velocity jockey so I wanted to see if anyone else is or isn't having the same problem before I much with select.vm...
Re: [OS-webwork] OGNL madness - evaluated tag attributes
Drew McAuliffe wrote:
I agree, and I think that it should be the ${} syntax. The reason I like the
optional syntax is solely for backwards compatibility.
I don't see why you are using java if you prefer that way of writing
personally.
Let's compare the alternaitves:
ww:property value=name/
ww:property value=${name}/
Am I wrong in assuming that simple usage of the variables is the most
common thing in the WW EL? Because if it is then implementing a more
verbose syntax for it is counterproductive. The rule of thumb is to make
the most common actions simple and intuitive and there is nothing
intuitive about the ${} syntax.
Anders Hovmöller
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OGNL madness - evaluated tag attributes
boxed wrote:
Drew McAuliffe wrote:
I agree, and I think that it should be the ${} syntax. The reason I
like the
optional syntax is solely for backwards compatibility.
I don't see why you are using java if you prefer that way of writing
personally.
Let's compare the alternaitves:
ww:property value=name/
ww:property value=${name}/
Am I wrong in assuming that simple usage of the variables is the most
common thing in the WW EL? Because if it is then implementing a more
verbose syntax for it is counterproductive. The rule of thumb is to make
the most common actions simple and intuitive and there is nothing
intuitive about the ${} syntax.
Right. In Velocity the other way makes sense because the $ is used in
plain HTML, i.e. comparing:
ww:property value=name/
${name}
--
But when comparing between the alternatives as above, I think it's
better to use the non-$ approach.
/Rickard
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] OGNL madness - evaluated tag attributes
Well, I would be with you on that (as it's more apparent what you're expecting to be
evaluated) but it won't fly for backward compatibility
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 4:25 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes
I agree, and I think that it should be the ${} syntax. The
reason I like the optional syntax is solely for backwards
compatibility.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Rickard Öberg
Sent: Sunday, November 23, 2003 11:34 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] OGNL madness - evaluated tag attributes
Jason Carreira wrote:
I really dislike the option of which syntax to use... Lets
choose one
and
use it...
Definitely agree.
Think about the case where many components/projects using
WebWork needs to be merged into one big app. Oh that won't
work because we used optional method Foo, whereas you used
Bar is NOT a good situation.
Said it before, and will say it again:
What makes a framework powerful is not what it allows, but
what it does not allow.
This is one of those cases where this is really important to remember.
/Rickard
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] OGNL madness - evaluated tag attributes
OK -- let's just end this discussion. It's not going to change for the
2.0 release :P
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jason Carreira
Sent: Sunday, November 23, 2003 2:31 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes
Well, I would be with you on that (as it's more apparent what you're
expecting to be evaluated) but it won't fly for backward compatibility
-Original Message-
From: Drew McAuliffe [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 23, 2003 4:25 PM
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes
I agree, and I think that it should be the ${} syntax. The
reason I like the optional syntax is solely for backwards
compatibility.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Rickard Öberg
Sent: Sunday, November 23, 2003 11:34 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] OGNL madness - evaluated tag attributes
Jason Carreira wrote:
I really dislike the option of which syntax to use... Lets
choose one
and
use it...
Definitely agree.
Think about the case where many components/projects using
WebWork needs to be merged into one big app. Oh that won't
work because we used optional method Foo, whereas you used
Bar is NOT a good situation.
Said it before, and will say it again:
What makes a framework powerful is not what it allows, but
what it does not allow.
This is one of those cases where this is really important to remember.
/Rickard
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Spring WW2 -- Status Update
Thanks Matthew. I've created an issue for the missing ServletContextAware and attached the source to the issue - http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-132 I've also added a ResolverSetupServletContextListener that does the job of setting the ServletContext on those resolvers that are ServletContextAware. Cameron and I were discussing how we should initialise the resolvers last week on the list, and well, we were hoping for input from others on the list on the best way of doing this... As Cameron pointed out using ServletContextListeners could potentially get messy if you have a lot of different Resolvers declared with slightly different config needs. However, for most usage cases I think a ServletContextListener will suffice. Cheers, Ross Matthew E. Porter wrote: First, thanks to Ross and the Atlassian guys for their work on integrating Spring into WebWork. A number of people, myself included, have been wanting this for a few months. They took the initiative and time to implement this. However, the code in Jira is incomplete at this time. The external reference code has been integrated into XWork's head. As previously noted, the sample Spring resolver is missing a ServletContextAware class. This is trivial to recreate as it is a single interface, but nothing is currently setting the ServletContext on the class implementing the interface. Or am I just missing something? Does anyone have any update on this? Cheers, matthew --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] OGNL madness - evaluated tag attributes
What about
ww:property value=firstHalf${secondHalf}/
? The advantage of the velocity-style escaped syntax is that it allows for
more flexibility, so that the whole thing doesn't have to get evaluated.
Also, what about tags where what could be displayed might be evaluated in
some cases, but might not in others? How can you build that logic into the
framework so it knows whether to be evaluated or not? I think the question
is not whether we should always evaluate or not, because that question has
been answered already by use of the triple-quoting; it has been decided
that it is more flexible to allow for values to be passed into tag
attributes that _can_ be evaluated against the stack but don't always have
to be. I agree with that approach. The question I'm raising is regarding the
way the syntax of those values is structured. I just don't like the
triple-quote approach.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of boxed
Sent: Sunday, November 23, 2003 2:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] OGNL madness - evaluated tag attributes
Drew McAuliffe wrote:
I agree, and I think that it should be the ${} syntax. The reason I
like the optional syntax is solely for backwards compatibility.
I don't see why you are using java if you prefer that way of writing
personally.
Let's compare the alternaitves:
ww:property value=name/
ww:property value=${name}/
Am I wrong in assuming that simple usage of the variables is the most common
thing in the WW EL? Because if it is then implementing a more verbose syntax
for it is counterproductive. The rule of thumb is to make the most common
actions simple and intuitive and there is nothing intuitive about the ${}
syntax.
Anders Hovmöller
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] textareatag throwing exceptions
im baffled, textarea tag is throwing exceptions yet with the exact same
attributes using the textfield tag that works just fine
this doesnt work:
ww:textarea label=getText('user.aboutMe.label')
name='user.aboutMe' value=user.aboutMe /
this does:
ww:textfield label=getText('user.aboutMe.label')
name='user.aboutMe' value=user.aboutMe /
using latest cvs build
javax.servlet.ServletException: Fatal exception caught in
com.opensymphony.webwork.views.jsp.ui.TextareaTag tag class, doEndTag
at com.evermind.server.http.EvermindPageContext.handlePageException(.:587)
at
__jspPage2_WEB_INF_views_user_userEditForm_jsp._jspService(__jspPage2_WEB_INF_views_user_userEditForm_jsp.java:172)
at com.orionserver.http.OrionHttpJspPage.service(.:70)
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] textareatag throwing exceptions
Root cause is;
javax.servlet.jsp.JspException: Fatal exception caught in
com.opensymphony.webwork.views.jsp.ui.TextareaTag tag class, doEndTag
at
com.opensymphony.webwork.views.jsp.ui.AbstractUITag.doEndTag(AbstractUITag.java:121)
Francisco Hernandez wrote:
im baffled, textarea tag is throwing exceptions yet with the exact same
attributes using the textfield tag that works just fine
this doesnt work:
ww:textarea label=getText('user.aboutMe.label')
name='user.aboutMe' value=user.aboutMe /
this does:
ww:textfield label=getText('user.aboutMe.label')
name='user.aboutMe' value=user.aboutMe /
using latest cvs build
javax.servlet.ServletException: Fatal exception caught in
com.opensymphony.webwork.views.jsp.ui.TextareaTag tag class, doEndTag
at
com.evermind.server.http.EvermindPageContext.handlePageException(.:587)
at
__jspPage2_WEB_INF_views_user_userEditForm_jsp._jspService(__jspPage2_WEB_INF_views_user_userEditForm_jsp.java:172)
at com.orionserver.http.OrionHttpJspPage.service(.:70)
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
