Hello all,
I have a question regarding bean:message
I have a page where I need to display a message with some
Dynamc parameters, and I would be able to 'internationalize' the whole
message
For example, let's say that my message is
Error.comparequantity={0} must be {1} than {2}
I would like to use the tag in my page like this
<bean:message key="error.comparequantity"
arg0="prompt.minQuantity"
arg1="less"
arg2="prompt.maxQuantity"/>');
However, it looks like args0 & args2 are not retrieved from my
ApplicationREsources.properties file
Any idea on how to achieve that?
Thanx in advance and regars
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Dealing with many forms
Posted by Janek Ziniewicz <ja...@gmail.com>.
Hi, I am writing my first Struts application, and have some problems with
it.
Some part of my app, gets data from database, fills appropriate form,
displays it and, if user changed the form, writes data back to database.
Another functionality is: get whole webpage (including form)from database,
fill it with data and if user changes it, write changed data back to
database. It was done with Jsp and JavaScript. Writing ActionForm for each
form would be senseless because part of functionality of the app is that
any user can submit new forms.
And now the problem: Some devices do not deal with JavaScript well (some
palmtops, cellphones etc). And my app must run properly on them. So, is
there any way to do the task above without JavaScript?
--
Pozdrawiam, Janek Ziniewicz
gg:902858
irc.freenode.net: #gore, #dub
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Joe Germuska wrote:
> I'm not sure I think that would be nice ;-) Seems kind of risky, in
> that it adds a lot of indeterminacy. That's the main reason why lots of
> us are down on request chaining too.
Just talking about the chain pattern generically... think about trying
to implement a recursive problem with a chain implementation... by
definition you'd want to do the equivalent of restarting the chain, right?
Now, if you want to make the argument that resursive algorithms are
somewhat risky, I would tend to agree :) Has never stopped me from
using one when appropriate though.
> That's a gut reaction, but without more demand for it and more
> consideration of possible side effects, it's not something I'd be likely
> to implement for fun on a Saturday afternoon or anything...
And certainly I have in no way thought this through completely. Plus,
I'll repeat my refrain once more: I'm not up to speek on chain and 1.3's
usage of it in particular at this point. I may in a few days come to
the conclusion that it's a horrible idea myself :)
> Joe
>
> BTW, we are probably creeping into struts-dev turf on this thread here...
Well, I'll tell you what... when I feel like I'm up to speed and know
what I'm talking about (whether I actually do or not!), if I still think
my first thought was right, I'll raise the idea on the dev list (commons
dev I'd think is more appropriate). Like I said, a few days from now I
may be completely off the idea :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:23 PM -0400 5/20/05, Frank W. Zammetti wrote:
>>It's interesting to have some more complex use cases to test the
>>chain model against...
>
>Absolutely. One thing that would be nice, and maybe it already is
>and I just don't know enough yet, is to be able to essentially
>restart the chain at any given point. That of course introduces the
>possibility of endless loops, but it makes it so that I could just
>do like restartChain() instead of forwarding back through tbe whole
>RP cycle.
I'm not sure I think that would be nice ;-) Seems kind of risky, in
that it adds a lot of indeterminacy. That's the main reason why lots
of us are down on request chaining too.
That's a gut reaction, but without more demand for it and more
consideration of possible side effects, it's not something I'd be
likely to implement for fun on a Saturday afternoon or anything...
Joe
BTW, we are probably creeping into struts-dev turf on this thread here...
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Joe Germuska wrote:
> Well, the difference between extending PopulateForm and putting a
> command after it which re-populates in the case of a SOAP request is
> small; the only caveat being that in the add-a-command-after model you
> must do it after or the existing PopulateForm action would clobber your
> efforts -- subclassing eliminates any questions about the ordering of
> events.
Yeah, I see your point. I'm coming at it from a purely gut instinct
perspective... when I stop and think about it, I agree, the different is
fairly small.
> How does the strutsws kit respond to form validation failures? Is the
> "input" path overwritten when you clone the ActionMapping? You could
> keep doing that, or you could use the same model described for the
> forward, that is indicate the failed-validation-path in a property set
> in the ActionMapping.
That's exactly how. Just like there is a default response template,
there is a default error template, or you can define your own in
webservices-config.xml to do something more. The input is overridden
with whichever one applies.
> I don't know nothing about properness ;-)
>
> It's interesting to have some more complex use cases to test the chain
> model against...
Absolutely. One thing that would be nice, and maybe it already is and I
just don't know enough yet, is to be able to essentially restart the
chain at any given point. That of course introduces the possibility of
endless loops, but it makes it so that I could just do like
restartChain() instead of forwarding back through tbe whole RP cycle.
Well, as I've said all along, I need to get up to speed on chain and
1.3's use of it before I can do more than stick my foot in my mouth here
:)
I have to get beta2 of AjaxTags out the door first, and I also want to
get my file manager app put up on Sruts Apps. After that I'll circle
back around and really get in to StrutsWS on 1.3, unless Marco beats me
to the punch of course! :)
> Joe
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow / complex app
Posted by Craig McClanahan <cr...@gmail.com>.
On 5/23/05, Joe Germuska <Jo...@germuska.com> wrote:
> Marco wrote:
> >Does Shale use chain? Could you integrate chain in Shale?
>
> Shale does use chain, but to be honest, I don't know much more about
> it than that.
>
Shale uses Commons Chain to configure it's application level
processing (i.e. the stuff that is performed in its "front controller"
filter). Shale does not use Commons Chain for any detailed
per-request processing (although you can easily do so for your own
application's purposes, by having your action handler (the code that
processes a submit button event, sorta like an Action.execute() method
in Struts 1.x) look up an appropriate Chain, set up an appropriate
Context, and then fire off the chain.
For conversation management, Shale also includes Dialog -- a very
simple implementation of the same idea that Spring WebFlow fleshes out
in all its sophisticated glory. This is quite useful for managing
state across a multiple-request dialog with the user. This doesn't
use Commons Chain, because it supports transitions to one of several
next states, based on logical outcomes -- and the sequential flow
nature that Commons Chain provides does not really match that model.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow /again
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:23 AM +0100 5/25/05, Marco Mistroni wrote:
>Hello Joe & all,
> I have one question regarding the chain..
>Am I correct to assume that The SelectInput command that comes after
>ValidateActionForm in chain-config.xml should be called in case
>validation fails?
>How does that happen? Javadoc says that
>/**
> * <p>Validate the properties of the form bean for this request. If
>there are
> * any validation errors, execute the child commands in our chain;
>otherwise,
> * proceed normally.</p>
> *
> * @version $Rev: 153658 $ $Date: 2005-02-13 14:26:03 -0500 (Sun, 13 Feb
>2005) $
> */
I think that JavaDoc is misleading. I had wanted to do some
rearrangement to the chain around this issue, but have not yet. (To
be honest, I'm not really sure what "child commands in our chain"
means!)
Here's how it works now: in the process action chain, the
ValidateActionForm command does the validation and sets a flag in the
context. Then, each subsequent command in the chain inspects the
value of this and controls its behavior accordingly.
This is kind of clumsy, and entangles the commands too much. It
would be better to "abort" the chain when the form is invalid, at
least as soon as possible. The problem is that commons-chain 1.0
treats a "true" return from a lookup chain as a signal to end ALL
chain processing, not just that chain which was looked up. This has
been addressed with a configurable property on LookupCommand in an as
yet unreleased version of commons-chain. With that, one can "abort"
a sub-chain without interrupting the processing of the source chain.
There's still the awkward bit of having SelectInput separate from
ValidateActionForm -- you have at least one class which needs to be
invoked paying attention to this value in the context. I've thought
of a few possible chain design approaches, like a branching command
or a conditional lookup command, but none have felt so compelling
that I wanted to push them in yet.
>but as far as I could see, SelectInput is just another command that
>comes after ValidateActionForm... and, one thing that make me more
>confused, is that if ValidateActionForm fails, it should return true, so
>the next command (which is SelectInput) shouldn't get executed.......
That's not true -- as noted above, in commons-chain 1.0, no command
in a chain may ever return true without cancelling all chain
processing. I found this counter-intuitive, as it seems do you --
and that's why I added the configuration property to LookupCommand.
I'd suggest checking out the code -- it should be pretty easy to
actually trace through it and get a better handle on what happens in
there.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow /again
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Joe & all,
I have one question regarding the chain..
Am I correct to assume that The SelectInput command that comes after
ValidateActionForm in chain-config.xml should be called in case
validation fails?
How does that happen? Javadoc says that
/**
* <p>Validate the properties of the form bean for this request. If
there are
* any validation errors, execute the child commands in our chain;
otherwise,
* proceed normally.</p>
*
* @version $Rev: 153658 $ $Date: 2005-02-13 14:26:03 -0500 (Sun, 13 Feb
2005) $
*/
but as far as I could see, SelectInput is just another command that
comes after ValidateActionForm... and, one thing that make me more
confused, is that if ValidateActionForm fails, it should return true, so
the next command (which is SelectInput) shouldn't get executed.......
could you clarify me how and when the SelectInput gets called?
Thanx and regards
marco
-----Original Message-----
From: Joe Germuska [mailto:Joe@Germuska.com]
Sent: 23 May 2005 14:10
To: Marco Mistroni; 'Struts Users Mailing List'; 'Frank W. Zammetti'
Subject: RE: sTRUTS 1.3 - chain flow / complex app
Marco wrote:
>Does Shale use chain? Could you integrate chain in Shale?
Shale does use chain, but to be honest, I don't know much more about
it than that.
>I am looking forward to add more complexity for 'testing' the chain..
>If you have anything to suggest me, go ahead :-) ..
Just keep doing what you're doing! More than the complexity, it's
just valuable to have people using it period. I've been developing a
new app on it for a few months now and everything seems to be going
smoothly, but I'm sure I don't use every feature of Struts, so having
more people use it to make any kind of webapp gives us more chances
to flush out any quirks.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow / complex app
Posted by Joe Germuska <Jo...@Germuska.com>.
Marco wrote:
>Does Shale use chain? Could you integrate chain in Shale?
Shale does use chain, but to be honest, I don't know much more about
it than that.
>I am looking forward to add more complexity for 'testing' the chain..
>If you have anything to suggest me, go ahead :-) ..
Just keep doing what you're doing! More than the complexity, it's
just valuable to have people using it period. I've been developing a
new app on it for a few months now and everything seems to be going
smoothly, but I'm sure I don't use every feature of Struts, so having
more people use it to make any kind of webapp gives us more chances
to flush out any quirks.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow / complex app
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello all,
>It's interesting to have some more complex use cases to test the
>chain model against...
I would offer my app as 'guinea pig' for complex cases :-)
Currently it's a small app that manage my own 'expenses' (I have a mysql
as backend and jboss 3.2.5/tomcat 5.5 as app server)to see
What do I spend an where (yeah, I m not that good with money :-)
I am updating my db almost automatically via quartz job, using struts as
user interface for manual insert of expenses and job scheduling..
I m using castor/hibernate as ORM frameworks, and spring & struts
I manage to port it from struts 1.1 to struts 1.3, and I was looking
into strutsws cos I want to have J2ME clients that communicates using
ksoap.
I am looking forward to add more complexity for 'testing' the chain..
If you have anything to suggest me, go ahead :-) ..
Does Shale use chain? Could you integrate chain in Shale?
Regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
>>I'd suggest adding a preprocessing command which recognizes the
>>SOAP header, as Frank described, and instead of forwarding, simply
>>sets a key/value pair in the ActionContext which other commands can
>>interpret. Then later, you could extend the PopulateForm class to
>>look for the flag and to do its population process based on SOAP
>>data instead of request parameters.
>
>Yep, that's what I was talking about in terms of changing things...
>extending classes isn't changing them of course, but it's still not
>the "insert some commands and your done" that I was hoping for. I
>suppose it's not that bad really, I was just hoping for simple
>insertions into the chain config.
Well, the difference between extending PopulateForm and putting a
command after it which re-populates in the case of a SOAP request is
small; the only caveat being that in the add-a-command-after model
you must do it after or the existing PopulateForm action would
clobber your efforts -- subclassing eliminates any questions about
the ordering of events.
How does the strutsws kit respond to form validation failures? Is
the "input" path overwritten when you clone the ActionMapping? You
could keep doing that, or you could use the same model described for
the forward, that is indicate the failed-validation-path in a
property set in the ActionMapping.
>>Typical caveats apply, but I think that would handle it. I'm not
>>totally sure how I feel about a practice of changing the forward
>>config in the process-view chain, but I can't see any other way
>>you'd handle it without having to bind your code a lot more to the
>>specific fact that it might be used in both ways.
>
>Agreed. As it stands now, I'm doing some rather dicey things to
>make it all work, specifically I'm thinking of the cloning of the
>ActionMapping and altering it on-the-fly for exception handling.
>So, what you suggest is better in terms of "proper-ness" at least :)
I don't know nothing about properness ;-)
It's interesting to have some more complex use cases to test the
chain model against...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow / solved
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Frank
Not at all... just give me couple of days to tidy it up
And test also validations samples (which I trust they work since
I haven't altered the way strutsws work..)....
Thanx for your help!
I'll send you 'tidy code' in couple of days.
Regards
marco
-----Original Message-----
From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
Sent: 23 May 2005 23:42
To: Marco Mistroni
Cc: 'Struts Users Mailing List'
Subject: Re: sTRUTS 1.3 - chain flow / solved
Sorry I didn't respond sooner Marco,
Fantastic work! I haven't had a chance to look at what you sent me yet,
but I definitely look forward to doing so. Would you have any objection
to me putting your code out on SF in CVS, maybe as a separate branch?
That way others can benefit from your efforts.
Take care,
Frank
Marco Mistroni wrote:
> Hello,
> Looks like I found a way to make it work! :-)
> I have submitted the code to Frank..surely he'll find way to optimize
> it..
> For now, I had to extend few commands (SelectAction,
ValidateActionForm,
> PopulateActionForm & SelectForward) and I had to rewrite struts
> chain-config.xml to use my own commands...
>
>
> Thanx to all of you who gave me precious hints!
>
> Regards
> Marco
>
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow / solved
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Sorry I didn't respond sooner Marco,
Fantastic work! I haven't had a chance to look at what you sent me yet,
but I definitely look forward to doing so. Would you have any objection
to me putting your code out on SF in CVS, maybe as a separate branch?
That way others can benefit from your efforts.
Take care,
Frank
Marco Mistroni wrote:
> Hello,
> Looks like I found a way to make it work! :-)
> I have submitted the code to Frank..surely he'll find way to optimize
> it..
> For now, I had to extend few commands (SelectAction, ValidateActionForm,
> PopulateActionForm & SelectForward) and I had to rewrite struts
> chain-config.xml to use my own commands...
>
>
> Thanx to all of you who gave me precious hints!
>
> Regards
> Marco
>
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow / solved
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello,
Looks like I found a way to make it work! :-)
I have submitted the code to Frank..surely he'll find way to optimize
it..
For now, I had to extend few commands (SelectAction, ValidateActionForm,
PopulateActionForm & SelectForward) and I had to rewrite struts
chain-config.xml to use my own commands...
Thanx to all of you who gave me precious hints!
Regards
Marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Joe Germuska wrote:
> I do think that it would be much easier in 1.3 than in 1.2 to solve this
> without doing a forward and re-engaging the request processor; I can see
> where the complexity of intervening in arbitrary spots in the request
> process in the "template pattern" approach of the RequestProcessor might
> make the forward a more attractive solution, but that is one of the
> issues solved by composing the request processing logic out of a number
> of small commands.
I started looking a little bit at chain and 1.3 a few minutes ago.
Still not qualified to really comment though :)
The only thing I will say is that I had hoped StrutsWS could be brought
to 1.3 by just inserting some commands in the chain, but it seems like
some other commands might have to be altered. I could be wrong about
that, I have more to learn before I could say with any certainty.
> I'd suggest adding a preprocessing command which recognizes the SOAP
> header, as Frank described, and instead of forwarding, simply sets a
> key/value pair in the ActionContext which other commands can interpret.
> Then later, you could extend the PopulateForm class to look for the flag
> and to do its population process based on SOAP data instead of request
> parameters.
Yep, that's what I was talking about in terms of changing things...
extending classes isn't changing them of course, but it's still not the
"insert some commands and your done" that I was hoping for. I suppose
it's not that bad really, I was just hoping for simple insertions into
the chain config.
> I'm curious, how does strutsws deal with the response? Is it assumed
> that all of these requests are actually only ever serving SOAP clients,
> so that the response is always a SOAP response? Or is the goal to have
> one action function for both simple HTTP requests as well as SOAP
> requests?
It is the later. The idea is that a single Action can transparently be
called as part of a typical webapp, or by a SOAP client. In fact, I use
this in a production app right now in that way... it's a "typical"
webapp, more or less!, but some parts of it are exposed as Web Services
for other systems to call on. Works great!
In it's current form, when the Action completes in the case of a WS
request, the forward returned is discarded and a new one is used. The
forward used can be to the default template (which is a JSP that creates
a SOAP response from an ActionForm) or one you specify in an optional
webservices-config.xml, so you can create a more complex SOAP response
if you need to (the default template has some limitations but generally
works for relatively simple responses).
> If it's the first, then you have nothing else to do; however,
> if you were interested in the second... well, I suppose you could put
> something in after the ExecuteAction stage or at the beginning of the
> process-view chain which consulted the resulting ForwardConfig and, if
> in "SOAP mode", looked up a different ForwardConfig. Now that you can
> put arbitrary properties in a ForwardConfig, you could even configure it
> in-place:
>
> <action path="/SoapOrHttpDoesntMatter"
> type="com.example.ProcessRequestAction"
> name="FormBeanName">
> <forward name="success" path="/NormalResponse.jsp">
> <set-property key="SOAP.path" value="/SOAPResponseTemplate.jsp" />
> </forward>
> </action>
Interesting... there is a good argument to be made for doing that
instead of having the separate webservices-config.xml file... although,
there are some other things you can specify in that config file as well,
so there's a reasonable argument for keeping it separate too (might
clutter up struts-config in a hurry). The current config file is
actually optional in any case, you can simply drop the new RP in and the
plug-in that is required and your Actions can automatically be called by
SOAP clients (ignoring security restrictions and session requirements).
But, rolling it into struts-config is something to think about.
> and then this command early in the process-view chain:
>
> public class AdjustForwardConfigForSoap extends ActionCommandBase {
>
> public boolean execute( ActionContext ctx ) {
>
> if (ctx.containsKey("SOAPModeFlat")) {
> ForwardConfig fc = ctx.getForwardConfig();
> String alternatePath = fc.getProperty("SOAP.path");
> if (alternatePath == null) throw new IllegalStateException();
> ForwardConfig alt = new ForwardConfig();
> alt.setPath(alternatePath);
> ctx.setForwardConfig(alt);
> }
> }
> }
>
> Typical caveats apply, but I think that would handle it. I'm not
> totally sure how I feel about a practice of changing the forward config
> in the process-view chain, but I can't see any other way you'd handle it
> without having to bind your code a lot more to the specific fact that it
> might be used in both ways.
Agreed. As it stands now, I'm doing some rather dicey things to make it
all work, specifically I'm thinking of the cloning of the ActionMapping
and altering it on-the-fly for exception handling. So, what you suggest
is better in terms of "proper-ness" at least :)
> Joe
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
>However, just to level-set as far as the current 1.2.x version goes...
Thanks, Frank. That helps a lot.
I do think that it would be much easier in 1.3 than in 1.2 to solve
this without doing a forward and re-engaging the request processor; I
can see where the complexity of intervening in arbitrary spots in the
request process in the "template pattern" approach of the
RequestProcessor might make the forward a more attractive solution,
but that is one of the issues solved by composing the request
processing logic out of a number of small commands.
I'd suggest adding a preprocessing command which recognizes the SOAP
header, as Frank described, and instead of forwarding, simply sets a
key/value pair in the ActionContext which other commands can
interpret. Then later, you could extend the PopulateForm class to
look for the flag and to do its population process based on SOAP data
instead of request parameters.
I'm curious, how does strutsws deal with the response? Is it assumed
that all of these requests are actually only ever serving SOAP
clients, so that the response is always a SOAP response? Or is the
goal to have one action function for both simple HTTP requests as
well as SOAP requests? If it's the first, then you have nothing else
to do; however, if you were interested in the second... well, I
suppose you could put something in after the ExecuteAction stage or
at the beginning of the process-view chain which consulted the
resulting ForwardConfig and, if in "SOAP mode", looked up a different
ForwardConfig. Now that you can put arbitrary properties in a
ForwardConfig, you could even configure it in-place:
<action path="/SoapOrHttpDoesntMatter"
type="com.example.ProcessRequestAction"
name="FormBeanName">
<forward name="success" path="/NormalResponse.jsp">
<set-property key="SOAP.path" value="/SOAPResponseTemplate.jsp" />
</forward>
</action>
and then this command early in the process-view chain:
public class AdjustForwardConfigForSoap extends ActionCommandBase {
public boolean execute( ActionContext ctx ) {
if (ctx.containsKey("SOAPModeFlat")) {
ForwardConfig fc = ctx.getForwardConfig();
String alternatePath = fc.getProperty("SOAP.path");
if (alternatePath == null) throw new IllegalStateException();
ForwardConfig alt = new ForwardConfig();
alt.setPath(alternatePath);
ctx.setForwardConfig(alt);
}
}
}
Typical caveats apply, but I think that would handle it. I'm not
totally sure how I feel about a practice of changing the forward
config in the process-view chain, but I can't see any other way you'd
handle it without having to bind your code a lot more to the specific
fact that it might be used in both ways.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I don't want to comment much, if at all, on the chain-based
implementation Marco is trying to accomplish because I am frankly not up
to speed on the 1.3 code base and so am not in a position to comment
intelligently. I'm trying to help him off the list as best I can, but
I'm actually having trouble even before the point he gets to, so I fear
I haven't, and may not be for a while, much help to Marco.
However, just to level-set as far as the current 1.2.x version goes...
StrutsWS allows an Action to handle Web Service requests (SOAP-based)
without changing them in any way. Marco explained it correctly, I'll
just expand a bit...
You have a new RequestProcessor... in processPreprocess(), it looks for
the SOAPAction header. If it isn't there, everything proceeds as
normal, so non-Web Service requests work as always.
If it *is* present though, regardless of its value, the SOAP message
(which presumably is the body of the request now) is parsed and a query
string is created from it. We then do a forward:
doForward(request.getServletPath() + queryString, request, response);
...so then the RP cycle begins again. At this point, for all intents
and purposes, it looks like any other request (with some flags set in
request attributes so the RP knows to not parse the SOAP message again),
except that all the parameters are on the query string like a GET rather
than in the body like a POST. There are some other WS-specific things
added to the RP, like cloning the ActionMapping (via an overridden
processMapping() method) and overriding the input attribute so that we
can be directed to a proper error handling page, some extra stuff after
the Action completes to forward to a special JSP that actually renders
the SOAP-based response, etc. But really the key point is transforming
the incoming SOAP-based message to a query string and restarting the
request cycle.
If you want to take a look, feel free:
http://sourceforge.net/projects/strutsws/
It was always my intent to port StrutsWS to 1.3 when 1.3 was actually
released, but Marco has taken the bull by the horns because he has a
need, and I definitely look forward to him getting it working. I think
the chain approach is tailor-made for a project like StrutsWS.
Frank
Joe Germuska wrote:
>> It works, but yes, you are right in the sense that If I override
>> The struts catalog, everything will screw up... unless I have a look at
>> Chain-config before, so that I know what commands are supposed to be
>> In struts chain, and then add mine while keeping original ones..
>> I think that's the best solution right now..though I don't know if it is
>> the
>> Optimal one
>
>
> For now, any case where one can't use the default chain should begin
> with extracting the default chain from the struts-core JAR and editing
> it, and then explicitly specifying an alternate location for the file in
> the web.xml init parameters.
>
>> >I don't understand how adding parameters to the request path once the
>> >Servlet is already processing it could possibly work; does the
>>
>>> pre-existing code perform a redirect after manipulating the path?
>>
>>
>> That's what the original WSRequstProcessor was doing (Frank, pls comment
>> if I am saying something wrong)..
>> It was working in the old way (for some reason, the preprocess method
>> was then getting executed twice...and that's what I cannot reproduce,
>> because the second time the request will come into the preprocess
>> method, form will be populated..
>
>
> if it does a redirect, that would explain the doubling as well as the
> correct population after the redirect -- but especially in the chain
> model, I wouldn't advise that as the best way to solve the problem.
>
>> However, thanx to your explanation I have one more trial to try.... then
>> I will be lost if it does not work :-)
>
>
> You always have us here on the list ;-)
>
> Joe
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
>It works, but yes, you are right in the sense that If I override
>The struts catalog, everything will screw up... unless I have a look at
>Chain-config before, so that I know what commands are supposed to be
>In struts chain, and then add mine while keeping original ones..
>I think that's the best solution right now..though I don't know if it is
>the
>Optimal one
For now, any case where one can't use the default chain should begin
with extracting the default chain from the struts-core JAR and
editing it, and then explicitly specifying an alternate location for
the file in the web.xml init parameters.
> >I don't understand how adding parameters to the request path once the
> >Servlet is already processing it could possibly work; does the
>>pre-existing code perform a redirect after manipulating the path?
>
>That's what the original WSRequstProcessor was doing (Frank, pls comment
>if I am saying something wrong)..
>It was working in the old way (for some reason, the preprocess method
>was then getting executed twice...and that's what I cannot reproduce,
>because the second time the request will come into the preprocess
>method, form will be populated..
if it does a redirect, that would explain the doubling as well as the
correct population after the redirect -- but especially in the chain
model, I wouldn't advise that as the best way to solve the problem.
>However, thanx to your explanation I have one more trial to try.... then
>I will be lost if it does not work :-)
You always have us here on the list ;-)
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Joe,
Thanx a lot for your reply...
>If you have time to try this, let me know -- but I'd be afraid that
>if you defined another catalog with the name "struts", it would
>overwrite the base "struts" catalog instead of merging with it. If
>that's true, then you either must edit the one chain-config.xml which
>defines the catalog named "struts" or we would have to specify a
>different catalog name for this lookup. Perhaps we should just
>choose "struts.local" or something. This would allow users to add
>preprocessing behavior without touching the base chain-config.xml,
>although it doesn't address the other case of mixing commands within
>the two main chains -- for the moment, I don't see any road to
>solving that which isn't a lot more work than it's worth, since I
>feel that users who are choosing to change the core chains are "power
>users" -- however, the "preprocessing" seems a bit more appropriate
>to expose to "less powerful" users.
Yes I have tried, I have defined a servlet-preprocess chain to override
What struts does by default.
It works, but yes, you are right in the sense that If I override
The struts catalog, everything will screw up... unless I have a look at
Chain-config before, so that I know what commands are supposed to be
In struts chain, and then add mine while keeping original ones..
I think that's the best solution right now..though I don't know if it is
the
Optimal one
>I don't understand how adding parameters to the request path once the
>Servlet is already processing it could possibly work; does the
>pre-existing code perform a redirect after manipulating the path?
That's what the original WSRequstProcessor was doing (Frank, pls comment
if I am saying something wrong)..
It was working in the old way (for some reason, the preprocess method
was then getting executed twice...and that's what I cannot reproduce,
because the second time the request will come into the preprocess
method, form will be populated..
Welll, maybe I need to add another command similar to what I already
have..
>Furthermore, I would think that, at least in SelectAction, if you
>change the path in that way, it would never find the right Action,
>because the "getPath" method is really just returning a key for the
>map of ActionConfig objects -- and changing the key would result in a
>failed lookup.
Yes, that's exactly what's happening... because I am getting a path of
Action.do?param1=x¶m2=y and that does not map to any actinconfig..
However, thanx to your explanation I have one more trial to try.... then
I will be lost if it does not work :-)
Thanx a lot and regards!
marco
I must admit that I've never looked at the strutsws project, so I may
have more questions than answers. Is the idea that the same action
can respond to a WebServices request as to a browser HTTP request?
If that's the case, then you shouldn't need to change SelectAction --
because the same action can "handle" everything. However, you may
need to add in new commands or override existing ones so that by the
time the Action is executed, the ActionContext has been populated the
same way, whether the request came from one source or the other.
Thus, isn't the place to change things more like PopulateActionForm?
Don't bother with a whole redirect -- if you know how to construct a
new URL, then you could just as easily create a map and use
BeanUtils.populate(ActionForm, Map) -- then when the Action operates,
it has no concern for which method was used to invoke the request.
It just trusts that the ActionForm has the right data.
Now, I'm not sure how the response works -- so maybe you want one
action (perhaps in preprocess) which simply sets a flag in the
ActionContext:
context.put("webService", new Boolean(isWebService(request));
Then any later commands could simply test that context value to know
when they need to operate in a different way to accommodate the
differences of web services.
Is this making sense? Without a better handle on the details of
strutsws, I won't be much more help, but unfortunately I don't have
time to make a big study of that right now.
>But for some reasons, when the flow arrives to my ValidateActionForm
>subclass (I have extended it to see what was happening) the two
>parameters for the action form are still null.
>
>If instead the request is not a SOAP request, the chain works as
>normal, and it works just fine (forms get populated & action gets
>executed).
>
>So, I think I am missing one point (or I am not overriding the proper
>methods).
>
>Could you tell me what happens after SelectAction.getPath() gets
>called? Where does the request go?
>Because if I can find the part of the code that gets request parameters
>and populate the form, maybe I can understand what's going on..
>
>If it's not clear, I can mail you my class privately....
>
>Thanx in advance for your reply
>
>Regards
> marco
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>thanx and regards
> marco
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:43 PM +0100 5/20/05, Marco Mistroni wrote:
>Hello Joe,
>
>>As an aside, I think reveals an unfortunate (though minor)
>>shortcoming of the basic chain model: either way, you must edit the
>>struts chain-config.xml in order to use this behavior. I would
>>prefer if there were a way for users to register their preprocessing
>>command without having to extract the chain-config and edit it. That
>>in itself isn't so bad, but it also makes it harder to track future
>>changes in the chain-config.xml as distributed and integrate your
>>local details with newer versions. It almost calls for an AOP-like
>>configuration realm.
>
>Hold on.... the 'editing' of chain config was my mistake because I
>didn't want to have too many files while I was testing my app.
>Now that I remember, in that famous article of Bill Siggelkow it was
>explained how to 'override' chain processing by just specifying
>The chain that you want to override..
>In that case, I could just write my own custom-config.xml which contains
>The chain servlet-preprocess (or whatever chain I want to override) and
>Just declare it.. (like I have done in another very simple app), though
>I don't know if this will solve problems that you have identified above.
If you have time to try this, let me know -- but I'd be afraid that
if you defined another catalog with the name "struts", it would
overwrite the base "struts" catalog instead of merging with it. If
that's true, then you either must edit the one chain-config.xml which
defines the catalog named "struts" or we would have to specify a
different catalog name for this lookup. Perhaps we should just
choose "struts.local" or something. This would allow users to add
preprocessing behavior without touching the base chain-config.xml,
although it doesn't address the other case of mixing commands within
the two main chains -- for the moment, I don't see any road to
solving that which isn't a lot more work than it's worth, since I
feel that users who are choosing to change the core chains are "power
users" -- however, the "preprocessing" seems a bit more appropriate
to expose to "less powerful" users.
>Sorry if I add another question..because there's something that has been
>bothering me since I am trying to port my app to 1.3.
>
>App was frank zammetti's strutsws, that allows to call Struts action
>using
>SOAP requests.
>Without going into details, RequestProcessor.preProcess(), if identifies
>an incoming XML request, it will extract those parameters and add them
>to the URL (e.g. /myAction.do)
>If the request was an XML request, it will extract the parameters from
>the SOAP request, and produce a new URL /myAction.do?param1=x¶m2=y
>
>I Have extended the SelectAction.getPath(Context ctx) command so that it
>does exactly
>What the original RequestPreprocessor.preProcess() was doing, so that
>the path returned by getPath(Context ctx) will be
>/myAction.do?param1=x¶m2=y).
I don't understand how adding parameters to the request path once the
Servlet is already processing it could possibly work; does the
pre-existing code perform a redirect after manipulating the path?
Furthermore, I would think that, at least in SelectAction, if you
change the path in that way, it would never find the right Action,
because the "getPath" method is really just returning a key for the
map of ActionConfig objects -- and changing the key would result in a
failed lookup.
I must admit that I've never looked at the strutsws project, so I may
have more questions than answers. Is the idea that the same action
can respond to a WebServices request as to a browser HTTP request?
If that's the case, then you shouldn't need to change SelectAction --
because the same action can "handle" everything. However, you may
need to add in new commands or override existing ones so that by the
time the Action is executed, the ActionContext has been populated the
same way, whether the request came from one source or the other.
Thus, isn't the place to change things more like PopulateActionForm?
Don't bother with a whole redirect -- if you know how to construct a
new URL, then you could just as easily create a map and use
BeanUtils.populate(ActionForm, Map) -- then when the Action operates,
it has no concern for which method was used to invoke the request.
It just trusts that the ActionForm has the right data.
Now, I'm not sure how the response works -- so maybe you want one
action (perhaps in preprocess) which simply sets a flag in the
ActionContext:
context.put("webService", new Boolean(isWebService(request));
Then any later commands could simply test that context value to know
when they need to operate in a different way to accommodate the
differences of web services.
Is this making sense? Without a better handle on the details of
strutsws, I won't be much more help, but unfortunately I don't have
time to make a big study of that right now.
>But for some reasons, when the flow arrives to my ValidateActionForm
>subclass (I have extended it to see what was happening) the two
>parameters for the action form are still null.
>
>If instead the request is not a SOAP request, the chain works as
>normal, and it works just fine (forms get populated & action gets
>executed).
>
>So, I think I am missing one point (or I am not overriding the proper
>methods).
>
>Could you tell me what happens after SelectAction.getPath() gets
>called? Where does the request go?
>Because if I can find the part of the code that gets request parameters
>and populate the form, maybe I can understand what's going on..
>
>If it's not clear, I can mail you my class privately....
>
>Thanx in advance for your reply
>
>Regards
> marco
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>thanx and regards
> marco
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Joe,
>As an aside, I think reveals an unfortunate (though minor)
>shortcoming of the basic chain model: either way, you must edit the
>struts chain-config.xml in order to use this behavior. I would
>prefer if there were a way for users to register their preprocessing
>command without having to extract the chain-config and edit it. That
>in itself isn't so bad, but it also makes it harder to track future
>changes in the chain-config.xml as distributed and integrate your
>local details with newer versions. It almost calls for an AOP-like
>configuration realm.
Hold on.... the 'editing' of chain config was my mistake because I
didn't want to have too many files while I was testing my app.
Now that I remember, in that famous article of Bill Siggelkow it was
explained how to 'override' chain processing by just specifying
The chain that you want to override..
In that case, I could just write my own custom-config.xml which contains
The chain servlet-preprocess (or whatever chain I want to override) and
Just declare it.. (like I have done in another very simple app), though
I don't know if this will solve problems that you have identified above.
>If you changed the behavior of
>org.apache.commons.chain.generic.LookupCommand, you would impact
>Struts in each of the places where it has a <lookup> element --
>looking up the preprocessing command, looking up the process-action
>chain, and looking up the process-view chain. That's probably not
>
yep, I have noticed it :-)
Sorry if I add another question..because there's something that has been
bothering me since I am trying to port my app to 1.3.
App was frank zammetti's strutsws, that allows to call Struts action
using
SOAP requests.
Without going into details, RequestProcessor.preProcess(), if identifies
an incoming XML request, it will extract those parameters and add them
to the URL (e.g. /myAction.do)
If the request was an XML request, it will extract the parameters from
the SOAP request, and produce a new URL /myAction.do?param1=x¶m2=y
I Have extended the SelectAction.getPath(Context ctx) command so that it
does exactly
What the original RequestPreprocessor.preProcess() was doing, so that
the path returned by getPath(Context ctx) will be
/myAction.do?param1=x¶m2=y).
But for some reasons, when the flow arrives to my ValidateActionForm
subclass (I have extended it to see what was happening) the two
parameters for the action form are still null.
If instead the request is not a SOAP request, the chain works as
normal, and it works just fine (forms get populated & action gets
executed).
So, I think I am missing one point (or I am not overriding the proper
methods).
Could you tell me what happens after SelectAction.getPath() gets
called? Where does the request go?
Because if I can find the part of the code that gets request parameters
and populate the form, maybe I can understand what's going on..
If it's not clear, I can mail you my class privately....
Thanx in advance for your reply
Regards
marco
thanx and regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
No, rather than changing LookupCommand, you would put your logic into
one or more classes that are clean implementations of Command and
configure in a catalog with a name so that the existing lookup
command would find them -- either put them in catalog "struts" under
the name "servlet-standard-preprocess" or change the configuration of
the lookup command to find them:
<lookup
catalogName="*your catalog*"
name="*your command name*"
optional="true"/>
You shouldn't need to change the behavior of LookupCommand itself --
you just need to give it the right information to do its job.
As an aside, I think reveals an unfortunate (though minor)
shortcoming of the basic chain model: either way, you must edit the
struts chain-config.xml in order to use this behavior. I would
prefer if there were a way for users to register their preprocessing
command without having to extract the chain-config and edit it. That
in itself isn't so bad, but it also makes it harder to track future
changes in the chain-config.xml as distributed and integrate your
local details with newer versions. It almost calls for an AOP-like
configuration realm.
Also, to clarify:
>And so, I will need to replace this entry in chain-config.xml
><define name= "lookup"
> className= "org.apache.commons.chain.generic.LookupCommand"
>/>
>
>with
><define name= "lookup"
> className= "com.myapp.commands.MyLookupCommand" />
This <define> element is just a bit of syntactic sugar that Craig
came up with in the chain-config digesting process that allows you to
do this once and then later have simpler configuration, say for
example if you use a given command frequently. It's comparable to
the <taskdef> tag in Ant. But again, the whole intention of the
LookupCommand is that instead of changing its behavior, you point it
at the other commands which you want executed.
If you changed the behavior of
org.apache.commons.chain.generic.LookupCommand, you would impact
Struts in each of the places where it has a <lookup> element --
looking up the preprocessing command, looking up the process-action
chain, and looking up the process-view chain. That's probably not
what you want.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: sTRUTS 1.3 - chain flow
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Joe,
I have read in a sample chain-config.xml that I have downloaded,
That RequestProcessor.processPreprocess maps now to 'LookupCommand with
optional="true"'
Does that mean that, If in my webapp my
RequestProcessor.processPreProcess was doing some logic, now I have to
put that logic into a
Class that extends LookUpCommand?
And so, I will need to replace this entry in chain-config.xml
<define name= "lookup"
className= "org.apache.commons.chain.generic.LookupCommand"
/>
with
<define name= "lookup"
className= "com.myapp.commands.MyLookupCommand" />
?
thanx in advance and regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: sTRUTS 1.3 - chain flow
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:05 AM +0100 5/17/05, Marco Mistroni wrote:
>Hello Joe,
> I am trying to port an app (Frank Zammetti's strutsws)that was
>using Struts 1.1 to Struts 1.3.
>I have a quick question: in which class/method the ActionForm is
>populated with parameters from request?
org.apache.struts.chain.commands.servlet.PopulateActionForm
(exending org.apache.struts.chain.commands.AbstractPopulateActionForm)
http://cvs.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/chain/commands/servlet/PopulateActionForm.java?root=Apache-SVN&rev=170126&view=log
http://cvs.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractPopulateActionForm.java?root=Apache-SVN&rev=169091&view=log
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
sTRUTS 1.3 - chain flow
Posted by Marco Mistroni <mm...@waersystems.com>.
Hello Joe,
I am trying to port an app (Frank Zammetti's strutsws)that was
using Struts 1.1 to Struts 1.3.
I have a quick question: in which class/method the ActionForm is
populated with parameters from request?
Thanx and regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re:
Posted by Joe Germuska <Jo...@Germuska.com>.
<c:set var="minQ"><bean:message key="prompt.minQuantity" /></c:set>
<c:set var="maxQ"><bean:message key="prompt.maxQuantity" /></c:set>
<bean:message key="error.comparequantity"
arg0="minQ"
arg1="less"
arg2="maxQ"/>
Joe
At 3:17 PM +0100 5/16/05, Marco Mistroni wrote:
>Hello all,
> I have a question regarding bean:message
>
>I have a page where I need to display a message with some
>Dynamc parameters, and I would be able to 'internationalize' the whole
>message
>
>For example, let's say that my message is
>
>Error.comparequantity={0} must be {1} than {2}
>
>
>I would like to use the tag in my page like this
>
><bean:message key="error.comparequantity"
>
>arg0="prompt.minQuantity"
>
>arg1="less"
>
>arg2="prompt.maxQuantity"/>');
>
>
>However, it looks like args0 & args2 are not retrieved from my
>ApplicationREsources.properties file
>
>Any idea on how to achieve that?
>
>Thanx in advance and regars
> marco
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org