I'm after a bit of advice really. In an C# ASP.NET web solution I need to create a form whereby a user can add names and email addresses (an unlimited amount of times) and when they've finished adding these names and addresses they click a submit button and the 'records' then get posted to an SQL database.
So to summarise I need a wayto hold some data on the page that users can insert to and delete and I was after some advice on the best way to go about this. I did look at listviews and gridviews but they seem to suggest that I need a datasource to connect to and I don't have one the data purely needs to exist for the length of time that they have the form open and will be destroyed either when they submit to the database or cancel out of the form. I'm also presuming that it'll need to exist in an ajax update form as I don't want postbacks when they click to add a name/password.
Any ideas would be gratefully received!
Thanks,
Craig
Related
I have a web page written in ASP.net where it finds a list of employees, displays them in a listview and allow the user to change different statuses for each employee.
On each row I have employee information like name, date of birth, address and then 4 status fields that are displayed as checkboxes and a comment field where the user can type a comment explaining why they changed a certain status.
Currently in Listview, there is an edit, delete button when they click edit, the checkboxes and text field are displayed the user updates them and click save.
asp.net will do a postback to save the changes for this row and then fetches the data again to refresh the list.
The problem I am having is the list is very large (more than 3000 names), so I am using pagination to show 50 to 100 names on each page. This is still a big performance problem because after every line update a query needs to run to fetch those names again, and with ASP.NET the server is generating the html and passing everything to the browser.
The customer wants the page to be mobile friendly too, so I am thinking to redo the page using Angular on front end with web-api or mvc.net on back end that returns JSON.
My question is there an easy way to do this and allow the user to change the status for multiple employees on the same page at once and then click one submit to update all the changes? if I do it this way, there will be less queries to run and it will be faster for the user because they don't have to wait after every line update.
Any examples will be greatly appreciated, unless there is a different way to implement this, in this case please let me know.
I have a thought that may work.
On load render names and use pagination.
Then use ajax to send the post to server and change data in database.
When editing has returned successful then only change the values that have been edited using javascript for the user to view.
I am working with a Telerik Radgrid on an aspx page, which basically has to bind to a datatable, which gets populated by data returned from a web service. I need to be able to fill out some of the columns in the RADGRID based on the data returned by the web service.
For example, I need to be able to build the Hyperlink column based on the parts data returned by the web service. I need a way to access the datasource before the grid item gets populated and direct execution to a routine which builds the URL for the parts on a website.
Can anybody please suggest an efficient way to do this?
I highly appreciate any help/suggestions.
Thanks
Karthik
(Moving my comment to an answer, because I'm thinking this will work out for you.)
You could always cheat and bind it to the grid, allowing you to access the data, but then hide the columns so the users could never get the data.
Let me know how it works out.
EDIT:
My select statement is "select top 5 ProductName from products"
I then created a hyperlink column and assigned the properties under the data tab as such.
When run, it makes the data clickable and when clicked, it navigates to the url seen in the SS.
That what you need?
After data is entered on a web form and then comitted to a database or whatever, what is the best way to clear the contents of the various text box controls and return combo boxes to a non-selected state? I know this can be done from the code behind but is not the best way since it requires a round trip to the server. I know javascript is also an option but I am not very familiar with it at all so is there another option or is Javascript the best way?
Thanks
Note: I'm making an assumption that you are doing a post back to the server in your form to save the data to begin with.
After you've processed the form (i.e. saved the data to the DB) why don't you clear the controls from the page and call "CreateChildControls". This would be the quickest way to clear your input controls before rendering the page back to the user.
YMMV, this isn't necessarily the best or safest way to do this but it can/could work; however I've only used this in custom controls that did not have a corresponding ascx file.
Pls somebody help me with viewsate. Suppose i have created two forms. First form contains First name and Last name and one button called NEXT. And Second form contain two fields and two button like Back and Save. While i am entering some value in form1 pressing one NEXT button and redirecting to second page. There when i am pressing Back button from second page it should come to first page whichever data i filled should exists, but in my case its not showing only empty form i can see when i am pressing on back button.
For this i have used viewstate mechanism. in page directory i have set enableviewstate=true.
postbackurl in both the button. Pls somebody help me what is wrong with me.
Thanks,
Sumit
Viewstate won't carry information from one WebForm to another. It only carries information across postbacks on the same WebForm.
You want to use another method, like SessionState, to carry information from the first page to the second page. Otherwise, you could combine all your inputs on the same page and separate them into multiple steps using something like the ASP.NET Wizard control.
David Lively's suggestions of cookie or database solutions are good, too.
ViewState will help you ship data between views/postbacks of the same page, but isn't really going to help you when moving data between separate pages.
In your first page, populate a cookie or database with your form fields. Any form can then update the cookie, delete it, or what have you.
You can call a javascript function that is doing a "real" back. Maybe I am missing something but this is what I would do.
onClick="history.go(-1)"
When a page is called from some other page it is not a post back, it is viewed as if it is a first time call... When a page is called from the same page then it is termed as a post back... View state or in the sense control values are maintained only during post back, and gets reseted to form values during first time call...
This is the reason behind why you are not seeing the values of the controls.
As others suggested, try using session or cookies and the best option would be Wizard.
I have written an application in ASP.net, that is designed to let the user add records to a database. The page is set up that when a user adds a record, the ID number of the newly added record is set in session, the page Response.Redirects to a "Thank you for submitting" page, then redirects back to the original page to allow further edits. Users can also use the Back button on this screen to go back to the original record adding page, which allows them to make edits to the data.
However, I have found that storing the ID in session isn't a terribly good solution, as a user might try to create two documents in different tabs or windows. I have also tried setting the ID in a literal control, but this causes the problem that when the user uses the Back button, the literal control isn't set to the ID, and new records get added instead of one being edited.
Is there any kind of solution for this?
I'd recommend storing your ID in the QueryString. After the record is added, redirect to your "thankyou" page, which then I am guessing contains a link to the edit form which you will generate with the ID in the querystring. When that link is followed, the edit page shouild pull the ID out of the query string in order to load up the correct record to edit.
Your add and edit form can even be the same page, when an ID is provided in the querystring, your form knows to edit that record, otherwise your form adds a new record.
Silly question, why can the user use the back button to edit the data just accepted in a post?
If the edit previously posted data is a common scenario why not just redirect to a page when the data is accepted that lets them edit it. Then if the hit the back button they would be going back to the original "clean" insert/add new data page.
This would give the following flows
Add->[Post]->Edit->.....
Add->[Post]->Edit->[Back button]->Add->[Post]->Edit->[Post]->Edit....
Have you tried adding the ID in the querystring? Then you could read it, and add it to the session as needed (say on a user clicking the back button).
Seems like a lot of problems allowing editing of an object in a page rendered when using the back button. Would it be too much to give them an edit button instead?
The controls save their state in the ViewState. If you choose to use SessionState instead of ViewState to store the information, then the controls will save their state in the session state and it won't work properly with multiple tabs.
I have not yet found a way to bypass this issue while still using SessionState. Our solution was to use the normal ViewState.
I've tried storing the ID in the querystring (which is mostly fine for editing), but the problem with that is when the information is stored in session for when they use the Back button. If the user does the following:
User creates a record (1st record), the ID is passed along in the querystring, and temporarily stored in session.
User creates another record (2nd record), the ID is passed along in the querystring, temporarily stored in session.
User uses the Back button on the first record to go to the page that doesn't have the querystring.
It's probably a far-fetched scenario, but it's one that may happen. The only solution I have is to block the usage of the Back button to go back to the adding page, by using window.history.forward() in JavaScript. But this as a solution is terrible.
My question for you is why are you storing anything in the session to begin with? If you can avoid storing anything in the session, I think you will be better off altogether.
Having thought about this, does the following sound like a decent solution to the problem I outlined above?
When first adding a record, store a timestamp of when the add page was accessed in a hidden field.
This timestamp is passed through session when the user clicks save. Along with the ID.
If the user opens another tab at the same time and saves, then the new page's timestamp gets passed through session.
If the user tries to access the add page of first record (using the back button), the system looks up session, and sees if there is a timestamp, and whether it matches the one in the hidden field for that page.
If it doesn't match, then the user gets a prompt, and told to edit the record properly.
Does this sound reasonable, or too overly complex?