in reply to CGI Cookies

Assuming I'm understanding your question, you'd like to avoid the user getting 2 page updates, one to get the cookie, the second to load the second page of the form. Essentially, you can't "do" anything in the browser without it loading a page. The way I tend to handle multipage scripts is to put all the functions into one script, rather than a mix of CGIs to process them and HTML pages served separately.

In your example, your script called with no parameters would print the first page (either by including the HTML in you script, or by opening a file containing the page or page snippet and printing its contents); the script called with valid form fields prints the second page, including a cookie header; the script called with invalid form fields prints the first page, possibly processed to mark which field was incorrectly filled in, pre-fills any fields the user entered correctly, etc.



the hatter

Replies are listed 'Best First'.
Re^2: CGI Cookies
by Trihedralguy (Pilgrim) on Feb 18, 2008 at 15:05 UTC
    Thats what I wanted to confirm was that you cannot pass a cookie without print the page to the browser. I will have to re-think a bit of my logic I think.

    As for putting all of my pages in one script, I dont think that is a good idea. I have about 6 forms that are going to be apart of an application, each form is a different "stage". I want to be able to save to the database after each step. So putting all of my HTML in one hat isn't really an option.

    Thank you for the comments!
[reply]
      Putting all pages in one script might actually be a good idea. As long as you make a hidden parameter in each of your forms with the number of the stage, your script will be able to direct the input to the right routine and you benefit from having all "common" routines in one place, rather than being repeated in all your scripts. Especially the connection to the database will benefit from being only defined once (if you ever have to change anything concerning the database, you make changes in ony one place).

      Also all standard matters, such as headers & footers, CSS, Javascript, Cookies, ... will all be found in one spot.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
      You probably would be best off using a single CGI program to handle all stages. Aside from your original cookie issue, it cuts down on duplicated code (e.g., initialization) by allowing all stages to reference the same routines and also makes it much easier to repeat stages if needed. (User ended up at stage 3, but some of the required information is missing? Just call the stage 2 sub and send them back to fix it.)

      Personally, I tend to use a CGI::Application-style approach to do this, with the code for each different page of the application in a separate module, then a very small .cgi which just loads up those modules and dispatches calls to them based on the request's specified action (CGI::Application calls it a "runmode"). Others are very fond of Catalyst or other frameworks, but I'm not familiar enough with any of them to describe how they function.

      Oh, and I just reread your post and picked up on something I missed earlier... Are you under the impression that "1 CGI script = 1 page"? That is most definitely not the case. The same CGI can produce an unlimited number of distinct pages. Having a single CGI program which produces 6 different pages (selecting based on the input received - or selecting randomly, for that matter) and saving each one's input to the database after each step is no harder (and probably actually easier) than writing 6 separate CGIs which each produce one page.

[reply]
        CGI::Application isn't an option right now, I haven't been able to pick it up yet.

        I have in the past made a lot of applications with very minimal "number of pages". I was just hoping to make this one a bit more structured. Having 1000+ lines of code in one application starts to get very confusing. In the last form application I made, I had less than 3 CGI scripts. But it was a considerably less amount of data being filled out.

        I think what I might end up doing is just calling a second page like I describe above, where I just say "You are being logged in...One moment." (Or Something). Pass them the cookie and the continue on the process. Well see, but thanks for all the suggestions!
[reply]

In Section Seekers of Perl Wisdom