I have a form that I could put on to one page, but for aesthetic reasons, I want to split into two. The original form, on submission, would go to a Servlet which would get the form data and insert it into a database. However, I don't know how to make this work when it is split into two different forms on two different pages. My forms are currently in html but I could change them to JSP if that is the solution. I do not want to use hidden fields; if there is no way to do it without hidden fields, then I will just put it on one page as my form has quite a few fields and hidden fields would mean basically doubling the amount of code. I also only want to use html or jsp for the forms; I don't want to use JavaBeans, and I want to avoid scripting in the jsp's. I have already done this by simply dividing the database logic into two and using the ID of the last inserted object as a hidden field, and the second form then uses that ID to update that item, but this is not an elegant solution and could cause a problem if one user submitted the first form and a different user submitted the second (the wrong item would be updated). Is this possible?
Well, this is one of the things the Session can be used for: store the data from the first page in the HttpSession and then in the second page retrieve the session data and save it to the database.
You can use javascript pagination (It'll save page loading time. Many online test applications adopt this approach)
a) Either on submission on each part of form data will send to server using ajax call.(partial submission)
b) Or the whole data will be maintained at client side only until whole form is completed and submitted successfully.
(depends on your application need)
You can logically relate each part of form with some unique id & session id combination. In addition, if you are not willing/required to store whole form data in session, you can have primary key in session. It'll make database update process easier for 2nd or next part of form data.
Related
I have a jsp page having many sections/categories to fill hardware configuration details and each section/category has many details to be filled in either by selecting a value in a list box or entering data in a text box. The user may fill in some fields of some section and can choose to fill other sections later. When user logs in next time to fill data, he must be shown the previously filled in data for respective sections/categories. The current design is, when user is entering any data and goes to next field, an ajax call is made to persist the entered data in DB. So if there are 10 fields in a section and if there are 10 sections in the form, 100 JDBC calls are made and if user wants to edit already entered field, additional JDBC calls are being made. Also the 10 fields in a section are dependent on each other, for example if the first field is “Operating System Name” and if I select as “Windows” then the next field “OS Version” should only show values “2000,2007 2008 etc” and the next field “OS Architecture” should only show relevant values for Windows and its Version. This was the main reason why a JDBC call is made each time when user enters a value in a field
Need your advice on this design to make minimal JDBC calls and the current design more efficient. Thanks
You could take a look at the J2EE ContextObject pattern. It'll allow you to encapsulate the state of user's configuration, and to share it throughout your application. Also the ValueListHandler will help you handle those expensive objects via caching the results, and allow the client to traverse and select items from the results.
Are there patterns for implementing a single user per page model in a J2EE environment?
By single user per page I mean, if I access:
mysite.com/foo/pageA
If someone else tries to access this page, they should not be able to until I:
-navigate away from the page
-close the browser
As it stands now, I have implemented this feature using a map that is a member variable in the servlet that handles requests for foo/*. The keys for the map are page names (enum), and the values for the maps are a boolean value that represents whether or not that particular page is locked.
Before the page is served, I look at the map value to determine if the page is occuiped, and if it is not, I send the user to the page and update the map entry (synchronizing on the map), if it is , I send the user to a page displaying the message that the page is occupied.
To implement the locking, I use the onbeforeunload javascript method, in which I use an ajax post call to update the map entry to false, again, synchronizing on the map.
I know that if the application expands to more than one instance, the locking/unlocking will have to be persisted, but as it stands now, the application only serves about 10 users.
It seems to be working, but I was wondering if there were established patterns for accomplishing this, or if the idea of locking a page to only allow a single user is bad practice in a web application.
I have an action say actionA associated with a JSP page say A.jsp and another actionB associated with B.jsp. There's a form on A.jsp. User submits some data which is set in actionA properties. Now user navigates to B.jsp (or any other page for that matter) and then comes back again to A.jsp. The form data in the fields of A.jsp is lost when the user comes back. I want to retain that data.
I cannot use hidden fields since I have a lot of fields and cannot use sessions either. Is there a way in Struts2? If not can you suggest me any other way?
When you want to send data from a pagexto another, as you're working on a http protocol you have two ways, use parameters (hidden fields in post submit or url parameters in get) or you have to use session.
If you can't do neither, think about saving your A state on a database and pass only a key that let you retrieve the A state when you are back.
Sorry for the generic answer but it's all I can say if you don't give more details.
I am working in Spring MVC 2, Jsp, Dojo, Javascript.
Actually I am populating Jsp page table-grid with list of objects coming in form command object. Let say 3 records displayed in grid. I am deleting third record with JavaScript getElementById.. delete-row/removeChild functions. That record is deleted from presentation i.e. grid. Now when I save this. It takes 3 records to server side instead of 2. It should take 2 records because the third record was deleted. I am using Dojo to dragNdrop grid rows.
If you're using a grid component that maintains a datastore - e.g. the DojoX DataGrid, you might be removing the markup for the row, but not telling the datastore to purge the row data. When the save occurs, the datastore sends all three rows.
If you are using the DataGrid, you should delete the row from the DataStore, which will be reflected automatically in the UI.
When I have this kind of issue, I always check the cache related headers in my response.
Could it be that the http request supposed to fetch saved data from the server in order to refresh the view doesn't hit the server, but instead hit the browser cache?
Could not resolve issue but another logic fulfills my need. Spring form tags were used to bind this for with objectclass. Converting deleted item row's id to negative and hiding this row at client side does the trick. When form submits this negative id converted to positive value and deleted from DB.
I have a form that is submitting to a servlet and processed with the doPost() method. Once the form is submitted, the user is taken to another page with a "Back" button (not the browser's back button). If the Back button is clicked, the form should repopulate with the original input. How can I accomplish this?
It is your responsibility to keep the information and repopulate the form manually. You can do this in one of two ways:
Either you push the content to
the client and read it back in when
necessary.
Or you can save the
form data for that client in the
server space.
I prefer the later by creating a model which represents the form data. When the form is processed, you can save a copy for that client. If the page is reloaded, you can check for the existence of a previous model. If it exists you use that data to populate your form. If it does not exist, you can use a default model or empty values.
There are other advantages of gathering your content into a model which will benefit you later on. For example, if one makes changes to a form and you have an 'Undo' button near the 'Submit' and 'Clear' buttons, you can easily revert to the last known state. In order to active the 'Undo' button you can easily do:
boolean isDirty = savedModel.equals(currentModel);
And enable/disable the 'Undo' button using the boolean rather than having tons of 'if/else' statements to see if a value was changed. Much cleaner.
Jeach!
If you use javascript:history.back() your browser should automatically take care of that for you.
You'll have to keep up with the data the user submitted in the form.
You could put that data on the in a url, on the request or in the session.
Make sure you escape any unsafe characters when putting them back into the form.
There are a lot of web frameworks out there that make this sort of thing easier to do.
Struts and Stripes are two that come to mind.
After original form is submitted you have several server-side options:
keep form values in session and populate them with the form called from 'Back' action;
add form values as parameters to 'Back' action url so they will be part of the request.
If the user submits the form, is the data put into a database? If so, simply query the database and repopulate the form... If not, consider saving the data to a database.