I have 2 views in my SPA built up using durandal. I have a form (consider basic employee information form) in the first view. Also, I am having a button in the view called "upload" which routes to a different view to upload some documents. Once user finishes uploading, it redirects back to my first view and when it does, the first view reloads (renders) again loosing all my previously entered values. Same is the case when I press browser back button on my second view (the upload page).
Any solution on how I can persist data in this case ?
Thanks.
Posting code would make it a bit easier but I would think you'd need to maybe store what's entered in LocalStorage or something and then retrieve it later?
AmplifyJS can make this easier.
Related
I have a Layout page which sets up the list of Projects in the application using Telerik's ComboBox as shown. The combobox allows user to select a project he/she wants to work on.
Once a selection is made, I want all subsequent actions in the application should correspond to the selected Project. I can preserve the Project information in a Session but then if user chooses to open this in a new tab and in 2nd tab users switches to a different Project and comes back to the first tab and refreshes the page then the session information (Project) would have changed which will create issues in my application.
So, what is the best way for me to persist Project information of the Layout.cshtml controls so that I can use it in my application such that every page that is rendered uses the currently/correctly selected values.
Tempdata / QueryStrings came to my mind but i don't know whether they will be reasonable solution to my problem. If yes, then how should I use them generically (specially querystrings) without complicating my solution?
localStroage and sessionStorage also seems like relevant solutions but then how do I use them in scenario where user opens a new tab from existing page? How will the Project # will persist on the newly opened page/window/tab?
something like this is achievable, if you make sure the url changes when a selection is made.
So let's say you select project C-1379 in your dropdown box, at that point your url could become http://localhost:58692/pid=C-1379.
from now onwards, your page can load the desired data, retrieving its required information from the query string. Do not use session or localstorage or anything like that as it won't work.
This way, you can still load your list of projects in your layout page, and you can select one based on the query string value and then load some default values via api calls to the back end.
If all your work from now on is done based on api calls, for example, you have some properties that you change and then you issue a POST to update said details then this is very easily done as well.
telerik controls usually have some events associated with them. the one you are using should have an onChange or something like that. This where where you would update the query string with the value of the project selected and then you can proceed to do what you need
I can preserve the Project information in a Session but then if user
chooses to open this in a new tab and in 2nd tab users switches to a
different Project and comes back to the first tab and refreshes the
page then the session information (Project) would have changed which
will create issues in my application.
I would have thought this is the desired behavior... take stackoverflow.com as an example, if I change my username in one browser-tab, I would expect my username to be updated in other browser-tabs as well... and that's what happens if I refresh my other tab.
There is no built in solution for maintaining user info in different browser tabs separately... the only way to achieve this, is by sending project name back and forth in the URL... but then you would loose this info if user changes the URL... In my opinion, this is an ad hoc solution and does not worth the effort of development, because it's a very uncommon scenario.
Getting to your options:
Storing user info is a very typical use case for session variable.
TempData is stored in Session by default. Though you can write
your own custom TempDataProvider and store it somewhere else (e.g.
database, cookie, etc). See Brok Allen's Cookie TempDataProvider
as an example. One advantage of using Cookie is that you send your
session variable back and forth with the request so you don't need to
worry about Sticky Sessions.
You can of course use a permanent storage, such as DB/Disk.
If the project name is not a sensitive info then I don't see any issue in passing it in Query String.
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.
There is some generated contents with the links on an ASP.NET page, which is created after the user inputs values and hits a button. The links take the user to another page.
When the user hits the Back button, the generated content is gone as the page returns to its initial state with the inputs cleared and generated content not there.
Is it possible to preserve the state of the page after its content has been generated and restore it after the Back button was clicked?
I think you can you can you temporary cookies.
and on load check whether cookie is exists or not.
Save the inputs in the session, so that the page will know how to correctly render on later requests. Even better, have the first code that runs when the data is submitted redirect to new page with a URL parameter that you use to know which links to show. This is a called a POST-REDIRECT-GET pattern.
I'm trying to describe it in as few steps as possible:
I have Page1.aspx with lot of controls, and Preview and Save button among those. I also have Page2.aspx that is the redirection target of a Preview Button click.
Since I need all the controls selections from Page1 to draw a preview on Page2 the redirection is done with setting Preview's PostBackUrl.
I also must have preview shown on a new tab or window so I used onClientClick="aspnetForm.target='_blank'" for Preview button definition.
Save button-click callback, after storing data to a database does redirection to some Page0.aspx (initial list of reports - the subject of the code)
Preview button works fine - a preview renders in a new tab, but when I go to the old tab and click on Save, I see from debugger, that firstly Page2.aspx(?) and secondly Page1.aspx are loaded. Then all the data is stored in the db, but though Page0 redirection is executed Page1.aspx stays loaded in the browser.
I have no idea what processes are behind this. Could one who knows give me an insight? Or if you consider my approach impossible to implement give some idea how to do the same?
If it's of importance, everything on the Page1 is located in an update panel.
Thank you very much for replying
In ASP.NET there are basically zero (0) circumstances in which you will ever send form data from one page to another. Although what exactly you are trying to accomplish is vague, you can consider some of the following:
Isolate unique operations/systems to a single page. If you have something like a User Profile, don't have three different aspx pages; just use a single page for the user or admin to manage that data / functions. Postback events are your friend.
Understand the difference between ViewState and traditional form data. I'm guessing that if you're trying to post form data from one page to another, you probably don't understand the point of ViewState. Using a single page to maintain temporary data that the user is currently working with is a great use for ViewState. If you want the data to appear on another page then you need to consider the data from the previous page as final and thus should be saved to a database or some other medium.
These are just some general guidelines because there is no exact answer to your problem without saying something generic like "You're doing it wrong." I would recommend starting by never again trying to post form data from one aspx page to another.
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?