Re: A CGI chained-event theory question

Greetings again,
Fortunately my problem is much simpler than the replies above address, but it shows that my post that I reread and rewrote 30 times before finally posting just didn't contain enough information to be clear.

My users have accounts in the web system, their cookies contain only their account names (And, in fact, an MD5 checksum of that name and an internal value to prevent cookie tampering).
All data is stored on the server, each form being inserted into the DB (MySQL) after each submit, it is only after the final submit that the data is collected together (since currently they all share a batch number allocated when you do your first submit), formatted and output into the Summary Page.
All users input is important and should appear on the Summary Page.
What I'm wanting is to have a Summary Page that, after the final Submit, contains the most recent groupings, BUT if a user enters a bunch of items now, and then another bunch 20 minutes later that they should somehow be amalgamated into a single summary saving untidy splotches of their days input all over the Summary Page.

I believe, however, that the answer has come to me - simple, and relatively concise.
Do away with Batch IDs, but put a datestamp on each DB entry. After each Submit, look around for any entries in the Summary Page table from my user in the last 12 hours or so, if found, append my latest item onto that. That way its realtime (as soon as they submit, its attached to a summary somewhere) and if they spread out data entry over a day, it will still be attached to the same Summary for tidiness.

You may find it amazing that it took me days of brainstorming, and eventually the 30 minutes+ it took me to form the above posting to ask you for your opinions... So sue me.
However, in doing so (posting), I seem to have managed to collect my thoughts, and as all good ideas do, came to me last night at 3am in bed.

My thanks for your good answers (even if not entirely related to what I really wanted to say), and bothering to read my drivel.

JP
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

Comment on Re: A CGI chained-event theory question

Replies are listed 'Best First'.
Re: Re: A CGI chained-event theory question by Ryszard (Priest) on Feb 04, 2002 at 23:54 UTC
A couple of points: Session ID's should be dynamically generated as rob_au suggests and stored in a session table for better security. If your database is compromised, someone can spoof all your users. It just adds another layer of security to your app. Generate another cookie each time they log in. Make sure you provide an option for the user to logout also. It sounds like you could use a 'staging' area for your data. (if the entries are not required immediately). How about this: Create a table called stage with a username and data column. Each time the enter button is pressed go get what is already has already been stored. You store your incomplete list in the database by using Storable.pm as an array check to see if the no more data checkbox has been checked If the check box is selected thaw everything out then chuck it in the database as you need. If not thaw it all out, and `push @existing_data, @new_data`, freeze it, and put it back. If you use this method, you are not time dependant at all (what happens if they want to continue the list after your "Time Out" period? (go to lunch, come back after the weekend et al)) If the inputted data is required straight away, then you could do a similar thing, except add a "complete" column to your items table. To provide a summary, you scan all the rows belonging to your user with the flag set saying the list is not complete. On displaying the summary, you set all the flags to "The list is complete". Obviously this is a little simplistic, if you flesh it out a bit, it should work pretty well. HTH	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: A CGI chained-event theory question
by Ryszard (Priest) on Feb 04, 2002 at 23:54 UTC

Session ID's should be dynamically generated as rob_au suggests and stored in a session table for better security. If your database is compromised, someone can spoof all your users. It just adds another layer of security to your app. Generate another cookie each time they log in. Make sure you provide an option for the user to logout also.

It sounds like you could use a 'staging' area for your data. (if the entries are not required immediately). How about this:

Create a table called stage with a username and data column.
Each time the enter button is pressed go get what is already has already been stored.
You store your incomplete list in the database by using Storable.pm as an array
check to see if the no more data checkbox has been checked
If the check box is selected thaw everything out then chuck it in the database as you need. If not thaw it all out, and push @existing_data, @new_data, freeze it, and put it back.

If you use this method, you are not time dependant at all (what happens if they want to continue the list after your "Time Out" period? (go to lunch, come back after the weekend et al))

If the inputted data is required straight away, then you could do a similar thing, except add a "complete" column to your items table.

To provide a summary, you scan all the rows belonging to your user with the flag set saying the list is not complete. On displaying the summary, you set all the flags to "The list is complete".

Obviously this is a little simplistic, if you flesh it out a bit, it should work pretty well.

HTH

[reply]
[d/l]