I'm trying to integrate paypal IPN with my Java Struts web application. According to paypal, there are only 2 variables that are posted with IPN across all transaction types, but there are a bunch of other variables that could possibly be posted.
If a post variable is sent that's not in my action form, then struts returns an error about the form not having the property/setter.
IPN has like 300 variables and I really don't want to have a field for all possible ones. Is it possible in struts to accept post variables that my actionForm may not have accounted for?
If you want to use Post Variables which will not be in Struts Form, you should bypass struts form and use simple html form with struts action classes. Some post variable without getter setter in struts form will throw the exception as you specified. So it is better to use HTML form to gain more flexibility. Off course we should write some functionalities for validation and others again for this type of form.
All we want to say that, you can use simple html forms with struts action classes without any issues. We have already done these type of works in our production applications.
Thanks
Related
I've got a simple html page with four buttons. I know how to map the buttons so that the Action Class gets the value of whatever is selected and call a method based on each button in the Action Class. However, what should I do with the Action Form? Can I just leave it blank? It seems that struts requires you to map a bean, yet I'm not really sure what to put in the Action Form, since all that I'm trying to do is call methods in the Action Class.
The struts is what we call nowadays as "action-based" framework. Nowadays most frameworks are what we call "event-based" framework.
It was built to make your life easier when you need to fill huge html forms and then send it to the server.
It was not intended to make your life easier when pressing a button to execute some code on the server and then return with that specific small result.
The main idea of struts was that, big things and change the entire view.
This example (and mabye those ones, takes forever to download) how easier struts made the form-processing easier. see "5. Action (Controller)" of first link.
If not clear, in the time, when there were just servlets, you needed something like this to parse a form.
TL;DR; In the end the ActionForm is there just to help you with your html forms that otherwise you would need to parse by hand instead to receive them as well-formed java beans.
Purpose of ActionForm is to map your fields in your html forms to a corresposnding bean which can be mapped in your strus-config.xml inside the form-bean tag.
Can I just leave it blank? yes the ActionForm is not a required field in <action> tag.
I am currently learning JSF and was rather amazed and puzzled when I realized that whenever we use <h:form>, the standard behavior of JSF is to always show me the URL of the previous page in the browser, as opposed to the URL of the current page.
I understand that this has to do with the way JSF always posts a form to the same page and then just renders whatever page the controller gives it back to the browser which doesn't know the page location has changed.
It seems like JSF has been around for long enough that there must be a clean, solid way to deal with this. If so, would you mind sharing?
I have found various workarounds, but sadly nothing that seems like a real solid solution.
Simply accept that the URL is misleading.
Append "?faces-redirect=true" to the return value of every bean's action and then
figure out how to replace #RequestScoped with something else (Flash Scopes, CDI conversation, #SessionScoped, ...).
accept to have two HTTP round trips for every user action.
Use some method (e.g. 3rd party library or custom code) to hide the page name in the URL, always using the same generic URL for every page.
If "?faces-redirect=true" is as good as it gets, is there a way do configure an entire application to treat all requests this way?
Indeed, JSF as being a form based application targeted MVC framework submits the POST form to the very same URL as where the page with the <h:form> is been requested form. You can confirm it by looking at the <form action> URL of the generated HTML output. This is in web development terms characterized as postback. A navigation on a postback does by default not cause a new request to the new URL, but instead loads the target page as content of the response. This is indeed confusing when you merely want page-to-page navigation.
Generally, the right approach as to navigation/redirection depends on the business requirements and the idempotence (read: "bookmarkability") of the request (note: for concrete code examples, see the "See also" links below).
If the request is idempotent, just use a GET form/link instead of POST form (i.e. use <a>, <form>, <h:link> or <h:button> instead of <h:form> and <h:commandXxx>).
For example, page-to-page navigation, Google-like search form, etc.
If the request is non-idempotent, just show results conditionally in the same view (i.e. return null or void from action method and make use of e.g. <h:message(s)> and/or rendered).
For example, in-page data entry/edit, multi-step wizard, modal dialog, confirmation form, etc.
If the request is non-idempotent, but the target page is idempotent, just send a redirect after POST (i.e. return outcome with ?faces-redirect=true from action method, or manually invoke ExternalContext#redirect(), or put <redirect/> in legacy XML navigation case).
For example, showing list of all data after successful editing, redirect after login, etc.
Note that pure page-to-page navigation is usually idempotent and this is where many JSF starters fail by abusing command links/buttons for that and then complain afterwards that URLs don't change. Also note that navigation cases are very rarely used in real world applications which are developed with respect to SEO/UX and this is where many JSF tutorials fail by letting the readers believe otherwise.
Also note that using POST is absolutely not "more secure" than GET because the request parameters aren't immediately visible in URL. They are still visible in HTTP request body and still manipulatable. So there's absolutely no reason to prefer POST for idempotent requests for the sake of "security". The real security is in using HTTPS instead of HTTP and checking in business service methods if currently logged-in user is allowed to query entity X, or to manipulate entity X, etc. A decent security framework offers annotations for this.
See also:
What is the difference between redirect and navigation/forward and when to use what?
JSF implicit vs. explicit navigation
What URL to use to link / navigate to other JSF pages
Bookmarkability via View Parameters feature
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
When should I use h:outputLink instead of h:commandLink?
Creating master-detail pages for entities, how to link them and which bean scope to choose
Retaining GET request query string parameters on JSF form submit
Pass an object between #ViewScoped beans without using GET params
This is my first time with wicket, so please bear with me.
Most examples in wicket show how with a wicket id you can automagically replace the inner HTML with different things. Using this knowledge I've hand written a form in HTML with lots of formatting and JQuery for different things, and only using Wicket to autogenerate the info for 2 select boxes. However when I try to parse the submitted information on the Wicket side, I get confused.
The only way I've figured out that's easy is using RequestCycle.get().getRequest().getRequestParameters(). to get all the passed info. It works, but I don't think that's the ideal way to use Wicket. There also seems to be a way with request handlers but I have no idea where to start, especially since a lot of documentation is out of date with the new 6.0.0 release.
What is the way I'm supposed to use Wicket with forms? Do I hand write most of the form, only let Wicket autogenerate some of the info, and use RequestCycle? Do I write a skeleton form, have Wicket autogenerate the rest, and use lots of submit handlers? Where is this documented in an easy to understand beginner tutorial?
Note: My form has several fields that are created dynamically (think "click here to add more options") and is submitted in the background with AJAX, verified, then cleared. This might complicate the Wicket side of things, but is a functional requirement
With Wicket you can think of HTML markup as if it was a template. Markup is actually almost-standard HTML. You can (and should) define wicket:id attributes for everything that will have certain behavior or logic attached (forms, buttons, links), or require some server-side processing (such as form components or nested custom components or panels). Everything else will be output in the response as it is in the markup.
Wicket will handle form submission and process the request for you. In Wicket, form components are usually defined server-side, and added to a Form component. In the Form component's onSubmit(), Wicket will have already processed the request, and the submitted values will be available in the FormComponent's Models.
So, the ideal way for Wicket to handle form submission would involve the server-side creation of any components in the form.
The following Wicket Examples page shows a basic Form with some FormComponents in it: Wicket Examples - forminput. You can even see its source code.
Also, you might find the following Wicket wiki page useful: How to do things in Wicket - Forms.
Regarding dynamic component creation, whenever a new dynamic component has to be created, you could for instance make an Ajax request that creates the component server side (wrapped in a ListView, for example), and get markup refreshed in the ajax callback.
There's an example of such a list here: Wicket in action - Building a ListEditor form component
Just to add, I found the Wicket in Action book to be an excellent resource for learning Wicket. Chapter 6 - Processing user input using forms elaborates on the subject.
I am new to Struts2.On doing sample programs.I came to know that we are creating a class and extending Action and another one class extending Actionform.I dont know why we are doing that ?And I can understand that struts contains set of custom tag libs which can be used .We are defining the Action tag and the appropriate form-bean.I could not find the concept and advantage behind this framework. Could anyone provide the links or books where i can find the struts concept.
thanks in advance
Struts is an implementation of MVC. The Action class, in combination with the configuration (struts-config.xml normally) is the controller, deciding based on what the user submits what parts of the model (your business logic, should cotain nothing web-specific).
The ActionForm as mentioned about represents the form submitted by the user.
I personally read Struts in Action many years ago, but that only covers Struts 1. The Struts website itself should be helpful http://struts.apache.org/
Struts is far in the past for me, but let's see if I can dredge up a memory to explain.
Struts associates an Action class with a request URL. When that request comes in, Struts looks up the Action using the request URL and executes it.
The ActionForm associates an HTML form with an Action so Struts can marshall HTTP request parameter name/value pairs and bind them to Java objects. These Java objects are passed to the Action so it can do its execution work.
Struts is rather old now; it's been around since 2000. The Action and ActionForm concepts have been part of it from release 1.0. There are lots of books on Amazon and articles on the web. If you can't find any, or have to ask here to get some, I'd say you're being far too passive and lazy about it. Fire up Google and get to work.
Don't mix up Struts 1 and Struts 2 both are having different architectures
Struts 2 = Struts + WebWork.
Struts2 architecture http://struts.apache.org/2.3.1/docs/home.html
Struts2 guides http://struts.apache.org/2.3.1/docs/guides.html
I've just inherited some old Struts code.
If Struts (1.3) follows the MVC pattern, how do the Action classes fill the View with variables to render in HTML ?
So far, I've seen the Action classes push variables in (1) the HTTP request with
request.setAttribute("name", user.getName())
(2) in ActionForm classes, using methods specific to the application:
UserForm form = (UserForm) actionForm;
form.setUserName(user.getName());
and (3) a requestScope variable, that I see in the JSP layer (the view uses JSP), but I can't see in the Action classes.
<p style='color: red'><c:out value='${requestScope.userName}' /></p>
So, which of these is considered old-school, and what's the recommended way of pushing variables in the View in Struts ?
My Struts days are long over, but as far as I remember we used to place one view-specific bean (which would work as a holder for fine-graner beans or collections of beans) into the request scope within our Action.perform() implementation. This view-specific bean would then be rendered by the view.
As Struts 1.3 is considered old-school, I'd recommend to go with the flow and use the style that already is used throughout the application you inherited.
If all different styles are already used, pick the most used one. After that, pick your personal favourite. Mine would be 1 or 3 - the form (2) is usually best suited for data that will eventually be rendered inside some form controls. If this is the case - use the form, otherwise - don't.