and you will completely circumvent the performance limitations of doing it
with a database.
1. First time the user hits a page, a querystring value is added to the url.
2. This querystring value is passed to every other page that the user might
go to.
3. The querystring value will grow as the pages accessed increases.
4. Each page could check a global shared function in Global.asax that checks
if the page has already been viewed based on the querystring value and
returns a boolean value.
5. If the function returns true, the page has already been viewed and you
can redirect them, if false, let the current page process.
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@dotnet.itags.org.microsoft.com...
>I was trying to think of ways to stop accidental reposts of data when users
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
> do
> a response.redirect to the page so people get a fresh version of it. If
> it's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them
> to
> expire after a certain time. I was thinking that I would store the guids
> in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem,
> what
> is wrong with it?
> Thanks, ScottHow many administrator you have so you need to have a webfarm for them?
Actually to put something in querystring you will need to redirect which is double trip to the server.
I think that you better of with keeping GUID in Session object and hidden field. Then comparing them on Post back.
George
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message news:81951537-B7DD-420F-A1E2-1FE47F243ED1@.microsoft.com...
This wouldn't really scale across multiple servers well. Also, the user can
have multiple windows open at the same time. This is an adminstration site
for a client application.
"Scott M." wrote:
> Use the same concept buy with a querystring value or hidden form field value
> and you will completely circumvent the performance limitations of doing it
> with a database.
>
> 1. First time the user hits a page, a querystring value is added to the url.
> 2. This querystring value is passed to every other page that the user might
> go to.
> 3. The querystring value will grow as the pages accessed increases.
> 4. Each page could check a global shared function in Global.asax that checks
> if the page has already been viewed based on the querystring value and
> returns a boolean value.
> 5. If the function returns true, the page has already been viewed and you
> can redirect them, if false, let the current page process.
>
>
> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
> news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
> >I was trying to think of ways to stop accidental reposts of data when users
> > hit the back button and I came up with an idea.
> > If I were to tag every response that I send to the client with a guid and
> > then store that guid in a database I could check on the postback to see if
> > that request has already been posted. If it has been posted I would just
> > do
> > a response.redirect to the page so people get a fresh version of it. If
> > it's
> > the first post back I could delete the guid from the database as being a
> > valid response. I would also have to timestamp each entry to allow them
> > to
> > expire after a certain time. I was thinking that I would store the guids
> > in
> > sql server.
> > This idea seems too much of a magic bullet for the re-postback problem,
> > what
> > is wrong with it?
> > Thanks, Scott
>
>
Actually, it would scale just fine since all code would reside in each page
and the querystring is not server-dependant. Also, remember that I'm using
querystring as an example, but it could also be a hidden form field or even
a cookie value. As for multiple windows being open, it shouldn't make any
difference, unless you are saying that they would have multiple windows with
the same page in them open?
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:81951537-B7DD-420F-A1E2-1FE47F243ED1@.microsoft.com...
> This wouldn't really scale across multiple servers well. Also, the user
> can
> have multiple windows open at the same time. This is an adminstration
> site
> for a client application.
> "Scott M." wrote:
>> Use the same concept buy with a querystring value or hidden form field
>> value
>> and you will completely circumvent the performance limitations of doing
>> it
>> with a database.
>>
>> 1. First time the user hits a page, a querystring value is added to the
>> url.
>> 2. This querystring value is passed to every other page that the user
>> might
>> go to.
>> 3. The querystring value will grow as the pages accessed increases.
>> 4. Each page could check a global shared function in Global.asax that
>> checks
>> if the page has already been viewed based on the querystring value and
>> returns a boolean value.
>> 5. If the function returns true, the page has already been viewed and you
>> can redirect them, if false, let the current page process.
>>
>>
>> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in
>> message
>> news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
>> >I was trying to think of ways to stop accidental reposts of data when
>> >users
>> > hit the back button and I came up with an idea.
>>> > If I were to tag every response that I send to the client with a guid
>> > and
>> > then store that guid in a database I could check on the postback to see
>> > if
>> > that request has already been posted. If it has been posted I would
>> > just
>> > do
>> > a response.redirect to the page so people get a fresh version of it.
>> > If
>> > it's
>> > the first post back I could delete the guid from the database as being
>> > a
>> > valid response. I would also have to timestamp each entry to allow
>> > them
>> > to
>> > expire after a certain time. I was thinking that I would store the
>> > guids
>> > in
>> > sql server.
>>> > This idea seems too much of a magic bullet for the re-postback problem,
>> > what
>> > is wrong with it?
>>> > Thanks, Scott
>>
>>
>
>>Actually to put something in querystring you will need to redirect which
>>is double trip to the server.
You do not need to re-direct to put something in a querystring. What are
you talking about?
0 comments:
Post a Comment