I'm using kendo for my client side framework using MVVM single page application architecture for a multi page MVC app that I'm currently working on. What happens is there are 4 pages/steps in total in which the first 3 steps requires users to enter in some information and hitting the next button and using kendos router function to route to the specific page on button "Next" press.
Each pages values depends on the previous page, so in page 1 user would enter in some user ID's, on next button click it will call an AJAX call to my controller method passing in a viewmodel from the view and then returning some values based on those ID's and load them on page 2.
Because the values are loaded based on a kendo observable viewmodel from the view on page 1, if the user was to refresh on page 2, the values would all become null since the refresh would basically wipe out all the values saved in the viewmodel or if the user presses the "Previous" button or the back button on the browser whatever values they entered on page 1 would also be empty instead of displaying the previous values they've entered.
Main question would be is this the right architecture for what I'm doing? Should I just be doing standard MVC and passing my viewmodels/populating my screens from the server side so my values would never be null but on refresh it would just always hit the server side code.
If a single page application architecture is fine for such an application what would be some solutions for this problem?
Thanks
I'm working with the 10.2 version of the DevExpress MVC controls. I have a page hosting a MVCxGridView and I need to preserve the current page when navigating away and back to this particular page.
I can see from the old ASPxGridView documentation that there's a PageIndex property, but this seems to only be accessible from a WebForms/Code Behind/Server Control type context. I'm using MVC and can't figure out how to preserve this page setting.
I've tried the cookie settings with the control but those don't seem to persist for me.
Any pointers would be greatly appreciated.
Currently the MVC grid doesnt support SEOFriendly, or at least I cant find anything on it. You might be able to support it yourself using JQuery and perhaps a paging template which redirects the user to the same page adding a paging parameter like ?paging=2. So basically you check if the url has a paging parameter and if so you can tell the grid to GotoPage(paramValue) telling it in this case to start at page 2.
You could get the gridview's page number in the body unload event and then save that value in a cookie. Next time back at the page, in the gridview's init event read the cookie value and set the grid view's page numbe.
I am researching web frameworks that are in common usage. In ASP.NET there is the notion of a "postback". Specifically, the framework automatically adds a hidden FORM to each page which can be submitted by JavaScript with various state parameters, etc. The "action" URL for this form is always the current page's URL, including its query-string parameters.
I am trying to find other frameworks that have this behavior, i.e. that automatically alter the page's HTML and add forms (or links) to the current page in some form.
If anyone can point me to frameworks that do this, preferably with a reference to a doc or an example, I would appreciate it!
Oracle Application Express, http://apex.oracle.com/
Generates a FORM element that contains all items on the page, and handles state for these items when the form is submitted.
I'm trying to use the jquery UI dialog component to display a form; which I successfully did.
However I'm at lost on how to retrieve data to this form inside the dialog window. Is it possible? The example shown on jquery website only shows static messages.
Maybe you can tell us more about the problem. What data do you want do display and in which format is this data (is it form data, javascript objects, dom objects, etc.?)
You talked about a form which is shown via a dialog. Where do you want to access this form data (when the dialog is closed, opened, when the form is submitted, ...)?
I'm making my way into web development and have seen the word postback thrown around. Coming from a non-web based background, what does a new web developer have to know about postbacks? (i.e. what are they and when do they arise?)
Any more information you'd like to share to help a newbie in the web world be aware of postbacks would be most greatly appreciated.
The following is aimed at beginners to ASP.Net...
When does it happen?
A postback originates from the client browser. Usually one of the controls on the page will be manipulated by the user (a button clicked or dropdown changed, etc), and this control will initiate a postback. The state of this control, plus all other controls on the page,(known as the View State) is Posted Back to the web server.
What happens?
Most commonly the postback causes the web server to create an instance of the code behind class of the page that initiated the postback. This page object is then executed within the normal page lifecycle with a slight difference (see below). If you do not redirect the user specifically to another page somewhere during the page lifecycle, the final result of the postback will be the same page displayed to the user again, and then another postback could happen, and so on.
Why does it happen?
The web application is running on the web server. In order to process the user’s response, cause the application state to change, or move to a different page, you need to get some code to execute on the web server. The only way to achieve this is to collect up all the information that the user is currently working on and send it all back to the server.
Some things for a beginner to note are...
The state of the controls on the posting back page are available within the context. This will allow you to manipulate the page controls or redirect to another page based on the information there.
Controls on a web form have events, and therefore event handlers, just like any other controls. The initialisation part of the page lifecycle will execute before the event handler of the control that caused the post back. Therefore the code in the page’s Init and Load event handler will execute before the code in the event handler for the button that the user clicked.
The value of the “Page.IsPostBack” property will be set to “true” when the page is executing after a postback, and “false” otherwise.
Technologies like Ajax and MVC have changed the way postbacks work.
From wikipedia:
A Postback is an action taken by an
interactive webpage, when the entire
page and its contents are sent to the
server for processing some information
and then, the server posts the same
page back to the browser.
Expanding on the definitions given, the most important thing you need to know as a web-developer is that NO STATE IS SAVED between postbacks. There are ways to retain state, such as the Session or Viewstate collections in ASP.NET, but as a rule of thumb write your programs where you can recreate your state on every postback.
This is probably the biggest difference between desktop and web-based application programming, and took me months to learn to the point where I was instinctively writing this way.
Postback happens when a webpage posts its data back to the same script/dll/whatever that generated the page in the first place.
Example in C# (asp.net)
...
if (!IsPostback)
// generate form
else
process submitted data;
Web developement generally involves html pages that hold forms (<form> tags). Forms post to URLs. You can set a given form to post to any url you want to. A postback is when a form posts back to it's own page/url.
The term has special significance for ASP.Net WebForms developers, because it is the primary mechanism driving a lot of the behavior for a page — specifically 'event handling'. ASP.Net WebForms pages have exactly one server form which nearly always posts back to itself, and these postbacks trigger execution on the server of something called the Page Lifecycle.
The term is also used in web application development when interacting with 3rd party web-service APIs
Many APIs require both an interactive and non-interactive integration. Typically the interactive part is done using redirects (site 1 redirects a user to site 2, where they sign in, and are redirected back). The non-interactive part is done using a 'postback', or an HTTP POST from site 2's servers to site 1's servers.
When a script generates an html form and that form's action http POSTs back to the same form.
Postback is essentially when a form is submitted to the same page or script (.php .asp etc) as you are currently on to proccesses the data rather than sending you to a new page.
An example could be a page on a forum (viewpage.php), where you submit a comment and it is submitted to the same page (viewpage.php) and you would then see it with the new content added.
See: http://en.wikipedia.org/wiki/Postback
Postback refers to HTML forms. An HTML form has 2 methods: GET and POST. These methods determine how data is sent from the client via the form, to the server. A Postback is the action of POSTing back to the submitting page. In essence, it forms a complete circuit from the client, to the server, and back again.
A post back is anything that cause the page from the client's web browser to be pushed back to the server.
There's alot of info out there, search google for postbacks.
Most of the time, any ASP control will cause a post back (button/link click) but some don't unless you tell them to (checkbox/combobox)
Yet the question is answered accurately above, but just want to share my knowledge .
Postback is basically a property that we can use while doing some tasks that need us to manage the state of the page, that is either we have fired some event for e.g. a button click or if we have refreshed our page.
When our page loads for the very first time , that is if we have refreshed our page, at that time postback-property is false, and after that it becomes true.
if(!ispostback)
{
// do some task here
}
else
{
//do another task here
}
http://happycodng.blogspot.in/2013/09/concept-of-postback-in.html