This is my code
Pipeline
Pipelets java
Pipelets XML
I'm passing a parameter(SKUs) value into a pipeline from js.
The value is getting passed into the pipeline but not into pipelets.
It gives me parameter SKUs in not available.
Thanks in Advance
you are trying to pass a String to a List. You could try again by making Pipelet Input Parameter "SKUs" type "java.util.List<java.util.String>".
If your SKUs parameter is passed to the pipeline using JS client (via post or get), your pipelet needs to process type String[].
I am having a method test like below and making a RESTful webservice call to fetch the data,
#RequestMapping(value ="/select", method = RequestMethod.GET)
#ResponseBody
public String test(
#RequestParam(value="begin", defaultValue="0",required=false) final String begin
)
{
//Some java code
}
**RESTful Webservice Call:**
http://localhost:8081/a/b/c/select?begin=1
Returning the data properly
http://localhost:8081/a/b/c/select?begin:1
Here in the url = has been replaced with : for negative testing.
Here Spring ignores the given value 1 and picks the default value 0 and returns the data accordingly without errors
Question:
But I want to capture the actual URL field with value which is begin:1, do some validation and display error message that the url is incorrect.
I understood that begin:1 is not considered as part of url by spring and hence picks the default value. Wondering is there a way in Spring to capture the wrongly framed url's.
Any pointers would be helpful. Many Thanks!
I need to develop a web method that has many parameters. In REST, I understand a webservice has its own significance by attaching itself to particular entity and HttpVerb determines operation type.
This webmethod cannot be associated with an entity, it just calls a stored procedure and returns data, so I assume it only has only a GET method. But it has too many parameters to be fit into a URL. So, do I need to consider using POST method instead of GET.
It wouldn't really pass as 100% true to REST but you can have one web method that you call that looks at query string part of the url to get the additional parameters.
You would have a web method with a route of '/GetData'.
domain.com/GetData?Parameters=firstParm=1^secondParm=info^thirdParm=test
then in the web method, you would check the query string for Parameters and then split the string by the '^' symbol.
or
domain.com/GetData?firstParm=1&secondParm=info&thirdParm=test
this you would have to do a query string for each parameter.
I have read the Spring documentation and I was not able to find relevant information regarding the expected behavior of a Spring MVC controller method returning null (with a return type of String).
Can someone please provide a reply or direct me to relevant documentation? Or to put it another way, what would be the benefit of returning null from a Spring MVC controller method?
In Spring 2, when you returned null from a controller you were saying to the Spring dispatcher that you don't want it to search for a view.
You did this if you were handling the response yourself by writing the response content directly and then flushing the output stream (you were managing a file download for example).
If you didn't return null, Spring would have forwarded to a view who would try to write to the response also, messing up your already written data or resulting in an exception if the response was already commited.
Returning null was a way of saying back off to Spring's view resolver.
A lot of things changed in Spring 3 and now the same can be obtained by having an #RequestMapping annotated method that returns void.
If you have a return type of String but you return null I think that it uses the default RequestToViewNameTranslator for translating an incoming HttpServletRequest into a logical view name when the view name wasn't explicitly supplied.
Return type String in spring mvc generally returns your view resolver, it can be your JSP, html or any other view page.
http://www.mkyong.com/spring3/spring-3-mvc-hello-world-example/
Suppose you want to return a normal String like "hi", you can use #ResponseBody annotation to do this.
i wish to have a simple Action in my controller that accepts a few optional values and some integer values.
this is my route i wish to have:
HTTP.POST
/review/create
and this is the Action method i would like...
[AcceptVerbs(HttpVerbs.Post)]
public JsonResult Create(int userId,
int addressId,
byte baseScore,
byte reviewType,
string subject,
string description)
{ ... }
I'm under the uneducated impression that all of those arguments above will be populated by the forms collection values ... but it's not happening. Also, I have no idea how I would write a route, to handle those ... because those values are form post data....
here's my global.asax....
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
// Api - Search methods.
routes.MapRoute(
"Search Methods",
"{controller}/{action}"
);
In fact, the action method is never called because it doesn't seem to find it :(
But, if create and action without any of those arguments, then it finds it ?????????
How would you write a route and action method to accept some require and some optional arguments, for the route /review/create ?
As far as i can see you may rewrite your controller action like this:
public ActionResult Create(int foo, int bar, byte blah, string name, int? xxx) {
// code here
}
The ModelBinder will then ensure that foo,bar and blah are set. Name and xxx may be null. I can't test it a the moment, but i think return type of the action should be ActionResult.
If you are POST'ing a form, just make sure that the elements in your form (textboxes, checkboxes, textarea, etc) have id's that match the parameters in your method. As an alternative you can pass a FormCollection to the method, and do myFormCollection["foo"] to get a string representation of the value (which can then be parsed to an int).
From my experience, you are missing a number of key elements and concepts with this question.
First and foremost, I don't believe you can execute a POST without a form. The form has to contain the controls from which you pull the values that get passed to the controller method. If the goal is to simply unit test your POST controller method, then just call the method directly in your test, which it appears that you're doing, based on one of your comments. If you involve the view, then you're doing integration testing, not unit testing. Regardless of the test type, the test will always fail because you are choosing not to build the form. Even if you manage to force the POST using Fiddler, Firebug or any other mechanism, you're still not testing the view, you're testing the HTTP protocol.
I highly recommend that you employ a web application testing tool, such as WatiN or Selenium, to test your web pages, rather than throw together a quick-and-dirty test that really doesn't test anything useful.
In your post request set content-type="application/json; charset=UTF-8" and pass the values for the method parameter in JSON format. This should make Asp.MVC not to look in FormCollection for those values.