You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by st...@gmail.com on 2008/02/14 21:32:40 UTC
Dynamic Results
Anyone realize why this is not working? I have get/set methods in my
ChartAction, but the getters are not fetching the values for the Result.
<action name="chart" class="actions.ChartAction">
<result type="chart">
<param name="height">${height}</param>
<param name="width">${width}</param>
</result>
</action>
--
Scott
stanlick@gmail.com
[OT] Re: Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> Have you ever been asked to write children's books? :-)
Yes, and illustrate.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by st...@gmail.com.
D --
Have you ever been asked to write children's books? :-)
S
On Thu, Feb 14, 2008 at 4:33 PM, Dave Newton <ne...@yahoo.com> wrote:
> --- stanlick@gmail.com wrote:
> > I understand the quirky plug-in, but that does not explain
> > why OGNL is looking for a setHeight(String) on ChartResult!
>
> Because parameters can be for the result (for example, FreeMarkerResult's
> "contentType" parameter).
>
> > I am puzzled at why S2 is not executing getHeight() on my
> > ChartAction and substituting the height and weight into
> > these params.
>
> I already told you; the JFreeChart result class doesn't parse parameters.
> Evaluating parameters isn't a "it just happens" thing, it's dependent on
> how
> the result is coded.
>
> If you look at the code for StrutsResultSupport you'll see that there's a
> method called conditionalParse() that handles that. The JFreeChart result
> does not extend StrutsResultSupport; it is simply an implementation of
> Result, and therefore does not evaluate expressions contained in its
> parameters.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: Dynamic Results
Posted by st...@gmail.com.
>While in "real life" you actually *do* catch more flies with vinegar than
>honey, it's suggested that when dealing with actual people you follow the
>*spirit* of maxims such as this, necessitating the need to occasionally
i>gnore any underlying untruths. Your current tactic is sub-optimal.
What... did you write the plug-in? :)
P.S. Duly noted chief
On Fri, Feb 15, 2008 at 10:39 AM, Dave Newton <ne...@yahoo.com> wrote:
> --- stanlick@gmail.com wrote:
> > I think if dynamic parameters are supported in the mappings,
> > they should be supported whether the sample of documentation
> > utilizes them or not.
>
> It isn't the "mappings" that support dynamic parameters. It's the result
> implementations.
>
> What you are trying to say is that you would wish that all bundled result
> types parse their parameters. I don't think anybody would disagree with
> that.
>
> > Do you agree that bundled plug-ins should pass a
> > baseline compatibility test?
>
> I'm not sure what that means.
>
> > I decompiled the ChartResult just now and it needs serious work.
>
> You know the source is available, right?
>
> > I agree it allows Struts2 to work with JFreeChart in a couple
> > minutes (which seems to correlate with the time spent writing
> > the plug-in)
>
> ...
>
> While in "real life" you actually *do* catch more flies with vinegar than
> honey, it's suggested that when dealing with actual people you follow the
> *spirit* of maxims such as this, necessitating the need to occasionally
> ignore any underlying untruths. Your current tactic is sub-optimal.
>
> Make a patch. File a JIRA. Update the documentation. I already did the
> legwork for you in identifying which plugins may need to be changed,
> making
> filing the JIRA that much easier and tracking down the Wiki pages that
> need
> to be updated fairly trivial.
>
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: [struts] Dynamic Results
Posted by Dale Newfield <Da...@Newfield.org>.
Dale Newfield wrote:
> It sounds like a reasonable set of patches could be made to xwork
> instead. If parse were made a result attribute (rather than a
> parameter), then the framework could be modified to conditionally do the
> parsing before setting values on the result (rather than the result
> itself doing that evaluation).
I could see that this might also require a "targetClass" (or some other
name) attribute on the parameter tag in order to be able to instruct the
evaluation to target something other than String.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Dynamic Results
Posted by st...@gmail.com.
I like this idea *more*! I'll write the JIRA on this plug-in and include a
suitable fix for the glaring oversights.
On Fri, Feb 15, 2008 at 10:30 AM, Dale Newfield <Da...@newfield.org> wrote:
> stanlick@gmail.com wrote:
> > I think if dynamic parameters are supported in the mappings, they should
> be
> > supported whether the sample of documentation utilizes them or not. Do
> you
> > agree that bundled plug-ins should pass a baseline compatibility test?
>
> It sounds like a reasonable set of patches could be made to xwork
> instead. If parse were made a result attribute (rather than a
> parameter), then the framework could be modified to conditionally do the
> parsing before setting values on the result (rather than the result
> itself doing that evaluation).
>
> Of course, the broader goals of the project seem to be to get away from
> struts.xml configuration in favor of convention, so changes to it may
> not be well received...
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: [struts] Dynamic Results
Posted by Dale Newfield <Da...@Newfield.org>.
stanlick@gmail.com wrote:
> I think if dynamic parameters are supported in the mappings, they should be
> supported whether the sample of documentation utilizes them or not. Do you
> agree that bundled plug-ins should pass a baseline compatibility test?
It sounds like a reasonable set of patches could be made to xwork
instead. If parse were made a result attribute (rather than a
parameter), then the framework could be modified to conditionally do the
parsing before setting values on the result (rather than the result
itself doing that evaluation).
Of course, the broader goals of the project seem to be to get away from
struts.xml configuration in favor of convention, so changes to it may
not be well received...
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> I think if dynamic parameters are supported in the mappings,
> they should be supported whether the sample of documentation
> utilizes them or not.
It isn't the "mappings" that support dynamic parameters. It's the result
implementations.
What you are trying to say is that you would wish that all bundled result
types parse their parameters. I don't think anybody would disagree with that.
> Do you agree that bundled plug-ins should pass a
> baseline compatibility test?
I'm not sure what that means.
> I decompiled the ChartResult just now and it needs serious work.
You know the source is available, right?
> I agree it allows Struts2 to work with JFreeChart in a couple
> minutes (which seems to correlate with the time spent writing
> the plug-in)
...
While in "real life" you actually *do* catch more flies with vinegar than
honey, it's suggested that when dealing with actual people you follow the
*spirit* of maxims such as this, necessitating the need to occasionally
ignore any underlying untruths. Your current tactic is sub-optimal.
Make a patch. File a JIRA. Update the documentation. I already did the
legwork for you in identifying which plugins may need to be changed, making
filing the JIRA that much easier and tracking down the Wiki pages that need
to be updated fairly trivial.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by st...@gmail.com.
I think if dynamic parameters are supported in the mappings, they should be
supported whether the sample of documentation utilizes them or not. Do you
agree that bundled plug-ins should pass a baseline compatibility test? You
can respond without consideration of volunteering your own time! I
decompiled the ChartResult just now and it needs serious work. I agree it
allows Struts2 to work with JFreeChart in a couple minutes (which seems to
correlate with the time spent writing the plug-in) however, when compared to
this <http://code.google.com/apis/chart/>, the plug-in is weak!
On Fri, Feb 15, 2008 at 9:36 AM, Dave Newton <ne...@yahoo.com> wrote:
> --- stanlick@gmail.com wrote:
> > I would propose that plug-ins shipped with the core work according to
> the
> > documentation<
> http://struts.apache.org/2.x/docs/result-configuration.html>.
> > [...]
> > I am willing to help if necessary and eligible.
>
> File a JIRA and include a patch.
>
> For completeness, the link you provided doesn't discuss setting dynamic
> parameters on a result. If anything,
> http://struts.apache.org/2.x/docs/result-configuration.html approaches the
> subject but still doesn't discuss it.
>
> The docs for the bundled plugins never give an example of OGNL param
> expressions, although many have a "parse" parameter (dispatcher,
> freemarker,
> httpheader, redirect, velocity, xslt, and jasper all do; chain,
> actionRedirect, stream, plaintext do not or don't have it documented)
> whose
> docs say it controls the parsing of OGNL strings in parameters.
>
> Of the remaining bundled plugins, only the "chart" (I think) is relevant,
> and
> it also does not mention a "parse" param.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> I would propose that plug-ins shipped with the core work according to the
> documentation<http://struts.apache.org/2.x/docs/result-configuration.html>.
> [...]
> I am willing to help if necessary and eligible.
File a JIRA and include a patch.
For completeness, the link you provided doesn't discuss setting dynamic
parameters on a result. If anything,
http://struts.apache.org/2.x/docs/result-configuration.html approaches the
subject but still doesn't discuss it.
The docs for the bundled plugins never give an example of OGNL param
expressions, although many have a "parse" parameter (dispatcher, freemarker,
httpheader, redirect, velocity, xslt, and jasper all do; chain,
actionRedirect, stream, plaintext do not or don't have it documented) whose
docs say it controls the parsing of OGNL strings in parameters.
Of the remaining bundled plugins, only the "chart" (I think) is relevant, and
it also does not mention a "parse" param.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by st...@gmail.com.
Thanks Dave --
You really are good at exploring the idiosyncratic realms! Since one should
not have to crawl around in the bowels of a framework to discover why
straightforward coding does not, I would propose that plug-ins shipped with
the core work according to the
documentation<http://struts.apache.org/2.x/docs/result-configuration.html>.
Otherwise, we will end up with a list of exceptions a mile long and likely
lose out to another framework. Is there a compatibility test that shipped
plug-ins must pass? When code that seemingly should work doesn't,
developers tend to shy away. If we know that a plug-in does not play nicely
with user configurations where a sister plug-in does; we should fix it. If
this means changing it to extend StrutsResultSupport like the well-behaved
plug-ins do, then alright. I realize this is a volunteer business and if a
technician has enough time to make suggestions, they should also be prepared
to roll up their sleeves! I am willing to help if necessary and eligible.
Scott
On Thu, Feb 14, 2008 at 8:19 PM, Dave Newton <ne...@yahoo.com> wrote:
> --- stanlick@gmail.com wrote:
> > It seems very odd that OGNL tried issuing chart.setHeight("${height}")
>
> Why? It has a java.lang.String parameter; it's matching method signatures.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> It seems very odd that OGNL tried issuing chart.setHeight("${height}")
Why? It has a java.lang.String parameter; it's matching method signatures.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by st...@gmail.com.
<action name="chart" class="actions.ChartAction">
<result type="chart">
<param name="height">${height}</param>
<param name="width">${width}</param>
</result>
</action>
I double checked my configuration and I have
itJustHappens="true" :)
It seems very odd that OGNL tried issuing chart.setHeight("${height}")
Caused by: java.lang.NoSuchMethodException: setHeight(java.lang.String)
2008-02-14 17:44:53,229Caught OgnlException while setting property 'height'
on type 'org.apache.struts2.dispatcher.ChartResult'.
Re: [struts] Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> The ChartAction extends ActionSupport. Wouldn't the
> action-mapping-OGNL-parsing be looking for height/width getters on the
> ChartAction?
I think we're all talking past each other here.
It's the responsibility of the *result* to parse OGNL in its parameters: the
JFreeChart result doesn't do that.
If you look at the source of the JFreeChart result and compare it to
something like the servlet redirect result you'll notice that JFreeChart just
implements Result, whereas the the servlet result result extends
StrutsResultSupport.
It's StrutsResultSupport that does the evaluation of parameters.
Dave
> On Thu, Feb 14, 2008 at 4:39 PM, Dale Newfield <Da...@newfield.org> wrote:
> > stanlick@gmail.com wrote:
> > > I am puzzled at why S2 is not executing getHeight() on my ChartAction
> > > and substituting the height and weight into these params.
> >
> > This is done by StrutsResultSupport. I would guess that whatever class
> > is implementing your chart result does not extend/leverage that
> > capability.
> >
>
http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/dispatcher/StrutsResultSupport.html
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] Dynamic Results
Posted by st...@gmail.com.
Hey Dale --
The ChartAction extends ActionSupport. Wouldn't the
action-mapping-OGNL-parsing be looking for height/width getters on the
ChartAction?
Scott
On Thu, Feb 14, 2008 at 4:39 PM, Dale Newfield <Da...@newfield.org> wrote:
> stanlick@gmail.com wrote:
> > I am puzzled at why S2 is not executing getHeight() on my ChartAction
> > and substituting the height and weight into these params.
>
> This is done by StrutsResultSupport. I would guess that whatever class
> is implementing your chart result does not extend/leverage that
> capability.
>
>
> http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/dispatcher/StrutsResultSupport.html
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: [struts] Dynamic Results
Posted by Dale Newfield <Da...@Newfield.org>.
stanlick@gmail.com wrote:
> I am puzzled at why S2 is not executing getHeight() on my ChartAction
> and substituting the height and weight into these params.
This is done by StrutsResultSupport. I would guess that whatever class
is implementing your chart result does not extend/leverage that capability.
http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/dispatcher/StrutsResultSupport.html
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by Ian Roughley <ia...@fdar.com>.
My mistake, I was thinking of a similar problem where I needed to pass a
static param to the next action being invoked. In this case, the
parameter had to be declared in the result stanza, but was not intended
for the result type. We also didn't want it to be noise on the action.
In this case there was no clear context.
/Ian
--
Ian Roughley
>From Down & Around, Inc.
Consulting * Training / Mentoring * Agile Process * Open Source
web: http://www.fdar.com - email: ian@fdar.com
stanlick@gmail.com wrote:
> Actually when OGNL fails to locate a setXXX(String) on the result when
> encountering result parm"${width} " it fails with
>
> 2008-02-15 09:17:25,991ERROR [http-8080-2] (
> DefaultActionInvocation.java:createResult:198) - There was an exception
> while instantiating the result of type
> org.apache.struts2.dispatcher.ChartResult
> 2008-02-15 09:17:26,241Caught OgnlException while setting property 'height'
> on type 'org.apache.struts2.dispatcher.ChartResult'. - Class:
> ognl.OgnlRuntime
>
> and the action setter is never invoked. What would the value of recovery by
> setting a result parameter on the action be? As far as differentiating
> between parameters in the config file goes, why wouldn't the lexical context
> of the parameter determine the intended application of the value?
>
>
>
>
>
> On Fri, Feb 15, 2008 at 9:00 AM, Ian Roughley <ia...@fdar.com> wrote:
>
>
>> I think you'll find this happens will all the result types and not just
>> the chart result. If you have additional info in the result config as
>> parameters, it will try to set is on the result type, fail with an
>> exception, and then set it correctly on the action.
>>
>> As to a resolution... as both result types and action can take
>> parameters from the config, what is the best way to differentiate them
>> without making the config more complicated?
>>
>> /Ian
>>
>> --
>> Ian Roughley
>> From Down & Around, Inc.
>> Consulting * Training / Mentoring * Agile Process * Open Source
>> web: http://www.fdar.com - email: ian@fdar.com
>>
>>
>>
>> stanlick@gmail.com wrote:
>>
>>> I understand the quirky plug-in, but that does not explain why OGNL is
>>> looking for a setHeight(String) on ChartResult! If I hardcode ints into
>>> these two parms, life is good. I am puzzled at why S2 is not executing
>>> getHeight() on my ChartAction and substituting the height and weight
>>>
>> into
>>
>>> these params.
>>>
>>> Can you look at this
>>> <http://struts.apache.org/2.x/docs/result-configuration.html>and tell me
>>>
>> how
>>
>>> the two differ?
>>>
>>> Peace,
>>> Scott
>>>
>>> On Thu, Feb 14, 2008 at 3:35 PM, Dave Newton <ne...@yahoo.com>
>>>
>> wrote:
>>
>>>
>>>> --- stanlick@gmail.com wrote:
>>>>
>>>>
>>>>> Anyone realize why this is not working? I have get/set methods in my
>>>>> ChartAction, but the getters are not fetching the values for the
>>>>>
>> Result.
>>
>>>>> <action name="chart" class="actions.ChartAction">
>>>>> <result type="chart">
>>>>> <param name="height">${height}</param>
>>>>> <param name="width">${width}</param>
>>>>> </result>
>>>>> </action>
>>>>>
>>>>>
>>>> Probably because the "chart" result doesn't parse its parameters.
>>>>
>>>> Dave
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
>
Re: Dynamic Results
Posted by st...@gmail.com.
Actually when OGNL fails to locate a setXXX(String) on the result when
encountering result parm"${width} " it fails with
2008-02-15 09:17:25,991ERROR [http-8080-2] (
DefaultActionInvocation.java:createResult:198) - There was an exception
while instantiating the result of type
org.apache.struts2.dispatcher.ChartResult
2008-02-15 09:17:26,241Caught OgnlException while setting property 'height'
on type 'org.apache.struts2.dispatcher.ChartResult'. - Class:
ognl.OgnlRuntime
and the action setter is never invoked. What would the value of recovery by
setting a result parameter on the action be? As far as differentiating
between parameters in the config file goes, why wouldn't the lexical context
of the parameter determine the intended application of the value?
On Fri, Feb 15, 2008 at 9:00 AM, Ian Roughley <ia...@fdar.com> wrote:
> I think you'll find this happens will all the result types and not just
> the chart result. If you have additional info in the result config as
> parameters, it will try to set is on the result type, fail with an
> exception, and then set it correctly on the action.
>
> As to a resolution... as both result types and action can take
> parameters from the config, what is the best way to differentiate them
> without making the config more complicated?
>
> /Ian
>
> --
> Ian Roughley
> From Down & Around, Inc.
> Consulting * Training / Mentoring * Agile Process * Open Source
> web: http://www.fdar.com - email: ian@fdar.com
>
>
>
> stanlick@gmail.com wrote:
> > I understand the quirky plug-in, but that does not explain why OGNL is
> > looking for a setHeight(String) on ChartResult! If I hardcode ints into
> > these two parms, life is good. I am puzzled at why S2 is not executing
> > getHeight() on my ChartAction and substituting the height and weight
> into
> > these params.
> >
> > Can you look at this
> > <http://struts.apache.org/2.x/docs/result-configuration.html>and tell me
> how
> > the two differ?
> >
> > Peace,
> > Scott
> >
> > On Thu, Feb 14, 2008 at 3:35 PM, Dave Newton <ne...@yahoo.com>
> wrote:
> >
> >
> >> --- stanlick@gmail.com wrote:
> >>
> >>> Anyone realize why this is not working? I have get/set methods in my
> >>> ChartAction, but the getters are not fetching the values for the
> Result.
> >>>
> >>> <action name="chart" class="actions.ChartAction">
> >>> <result type="chart">
> >>> <param name="height">${height}</param>
> >>> <param name="width">${width}</param>
> >>> </result>
> >>> </action>
> >>>
> >> Probably because the "chart" result doesn't parse its parameters.
> >>
> >> Dave
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >>
> >
> >
> >
>
--
Scott
stanlick@gmail.com
Re: Dynamic Results
Posted by Ian Roughley <ia...@fdar.com>.
I think you'll find this happens will all the result types and not just
the chart result. If you have additional info in the result config as
parameters, it will try to set is on the result type, fail with an
exception, and then set it correctly on the action.
As to a resolution... as both result types and action can take
parameters from the config, what is the best way to differentiate them
without making the config more complicated?
/Ian
--
Ian Roughley
>From Down & Around, Inc.
Consulting * Training / Mentoring * Agile Process * Open Source
web: http://www.fdar.com - email: ian@fdar.com
stanlick@gmail.com wrote:
> I understand the quirky plug-in, but that does not explain why OGNL is
> looking for a setHeight(String) on ChartResult! If I hardcode ints into
> these two parms, life is good. I am puzzled at why S2 is not executing
> getHeight() on my ChartAction and substituting the height and weight into
> these params.
>
> Can you look at this
> <http://struts.apache.org/2.x/docs/result-configuration.html>and tell me how
> the two differ?
>
> Peace,
> Scott
>
> On Thu, Feb 14, 2008 at 3:35 PM, Dave Newton <ne...@yahoo.com> wrote:
>
>
>> --- stanlick@gmail.com wrote:
>>
>>> Anyone realize why this is not working? I have get/set methods in my
>>> ChartAction, but the getters are not fetching the values for the Result.
>>>
>>> <action name="chart" class="actions.ChartAction">
>>> <result type="chart">
>>> <param name="height">${height}</param>
>>> <param name="width">${width}</param>
>>> </result>
>>> </action>
>>>
>> Probably because the "chart" result doesn't parse its parameters.
>>
>> Dave
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
>
Re: Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> I understand the quirky plug-in, but that does not explain
> why OGNL is looking for a setHeight(String) on ChartResult!
Because parameters can be for the result (for example, FreeMarkerResult's
"contentType" parameter).
> I am puzzled at why S2 is not executing getHeight() on my
> ChartAction and substituting the height and weight into
> these params.
I already told you; the JFreeChart result class doesn't parse parameters.
Evaluating parameters isn't a "it just happens" thing, it's dependent on how
the result is coded.
If you look at the code for StrutsResultSupport you'll see that there's a
method called conditionalParse() that handles that. The JFreeChart result
does not extend StrutsResultSupport; it is simply an implementation of
Result, and therefore does not evaluate expressions contained in its
parameters.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Dynamic Results
Posted by st...@gmail.com.
I understand the quirky plug-in, but that does not explain why OGNL is
looking for a setHeight(String) on ChartResult! If I hardcode ints into
these two parms, life is good. I am puzzled at why S2 is not executing
getHeight() on my ChartAction and substituting the height and weight into
these params.
Can you look at this
<http://struts.apache.org/2.x/docs/result-configuration.html>and tell me how
the two differ?
Peace,
Scott
On Thu, Feb 14, 2008 at 3:35 PM, Dave Newton <ne...@yahoo.com> wrote:
> --- stanlick@gmail.com wrote:
> > Anyone realize why this is not working? I have get/set methods in my
> > ChartAction, but the getters are not fetching the values for the Result.
> >
> > <action name="chart" class="actions.ChartAction">
> > <result type="chart">
> > <param name="height">${height}</param>
> > <param name="width">${width}</param>
> > </result>
> > </action>
>
> Probably because the "chart" result doesn't parse its parameters.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Scott
stanlick@gmail.com
Re: Dynamic Results
Posted by Dave Newton <ne...@yahoo.com>.
--- stanlick@gmail.com wrote:
> Anyone realize why this is not working? I have get/set methods in my
> ChartAction, but the getters are not fetching the values for the Result.
>
> <action name="chart" class="actions.ChartAction">
> <result type="chart">
> <param name="height">${height}</param>
> <param name="width">${width}</param>
> </result>
> </action>
Probably because the "chart" result doesn't parse its parameters.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org