I have an ASP.NET web app I'm developing but I have a question concerning efficiency. On my page I have Textboxes that have an OnTextChange event that calls a C# page with the function inside. The function works and sums up some values and sends the output back to the page. Now the function is only called if some event triggers a Postback to the server then the calculations are done. I'm wondering if I use both server-side code and some Javascript to do the same calculations would there be a conflict in data when the Postback occurs? For example If I'm submitting the data to a SQL database would there be any sort of issue? Javascript is immediate at doing simple math and would be a better UI for the user to have instant results when punching in some numbers to the textbox, without having to press enter or a submit button.
You shouldn't worry about this. Whatever you do in Javascript will post back correctly to the server. You will not see any kind of "conflicts".
Related
Currently I created a wizard with a listbox. The listbox has a next and previous button. The listbox has thousands of items but the next and previous will show them 30 items at a time.
I am not using AJAX so the page reloads each time the button is being clicked. I don't want the page to reload everytime the user clicks next and previous. I thought of using AJAX.
Is there anyway I can prevent the page from reloading either by AJAX or a different way everytime the user presses next. Pressing next triggers a stored procedure which selects the next 30 items.
C#, SQL, ASP.NET, HTML, JavaScript
You can surely use jquery for this purpose. It will allow you to do an ajax request. In fact, ajax request can be done from a .Net page with even plain javascript and it has nothing to do with .Net version.
However, using jquery will make it easy and you will be able to easily populate the listbox using the results from server.
I have an ASP.NET form that the user can make lots of changes to, each time they make a change the page PostsBack and the details are updated.
If the user hits the browser back button they go back through all the previous versions of the page.
Is it possible to stop each PostBack being treated by the browser as a new page?
So the would make any changes they like and if they hit the back button it brings them to the previous form and not the same form but a different version?
I know I could use AJAX to update values but I'm not an advanced coder so trying to keep things simple as I haven't used AJAX before.
Ajax is your only solution.
There is no way to remove a page from the browser history. Javascript is explicitly denied the capability.
Now, you could, potentially, stop them from using the back button at all. Although this might result in unhappy users and I'm not 100% certain it works in all browsers.
function body_onload(){
window.history.forward(1);
}
You could use a trick to do it.
On postback you can set a session bit to true saying they submitted that form. On your postback check to see if that value is set. If it is they are trying to do it again and you can just abort it. It wouldn't prevent the postback per se but you could control the logic and prevent it from DOING anything.
I personally would explore ajax as Jquery provides some nice ways to do it and it'd be a learning experience but I suppose this would work as you are asking. On a per session basis. If you only want 1 submission ever use a database to store the activity.
You could use UpdatePanel: http://msdn.microsoft.com/en-us/library/bb386454.aspx
I'm building a website in jquery mobile. It is a SOA application and on 'pageshow' event I call the web services get the data and populate labels and dropdown lists with it. However, say for instance, when a user clicks back and the app takes him back to dashboard, the ajax call is made again and the labels are unnecessarily populated again. What I want to ask is, can I prevent this behaviour of populating the same labels with the same data over and over again? Does jquery mobile have this 'viewstate' behavior built in?
Thank you for taking the time to answer my question.
You could use HTML5's localStorage / sessionStorage API to actually persist data between callbacks.
Personally I think that if you'd use JQM's page idiom (having only data-role=page and not loading any new ajax pages), you wouldn't have this problem at all (but rather the opposite, how to reset all fields).
I have a asp.net page with c# code behind. I have a first panel where the user selects and enters information, they then click continue and that data is stored in variable. A new panel displays on screen and the select some new data which when they click continue stores that data in that panel and sends all the information to a c# program. The problem I an getting is that when I click continue the first time and the page refreshing showing only the new panel all the data defaults to 0. How can I fix this?
Thanks
HTML is a connectionless protocol. This means there is no state. There are ways to mimic state with .net, but html has no means of this by default. If you are using webforms, you can utilize viewstate as long as you are posting back to the same page each time. If you are using mvc, you will either have to submit your data via ajax or you will have to send all the initial data you sent to the server back to the view so when you press continue you can populate it all again. Or just use jQuery/javascript to hide(), show() portions of your page, but wait till everything is completed prior to posting to the server.
Good luck
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.