I have a struts2 form.
In this form the user is asked to fill several fields.
2 of those fields are filled by picking an object from another action.
In fact :
main form => pickup button => new action with a new form to fill => return to the main form and filling the corresponding field.
My problem is that after the user finished the subaction, I want to return to the main form but not lose everything he filled before ...
I don't know how to handle this, should I pass to the subaction every field from the main form ?
Several ways come to mind, depending on factors will determine the best one for you.
1) Send out all the parameters you want to keep each time. Easiest way to do this is use hidden fields. Model driven may also make sense here or placing several actions into one class, either way it highlights that those actions share a common set of properties.
2) Store the value in the session like Vasily recommended however Struts2 has the scope interceptor... If you need to do this often it is worth looking at (see last example on page): http://struts.apache.org/2.3.1.2/docs/scope-interceptor.html however to do this right is a little tricky, because if this is an office application and the users are anything like me they we'll have a dozen windows open at any given time. In this situation you'll want to consider also adding a token (see: struts2 token tag) to to each "flow" which will prevent one of a dozen windows when doing a refresh to pick up the latest data from what I would expect rather than, get polluted from some global store that all actions use. There are some other ways to handle flows/conversations... for instance someone wrote a plugin which I suppose would implement what was just explained: http://code.google.com/p/struts2-conversation/
It's always worth a quick look over the struts2 plugins to make sure you aren't reinventing the wheel, although I must say I can't vouch for that plugin.
3) Don't have them leave the page at all. This is very slick... If you need to select additional parameters, when they click on the "pickup" button have the form expand with the required fields then when they click "update" in this subsection, it is close and update the rest of the fields. You will need a combination of JS on the client side with generally an XML or JSON response. For your own pages JSON is the easier way to go, to produce JSON responses see the struts2-json-plugin.
I would go with #3 in most cases. Possibly #1 if I knew the action would only be used from the calling action and/or I wanted a very bookmark safe form(pass all parameters if possible with GET). #2 in more complicated scenarios where multiple actions needed to collaborate and I could not use ajax for some strange reason. Note #3 and #2 are not very book mark friendly, and they are in general not very state friendly without using client side storage.
Store your mainform in session.
public class Test extends ActionSupport implements Preparable {
private MainForm form;
public void prepare(){
form = (MainForm)ServletActionContext.getRequest().getSession().getAttribute("mainForm");
if(form == null) {
form = new MainForm();
}
}
public String execute(){
//Do something useful
//Do something useful
//Do something useful
return SUCCESS;
}
public MainForm getForm() {
return form;
}
public void setForm(MainForm form) {
this.form = form;
}
"prepare" method is a part of Preparable interfeice. It will be executed before all parameters readings and before "execute" method every time when your call the acton.
You need the following to have a working struts2 platform:
2 struts form classes with fields
A struts action class
A jsp page
A struts config file
Then go through the below process:
When the first form is loaded save its bean in the second form
through a field
After you return from the first form load its fields in the second
form through the above field
Related
I have a form in wicket which has two buttons. I would like one to have validation over the fields (if they are left null or not) which I already did. Now I would like the second button NOT to have this validation. I have seen few examples where people use the method setDefaultFormProcessing() which is a method of class Button in wicket.
However when I use this method my form seems to also ignore changes done in the fields of the form.
Any idea how I actually can achive bypassing the validation but still be able to see changes in my form??
Thanks!!
This is the defined behavoir. If data is not valid it is not possible update model anyway. Consider an example when you have a date field and you type there '99/9/YYYYY' that is not a valid date, thus wicket has no chance just to bypass validation and update model. The only chance is to keep input data as String and give you an option, how to convert or update model by your own implementation.
If you have a reference to your form components, you could invoke updateModel().
See http://apache-wicket.1842946.n4.nabble.com/Turn-off-form-validation-td1877661.html
And check API doc for FormComponent that is a base class of all fields and other form components. https://ci.apache.org/projects/wicket/apidocs/7.x/org/apache/wicket/markup/html/form/FormComponent.html
I have a struts action flow(struts-1.x framework), which, when executes, the action class ActionFlowActionUnit1.java sets a String variable varName to request using the code
request.setAttribute("varNameFromRequest", varName);
and the flow finally leads to the loading of a jsp Page1.jsp.
Now, Page1.jsp contains a button, which, when clicked, initiates a new struts action flow, which has the action class ActionFlowActionUnit2.java. In this class, I want to use the varName which I had set in request using request.getAttribute().
How can I do it WITHOUT USING SESSION?
Technically, I'm not sure if achieving this using requestis possible, because, triggering a new struts-action will lose all other information in the request that was previously set (if I'm correct).
I couldn't get anything from Google.
As you say, it is not feasible technically as you want it (every http request from the browser creates a new HttpServletRequest object)
You have 2 options:
Using the Session, which you want to avoid as far as I understand
Bring back and forth some parameter into every successive request with the value you would like to keep.
The second option would mean to store some parameter inside your Page1.jsp <form> with the variable you need your second action to receive, and then rinse and repeat. This is a pure html form solution.
If you are implementing a complex flow, this looks a fair case to have a look at Spring Webflow. There you can manage flow-level variables, which are stored at a "different" scope than request or session, and looks exactly what you want.
http://projects.spring.io/spring-webflow/
We are trying to build a GUI framework using GWT. We are finding it hard to implement the cancel functionality in the framework.
Required feature is this:
We have CRUD screens which have pop-ups, grids and so on. When the user changes anything in the GUI and then clicks on cancel() he should be given a notification message saying that something has changed.
Approach that we have tried:
Currently we are trying to keep a hashmap of key vs value of the entire pojo object and trying to compare it against the model which gets updated as and when user changes something. But this is adding lot of unwanted code in every pojo and not working as expected when user adds data directly from the backend.
Is there any elegant way in achieving this functionality? Kindly note that *we are not using Editor framework of GWT *(https://developers.google.com/web-toolkit/doc/latest/DevGuideUiEditors) in our application.
Example:
Suppose I have a pojo like this:
public class Person {
List<Address> address;
PhoneNumber phoneData;
// and so on along with getters and setters
}
How will I write a generic clone method for this? And even if I manage to do that somehow that will lead to lot of code in every pojo (our application has hundreds of them) which doesn't seem right.
Please note that, our pojo gets updated as soon as something is changed in GUI to achieve live binding.
So you have "Save" and "Cancel" buttons in your form?
I would recommend you to change the concept. Update your object properties immediately as user edit them (as in GMail, JIRA and many other modern applications) in an OnChange event handler.
Save all updates to the session stack as UpdateAction objects and let the user undo every single property modification calling UpdateAction.undo() method.
The benefits are:
this design is much more user friendly than "Click "Edit" - update - click "Save"" scenario.
You don't need separate view/edit forms/popup dialogs - just a single form for both viewing and editing.
I have a hard time to get used to the WebDriver PageObject pattern. Please share your experience and ways of using PageObjects pattern and loadableComponents.
As PageObject represents usually a component or piece of functionality, it occurred to me at first that I should use it to actually do some things in load() and see if it does what it should in isLoaded().
Then I realized that it should be utilized only for "loading" objects (possibly initialization) as it is in case of moving around a website, each object with its own url. And using isLoaded() to test whether the object IS READY for testing.
But if you have a complex JavaScript order submitter to test, that is compound of JS file uploader, JS form that is based on 2 independent parts and there are three kinds of Orders, you don't move anywhere (regarding URL), just the state of elements is changing.
Consider the get() method. You get into the page with the interactive Form. It is loaded when the form exist on the page. Then you have form1 and form2 objects ... what should their load() and isLoaded() method look like, they are ready for action right away because they don't need any loading, just testing their services.
It's a mess, one doesn't know if the isLoaded() method is used for checking whether object loaded, or whether object loaded and was setup properly. But I guess the former way is correct and that validity of setting it up should be ensured within the tests.
Scenario:
Testing first part of html form - test that field client side validation works
Testing the second one that depends on the first one
Testing the following file uploader - upload, canceling, clearing, order, fileIDs
Testing the overall html form submission - ServerSide validation errors, results
The documentation says :
LoadableComponent
PageObjects
The public methods represent the services that the page offers
Validate, upload, upload Multiple, cancel, clear
Try not to expose the internals of the page
The only thing that occurs to me is having Driver instance hidden to UnitTests and use Only PageObjects to keep all field names, css class names in PageObjects + supply PageObjects with input data and assert boolean result of the services/functionality
Methods return other PageObjects
This is the most difficult thing to get used to. Having 4 page objects for one interactive form kinda doesn't feel natural. They recommend Form1, Form2(Form1), Upload(Form2), Submit(Upload), although I find the chaining and handing over a reference to the preceding object very chaotic. Calling get() on all of them in a test method seems better. But I guess that the idea behind it is not to expose the Driver instance to the Tests, but use only PageObjects that are using Driver instance internally
Different results for the same action are modelled as different methods
I suppose that this means that it shouldn't be decided about validity of that action on the Page object side, but on the Test side
I have a bit different approach when writing page objects. Translated to your terms load() method ends with conditional wait ensuring the page contains what you desire. Then I do not need any isLoaded() - either I'm there or Exception is thrown.
Components in page are properties of the page containing them and I set two-way relationship between a component and the page. They are not fully functional page objects. Maybe your forms can be modeled this way too.
The loadable component is an extension to the Page Object pattern. The LoadableComponent class in the WebDriver library will help test case developers make sure that the page or a component of teh page is loaded successfully. It tremendously reduces the efforts to debug your test cases. The page object should extend this Loadable Component abstract class and as a result, it is bound to provide implementation for the following two methods:
protected abstract void load()
protected abstract void isLoaded() throws java.lang.Error
The page or component that has to be loaded in the load() and isLoaded() methods determines whether or not the page is fully loaded. If it is not fully loaded, it throws an error.
https://code.google.com/p/selenium/wiki/LoadableComponent
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.