Nabeel,
You dont have to write parameters separately when submitting the form.
say, you have a form called "test"
*<s:form name="test" action="submit" >
</s:form>*
inside that form you have various of struts html components,
and your *struts.xml* file should be like this,
*<action name="submit" class="com.search.UserSearchAction "
method="performSearch">
<result name="success">/pages/ext/summary.jsp</result>
</action>*
so when the form submitted your *performSearch (if you didnt specify a
method Struts framework will assume that you have a method called execute in
your action class) *method in *UserSearchAction* class will be called, from
there you can
access the submitted values, at the end of the method if everything are
according to plan you expected you should return *"success" *so Struts
framework will identify which JSP to load, (look at the struts.xml) which i
have described above.
Hope this will help :)
--
Regards
Kushan Jayathilake
On Mon, Oct 18, 2010 at 3:24 PM, Nabeel Saad <nabeeliph...@gmail.com> wrote:
> Hello folks,
>
> Thanks for the replies Kushan and Li Ying. Reading through both of your
> emails:
>
> - Kushan, yes, my code for the class UserSearchAction has a field called:
>
> int searchType
>
> Along with a getter and setter for it like:
>
> public int getSearchType()
> public void setSearchType(int searchType)
>
> I believe that is all set up correctly.
>
> -Li Ying
>
> Thanks for the suggestion, I've used the Apache tool and was able to see
> that the parameters are going through correctly from the client side as
> such:
>
> searchType=2&value=testuser52&postcode=
>
> Clearly searchType has a value of "2" which is an integer. However, at
> some
> point, the server code (and this is not my code specifically, it's the
> xwork
> code) is outputting the following:
>
> [ParametersInterceptor] Setting params struts.portlet.mode => [ view ]
> dynamicAttributes => [ {} ] struts.portlet.action => [ /view/view/search ]
> templateDir => [ template ] theme => [ simple ] value => [
> *testuser52testuser52,
> testuser52* ] searchType => [*11, 1* ] postcode => [ , ]
>
> which is clearly duplicating my params and messing with xworks that fails
> cause it is now trying to convert {11, 1} which is an array into an into
> and
> that fails.
>
> As for upgrading Struts and xwork libraries, I'm trying that now, but I
> don't see why that would need to be upgraded given the fact that it
> functioned as expected before the upgrade of the JBoss server in which it
> resides, does that make sense? Also, if it does turn out to be the struts
> side of things, then it'll require quite a bit of rigorous testing to take
> place.
>
> One other question, do you guys know where the "writing of the parameters"
> takes place in the code? i.e. where in the source code of struts/xwork
> does
> the code take the parameters from the HTTP headers or where ever and
> associate them to the fields in the Java objects?
>
> Cheers.
> Nabeel
>
> On Sat, Oct 16, 2010 at 5:54 AM, Kushan Jayathilake <kusha...@gmail.com
> >wrote:
>
> > Nabeel,
> >
> > If your text field name is customerName then you have to have a property
> in
> > your action class called "String customerName" and also there should be a
> > getter and setter for this property. When the form is submitted Struts
> > framework will call the setter to set the value to the property and you
> can
> > use getter to access the property value. Do the conversion in the action
> > class.that's more easy.
> >
> > Regards
> > Kushan Jayathilake
> >
> > On 15 Oct 2010 20:55, "Nabeel Saad" <nabeeliph...@gmail.com> wrote:
> >
> > Hello folks,
> >
> > I'm working on a project to upgrade a JBoss Portal community platform to
> a
> > supported version of JBoss Enterprise Portal Platform.
> >
> > During the process, I've gotten the platform building and functioning
> > mostly
> > normally. I have one issue that is completely blocking me for the
> moment.
> > There is a portlet that pretty much searches for users that is currently
> > failing. All you do is fill in a form (a dropdown [called searchType]
> with
> > the type of data your are providing - username, address, card number,
> > etc...
> > - the value for that data and a post code) and it searches for the user
> and
> > returns the results of the search.
> >
> > However, when I click on the search button, I get re-directed to the
> search
> > page and the attached "debug_stack_trace" is thrown in the JBoss console.
> > What I've understood from the trace and from my research and testing, is
> > that the dropdown field searchType is returning data that is breaking its
> > conversion into a number, thus the NumberFormatException.
> >
> > Method "setSearchType" failed for object
> > com.client.user.search.action.searchcustomeract...@5524c895
> > [java.lang.NoSuchMethodException:
> > setSearchType([Ljava.lang.String;)]
> >
> > This error does make sense because it's trying to assign the value of
> > searchType to the field in the class; however, searchType is actually
> > expected to be an int, and somehow it's receiving a String or the fact
> that
> > it's failing to convert it to a Number, then it says I can't find a
> method
> > that takes String for setSearchType...
> >
> > I ran through the code, and was able to find exactly where it broke. In
> > OgnlTypeConverterWrapper.convertValue the method returns
> > "ognl.NoConversionPossible" which causes OgnlRuntime.getConvertedTypes to
> > return false.
> >
> > Clearly xwork is not able to convert my property, the last two lines
> before
> > the NumberFormatException are:
> >
> > [XWorkConverter] field-level type converter for property [searchType] =
> > none
> > found
> > [XWorkConverter] global-level type converter for property [searchType] =
> > none found
> >
> > However, what I don't get is that this is core Struts functionality,
> > correct? And my project, using maven dependencies, depends on
> struts2-core
> > which in turn depends on xwork-2.1.1. So, I don't get why this is now
> > breaking.
> >
> > One of the things that I have noticed is the line saying:
> >
> > [ParametersInterceptor] Setting params struts.portlet.mode => [ view ]
> > dynamicAttributes => [ {} ] struts.portlet.action => [ /view/view/search
> ]
> > templateDir => [ template ] theme => [ simple ] value => [
> > *testuser52testuser52,
> > testuser52* ] searchType => [ *11, 1* ] postcode => [ , ]
> >
> > Note the text in *bold*. These are the values that I have entered in the
> > form; however, it is duplicated in the debug output!! The actual value
> > that
> > I input was only testuser52 and 1. But somehow, somewhere in the struts
> > mechanism (I think), these parameters were duplicated twice, once in the
> > value stored in the first index of the array and another as a second
> value
> > in the second index of the array. When I ran the original platform, the
> > parameter look like this:
> >
> > [ParametersInterceptor] Setting params struts.portlet.mode => [ view ]
> > dynamicAttributes => [ {} ] struts.portlet.action => [ /view/view/search
> ]
> > templateDir => [ template ] theme => [ simple ] value => [ *testuser52* ]
> > searchType => [ *1* ] postcode => [ , ]
> >
> > I've ran the code through a debugger in Ecipse while running in JBoss to
> > try
> > and see what was happening.. first of all, the duplication is happening
> at
> > the lowest level of reading that I can see... whenever there is a
> > getParameters() type call anywhere (even in xwork.ActionContext), the
> > parameters are already duplicated. So, I'm wondering if this duplication
> > isn't happening when the parameters are "written". I'm not even sure the
> > duplication would affect the final output of my portlet (although, I
> > suspect
> > it would given that the "main" value is corrupted by being duplicated)
> but
> > I'm just trying to figure out the different possible reasons for this
> > portlet to break.
> >
> > So in summary, I think the problems I have are:
> > 1. Parameters duplicated in request parameters somehow
> > 2. xwork converter fails to convert my searchType String of value { 11,
> 1}
> > (an array) to an int.
> >
> > Any thoughts would be much appreciated as I've been stuck on this issue
> for
> > about a week now.
> >
> > Cheers,
> > Nabeel
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > For additional commands, e-mail: user-h...@struts.apache.org
> >
>
>
>
> --
> --------------------------------------------
> T: +44 7 525 611 473
> E: nabeels...@hotmail.com
>
