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.
Related
In Stuts2 I am using Tiles plugin to create a layout for the website (menu, footer, header etc.) that is consistent on every page.
Now each tile is just a static HTML content.
Is it possible to make a Tile more dynamic by eg. calling a Footer action class every time the footer is to be rendered? For example: to fetch footer content from database.
If I was to do that inside every page's action class in my application this would make for a very unusable code...
So maybe it is possible from Tile perspective?
There is only one way to do what you ask with a tiles version less than 2.2.2 and that is with a "preparer".
This however is not an integration with struts2 but would mean the preparer it self will access the service layer to get the required content for the view and all that content would need to be set though tiles attributes.
With tiles versions 2.2.2 and higher:
You can use OGNL expressions within tiles attributes, this can allow access to some struts2 interaction as well as static method access. With static method access you can call a method to return a string how ever you want. Creating such a string would be on par with writing a scriptlet.
To upgrade you need to either manually override some jars to get tiles 2.2.2, or to get version three you will need to implement your own result type: How to integrate Struts 2 with Tiles 3.
I don't actually recommend either of the above methods at this time, tiles 3 is recommended but not as an excuse to do something as bad as writing a scriptlet. It would probably be better to use the s:action tag in a tile, as mentioned by David or use an Ajax method as mentioned by Jaiwo99. The reason being that both these methods keep with struts2 while the ones I presented would be unusual and be harder to maintain. Personally I would lean towards the ajax methods.
Struts2 along with the struts2-json-plugin makes creating json services very simple. Tiles is a nice system for reducing boiler plate. If ajax is used heavily the two really can compliment each other. You can make a lot of reusable ajax components, just be sure to not hard code the urls of actions. Always use the s:url tag and assign that to JS variables.
Try following code:
$('#footer').load('your/action/with/namespace');
i'm assuming your footer is with id footer, everytime you open a page, your footer action class will be called and the data can be fetched dynamically.
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 would like to render the same JSP for multiple Struts Actions. I'm having trouble because when rendering the JSP, the bean name is different depending on which Action was called. So, I can't call something like:
<c:out value="${myBean.myProperty}" />
because the bean isn't necessarily called myBean.
Currently, I've been getting around this by placing any common objects I'll need in the JSP into the HttpSession. For example:
public class SampleAction extends Action
{
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception
{
String string = "TEST";
HttpSession session = request.getSession();
session.setAttribute("sampleString", string);
return mapping.findForward("sampleAction");
}
}
Then, in the JSP, I can simple reference "sampleString" and it won't change depending on the rendering Action.
Of course, the objects I'm using are much larger than a string, and I don't want to put objects in the session if I don't have to. Is there any way to just put an object into the page context or something, rather than the session, in order to share it among different JSPs?
I'm coming from the Rails world, so I'm very new to Struts and am finding myself a bit lost. I have to extend an existing application written in Struts. The program actually uses BeanAction to combine an ActionForm with an Action, so the example above isn't exactly what my code looks like.
Thanks for any help clearing up my confusion!
My first thought was to try implementing it as a custom tag, just like krosenvold said in his answer. But you said you are new to Struts, and I will assume you are new to JSP's and J2EE web development too. And custom tag's are not a very easy subject.
You could use a 'proxy' page to call via jsp:include your destination JSP. The jsp:include tag can have a body having jsp:param tags, in which you can map a common variable name to different references.
See here for an example in jsp:param in jsp:include.
By doing that, you will have a single page with you real code, and N proxies to handle referencing to your complex objects.
Using custom tags would work too, this is just another way of doing it, which I personally think is easier to implement for a non-SCWCD.
I think you want to use an interface that the three different action classes implement, so you can have the same jsp use the interface type. Note that this makes the three action classes "the same" wrt to that jsp, so I'm basically saying that's the route to go. If you cannot/will not use that then I'd probably use a custom jsp tag to encapsulate the common bits and have separate jsp's for each page call the same common tag.
I am using a MVC framework which is a bit like struts.
So, say I have a "Edit Store" link in my application this is how the url would look like:
http://localhost:9080/test?action=editStore&storeNum=10
Now, action determines my Action (analogous to Struts Action) to be run. The corresponding action here is: EditStoreAction. Clicking this would open a pop up with different attributes of a store for edit.
My question here is:
How do I write my actions? Do I write two actions in this context?
EditStoreAction which will render
edit.jsp
StoreSaveAction which
will invoked when user presses
accept on the rendered response of
edit.jsp.
OR Do I just write one action? EditStoreAction and submit form to the same action, I would know that the user has pressed the accept button for changes on submission. So, I would execute a different flow in the Action, which would save updates to database and redirect to a diff page.
What is the best pratice here? Create as many actions as possible coz it keeps the code modular? OR just write one action to handle everthing in a jsp?
I know this question sounds a bit trivial, however, sometimes you just want to get everything right. Hence, the question. Appreciate your help.
The idea is, similar to Spring MVC, to map your actions to the methods of a specific class, say it controller.
So, in your case, these two actions will be mapped on two different methods of the same class. You can call the class StoreFormController and two methods, editStore() and saveStore().
Better still if you make two controllers for each entity. May be one for all GET requests and another is for POST requests. So, in your case there would be two controllers StoreController for all other requests and StoreFormController for all form submissions, namely post requests. Now, your first action being GET will go to editStore() method of StoreController, whereas the second being POST request will go to saveStore() method of StoreFormController. You can define as many methods as needed in any of these two classes based on the request type.
You can easily see, where I am coming from, if you know Spring MVC API.
I like to use struts DispatchAction class because I could define more than one method in the action class (the "execute") method. Behind the hood, all it does is to find the method that it has to execute (submitted in the form or passed in the URL), find the method using reflection, invoke it with the right set of arguments (the method must have the same signature of the "execute" method), gets it result and pass it along. The DispatchAction simply overrides the "execute" method of the Action class to implement that behavior.
That being said, in your case, I would define only one class - let's say "DispatchStoreAction", and I would define two methods, probably "prepare" and "save". I like doing it that way because I still have a good class abstraction (and you don't put the "action" you're executing in the class name), because your methods can clearly identify what they are supposed to do, and also because, by definition, action classes tend to be small. You will probably have a "StoreLogic" or "StoreBusiness" defined somewhere, and this class will handle the business logic related to the entity that you're working on. I personally think that it's nice if you have one "StoreAction" and then one "StoreLogic", one "UserAction" and one "UserLogic" and so on - the relationship doesn't need to be 1 to 1 but I think it helps maintaining the code.
Check the source code of the DispatchAction class for ideas on how to do this, but the implementation should be trivial.