Programming Preferences
-
If you have to move to web page 2 on a button click on page one, and page 2 totally depends on data input by user on page one, what approach would you choose to share data between the pages? Would it be session or cross-post or something else? Any why?
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
That depends. Do you need to run any logic from page 1 before you move to page 2? If not, just use
<form action="page2.ext">- you'll save the user a round-trip to the server.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
OriginalGriff wrote:
the "break in a loop is bad" faction
They are just afraid of Ivan Drago. Though, FYI, it's usually called a "ring", not a "loop".
They can leave my ring well alone! :laugh:
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
I always use Sessions (unless I'm trying to pass a huge object and then I'll just pass a reference to it instead).
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
mark merrens wrote:
unless I'm trying to pass a huge object
Perhaps more fiber in your diet would help
-
Session or cookies, depending on how non-volatile I wanted the data. I generally try to make data last as long as the user is probably going to need it - except security info, which never leaves the server so is session limited at best.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
Keep in mind as well, for storing things in the session, you should not store objects that are not agile. (Agile objects being defined as... objects which do not maintain a reference to system resources, DB connections, open file handles, etc.). Session is also server dependant, if you use session to store objects, your server balancing must be a sticky balancing paradigm where once you hit a particular server, you remain with that server for the duration of the session.
-
mark merrens wrote:
unless I'm trying to pass a huge object
Perhaps more fiber in your diet would help
Thanks: I thought that was lost on everyone.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
Keep in mind as well, for storing things in the session, you should not store objects that are not agile. (Agile objects being defined as... objects which do not maintain a reference to system resources, DB connections, open file handles, etc.). Session is also server dependant, if you use session to store objects, your server balancing must be a sticky balancing paradigm where once you hit a particular server, you remain with that server for the duration of the session.
+1 And, of course, make sure that objects are serializable (like proper DTOs), so "the next guy" (which is yours truly) doesn't want to come after you wielding an axe because stuffing ListItemCollections and GridViewRows into Session makes the StateServer unhappy . :mad:
-
Session or cookies, depending on how non-volatile I wanted the data. I generally try to make data last as long as the user is probably going to need it - except security info, which never leaves the server so is session limited at best.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
My previous employer banned session variables. They projected millions of users and didn't want all that memory floating around for 20 minutes before being released in the case the user was just there for a second. Their other argument was that they were going to a server farm and didn't want to keep the sessions coordinated. The place I'm at now does not have that much traffic so Sessions are fine with us. Our problem is sessions timing out and the users complaining they lost their work will they were yakking on the phone. We use cookies as well, but not as much. Some of our users are still terrified of cookies and disable them. In worst cases we stash the data in a database record and pull it back later. Not a good solution either.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
If you have to move to web page 2 on a button click on page one, and page 2 totally depends on data input by user on page one, what approach would you choose to share data between the pages? Would it be session or cross-post or something else? Any why?
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
Actually, I normally prefer to use ViewState and stay on the same page, swapping elements on the button press. If I really have to pass data to a different page, I would normally use session variables. I don't like to use cookies for anything other than authentication, although they can be good for shopping carts and other things that you want to persist beyond the session.
-
My previous employer banned session variables. They projected millions of users and didn't want all that memory floating around for 20 minutes before being released in the case the user was just there for a second. Their other argument was that they were going to a server farm and didn't want to keep the sessions coordinated. The place I'm at now does not have that much traffic so Sessions are fine with us. Our problem is sessions timing out and the users complaining they lost their work will they were yakking on the phone. We use cookies as well, but not as much. Some of our users are still terrified of cookies and disable them. In worst cases we stash the data in a database record and pull it back later. Not a good solution either.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
BrainiacV wrote:
In worst cases we stash the data in a database record and pull it back later. Not a good solution either.
Agreed - there is the fun of redundant DB entries then...and no built in mechanism to expire old data.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
If you have to move to web page 2 on a button click on page one, and page 2 totally depends on data input by user on page one, what approach would you choose to share data between the pages? Would it be session or cross-post or something else? Any why?
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
I prefer session variables to share info between pages.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I always use Sessions (unless I'm trying to pass a huge object and then I'll just pass a reference to it instead).
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
If you have to move to web page 2 on a button click on page one, and page 2 totally depends on data input by user on page one, what approach would you choose to share data between the pages? Would it be session or cross-post or something else? Any why?
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[^]
I believe it depend of the size and sensitivity of the data you just passing. There are whole religions in favor every method. In my opinion a good programmer will never set a barrier just for the shake of 'preferences', but will learn the needs and deeds of the system an act in the best way...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
