want develop Wizard based app:
Have some steps, collect info from all steps, and handle on final step.
How forward data from start to end?
Now I see two variants:
* Use TempData. but it good Idea if TempData use Seesion. can have problems with multiple instances of wizard on same session.
* provide accamulated data from previous steps to next step View. But this way additional responsibility to View - it must forward all data to next step.
You need to handle the two separate scenarios separately.
#1 While handling a single web request, your controller will run, and then your selected view will run. Data can go from controller to view in ViewData and in TempData, or any of the mechanisms in #2 (but this would be odd).
#2 Data that needs to cross from one response to the next request. Here you can use the client (hidden form fields (look how ViewData is sent to the client in a web forms app), form fields, cookies), or held on the server: session, application or some persistent
store.
Each option has different trade offs, and many many pages have been written about them. E.g. by default a session will not survive a server restart (including process cycling) or use of a server farm, but can be configured (at some incremental performance
overhead) to handle these cases.
The simplest, until you understand requirements in detail would be either hidden form fields (with some integrity verification) or use the web app's session (I would likely go for the latter as the easiest).
I clearly understand this options, but each one trade offs as you say.
#1 Hidden Fields add UnWanted responsibility to View. View Must Know about own data to display, and about all data, that need be forwarded to next Action
#2 Server Strorages has additional effort to manage - expire, handle AppRestart, allow multiple entries for each user. In Any case it need provide KEY to View and View must Forward it to next step with promlems from #1
I want know, does TEAM have plans to do something like ControllerState.
deFacto now we have stateless, actionBased Controller. In some cases it is OK. but sometimes Controller state can do life easier.
#1 Hidden Fields add UnWanted responsibility to View. View Must Know about own data to display, and about all data, that need be forwarded to next Action
Controller passed serialised object (as base64) to views which blindly populate hidden field. Using the same field name on every view means every controller can read this. (And could be largely done once with common controller and view base classes).
mogadanez
#2 Server Strorages has additional effort to manage - expire, handle AppRestart, allow multiple entries for each user. In Any case it need provide KEY to View and View must Forward it to next step with promlems from #1
Sessions already handle expiry.
For resart the established options also cover the web farm case.
Multiple entries per user... either rely on separate sessions (just takes one user to open in new tab), or put a key as per option #1. I suspect any ControllerState will just be doing either #1 or using session...
Something like this is not free, you are going to have to do some work. But, given the building blocks not much.
mogadanez
Member
73 Points
49 Posts
how handle internal controller state between steps
Jan 14, 2008 08:55 PM|LINK
want develop Wizard based app:
Have some steps, collect info from all steps, and handle on final step.
How forward data from start to end?
Now I see two variants:
* Use TempData. but it good Idea if TempData use Seesion. can have problems with multiple instances of wizard on same session.
* provide accamulated data from previous steps to next step View. But this way additional responsibility to View - it must forward all data to next step.
rjcox
Contributor
7064 Points
1444 Posts
Re: how handle internal controller state between steps
Jan 15, 2008 09:00 AM|LINK
You need to handle the two separate scenarios separately.
#1 While handling a single web request, your controller will run, and then your selected view will run. Data can go from controller to view in ViewData and in TempData, or any of the mechanisms in #2 (but this would be odd).
#2 Data that needs to cross from one response to the next request. Here you can use the client (hidden form fields (look how ViewData is sent to the client in a web forms app), form fields, cookies), or held on the server: session, application or some persistent store.
Each option has different trade offs, and many many pages have been written about them. E.g. by default a session will not survive a server restart (including process cycling) or use of a server farm, but can be configured (at some incremental performance overhead) to handle these cases.
The simplest, until you understand requirements in detail would be either hidden form fields (with some integrity verification) or use the web app's session (I would likely go for the latter as the easiest).
mogadanez
Member
73 Points
49 Posts
Re: how handle internal controller state between steps
Jan 15, 2008 10:08 AM|LINK
I clearly understand this options, but each one trade offs as you say.
#1 Hidden Fields add UnWanted responsibility to View. View Must Know about own data to display, and about all data, that need be forwarded to next Action
#2 Server Strorages has additional effort to manage - expire, handle AppRestart, allow multiple entries for each user. In Any case it need provide KEY to View and View must Forward it to next step with promlems from #1
I want know, does TEAM have plans to do something like ControllerState.
deFacto now we have stateless, actionBased Controller. In some cases it is OK. but sometimes Controller state can do life easier.
rjcox
Contributor
7064 Points
1444 Posts
Re: how handle internal controller state between steps
Jan 15, 2008 12:42 PM|LINK
Controller passed serialised object (as base64) to views which blindly populate hidden field. Using the same field name on every view means every controller can read this. (And could be largely done once with common controller and view base classes).
Sessions already handle expiry.
For resart the established options also cover the web farm case.
Multiple entries per user... either rely on separate sessions (just takes one user to open in new tab), or put a key as per option #1. I suspect any ControllerState will just be doing either #1 or using session...
Something like this is not free, you are going to have to do some work. But, given the building blocks not much.