[prev in list] [next in list] [prev in thread] [next in thread] 

List:       barracuda
Subject:    Barracuda: Resubmitting Forms
From:       Barracuda () enhydra ! org (Christian Cryder)
Date:       2001-01-10 16:22:01
[Download RAW message or body]

> It *can* be, but it doesn't have to, and that's why I'd advise
> to not code that particular requirement into a general framework.

Everything I've heard in this discussion so far leads me to believe that
there are
a) multiple ways of doing this
b) no one way for doing it all the time

Which leads me to the same conclusion...this type of thing shouldn't be a
requirement for this particular layer (the component level).

Christian
------------------------------------------------
Christian Cryder
Application Architect, Barracuda
Lutris Technologies, Inc.
christianc@lutris.com
------------------------------------------------
       "What a great time to be a Geek"
------------------------------------------------
http://www.lutris.com ~ http://xmlc.enhydra.org
        http://barracuda.enhydra.org


> -----Original Message-----
> From: owner-Barracuda@enhydra.org [mailto:owner-Barracuda@enhydra.org]On
> Behalf Of Richard Kunze
> Sent: Wednesday, January 10, 2001 2:41 AM
> To: Barracuda@enhydra.org
> Subject: Re: Barracuda: Resubmitting Forms
>
>
> On Tuesday 09 January 2001 20:56, you wrote:
> > I still think we have to set some value in the form .
> > Here is the complete process:-
> >
> > 1. App server receives a request to display a form page.
> > 2. It generates a random number say "123456" it stores that value in the
> > user session (Stored on the server not on the client) and
> creates a hidden
> > field called FormId with value="123456"
> > 3. When the server receives the submited request it checks the
> session for
> > FormId "123456" if it finds it there this means the form was never
> > submitted before and it is accepted. The ID is removed from the session.
> > 4. If the user hits the back button, changes some value and submits the
> > form again then there is no ID "123456" in the session and user gets an
> > error.
> >
> > Why do we have to keep a value in the client at all? The answer is that
> > there can be some forms which the user can submit multiple times in a
> > session but not really duplicates.
> > consider this:-
> > A user can submit Problem report (Cases) through our site. We
> want the user
> > to be able to submit mutliple cases in a session. But we want to prevent
> > him from re-submitting a case (After hitting the back button)
> > If we don not store the hidden value in the form we cant match it with
> > session. User should be able to click the "Create Case" button
> and create a
> > new case. Each time he does that a new value is stored in Form and the
> > session.
> > If you just have a persistance flag in the Form Object then
> once the user
> > submits one case he will not be allowed to submit another.
>
> OK. In this case, I agree with you. But, the ID you're generating
> is just used
> to identify the form. You could just as well use a sequential
> trouble ticket
> number for this - if a user submits data with a different trouble ticket
> number, it's a new problem report.
>
> In general, you only need to make sure that each form instance is only
> submitted once. Depending on the form, the instance may be uniquely
> identified by the form's URL (e.g. for a login form), by some part of the
> form data (e.g., the trouble ticket ID in your problem report
> form) or it may
> even be the complete set of data entered in the form.
>
> So, the server only needs a boolean flag telling it it has seen
> "this form"
> already and doesn't want to see it again, where "this form" is
> some key that
> uniquely identifies the form. This can be just the URL, or the
> URL along with
> some data (depending on the application), but it's not
> necessarily a special
> hidden field with a random value. It *can* be, but it doesn't
> have to, and
> that's why I'd advise to not code that particular requirement
> into a general
> framework.
>
> Agreed?
> --
> Richard Kunze
>
> [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
> Tel.: +49 6102 249 600, Fax.: +49 6102 247 970
> http://www.tivano.com, kunze@tivano.com
> ------------------------------------------------------------------
> -----------
> To unsubscribe from this mailing list, send email to majordomo@enhydra.org
> with the text "unsubscribe barracuda" in the body of the email.
> If you have other questions regarding this mailing list, send email to
> the list admin at owner-barracuda@enhydra.org.

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe barracuda" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-barracuda@enhydra.org.

[prev in list] [next in list] [prev in thread] [next in thread]