Best Practices for Web App Development ?

[Kevin Frey]

I've been spending considerable time thinking about the various implications
that come into play when building a production-quality web application and
this has prompted me to ask whether there are any best practices guidelines
on achieving this. Particular questions I have are:

1. Session management using non-persistent cookies (for Session Id). The
chief problem I see with this is what happens if a user chooses File->New
Window and then wants to "log in" to the same application again. One browser
process trying to handle two different sessions with cookies. What is the
typical workaround for this? I've played around with ASP.NET URL rewriting
with the session ID's stored in the URL, but this seems to have its own
problems (a seeming inability to be able to copy the URL from the address
bar for pasting via an email, for example - since it contains the Session
ID).

2. Server-side state associated with a window as opposed to a session - how
to identify the page? Let's say the web interface presents the user with
view-only details of a customer. Whilst viewing this page the user could
easily create a new window (in IE) and now be looking at two copies of the
customer, but more importantly they could start navigating within each
window independently, albeit as part of the same session state (since that
would be the typical case). If the user then wanted to edit two different
records in those two different windows, and some amount of server-side state
needed to be held for each operation (eg. a lock or whatever), what would be
the typical method for tracking the state independently for each window?
And, more importantly, how would I know when to clear that state?

I think it is fair to say that people expect their browser to behave
"normally" and I want my back-end to be able to respond to their "normal
user" but still behave correctly, hence these kinds of questions.

Thanks for any and all input.

Kevin

 

[Raymond]

First of all, if they go to File | New Window, that
shouldn't be a problem for non-persistent cookies,
it's still in the same IExplore process. So the
non-presistent cookies should be readable in that
new window. What you describe is only a problem when
then open a whole new IExplore process, in which
case you can only maintain session with persistent
cookies.

Regarding server-side edits across windows: depends
on the exact problem. If window 1 makes change #1
to a record, and then window 2 makes another change
to the same record, you just handle that on the server
depending on the record state at the time the change
was made. No mystery there. And the client windows
get updated depending on the time that their response
comes back. If you're very worried about transactions and
locks on the DB side, you could try stricter locks.