On Sat, 18 Jun 2005 15:00:55 -0400, Michael Graham wrote:
Hi Michael
>> Now, in the editing screen, if the user submits a form of 310
>> staff details, with N fields per person (sigh)
> You really aren't kidding about this stuff, are you? :)
Nope.
> Yeah that's the kind of thing I mean. (Assuming I understand you
> correctly - that you are storing application state in the user's
> session.)
Yes. That's what it's for, IMHO.
I never use cookies (personal preference, easy to defend), and given the size of
the incoming CGI form, I want to minimise hits on the db just to re-discover
where I was up to before I sent out the form.
> If the user closes the form and comes back to it three days later
> then the application state from three days ago is reused, right?
> Bleah.
Nope. A cron job zaps sessions right on 2 days later. 10 hours was my
suggestion, but, hey, I'm only a contractor :-).
> The other option is to use hidden fields, but that's pretty messy
> too.
There is just too much info. I use 3 hidden fields:
o The session id
o The (default) run mode, which can be overridden back at the Perl level by the
user clicking certain things, or at the JS level the same way [1]
o A state variable giving the basic action to perform in the given run mode [2]
[1] Eg: With an edit button per person, clicking on any one of these means JS
moves that person's id into the state variable.
[2] Eg: If the variable has the value 'e' for entity (dept), then JS can turn
that into 'eNNNN' when a button (1 per entity) is clicked in the entity
hierarchy tree, thereby identifying which entity has been selected. Etc.
The session in the db can hold the list of valid person/entity ids, etc.
> Still doesn't solve the problem of one user, one form, two browser
> windows though. Hmmm....
I have 2 frames (for reasons which keep the customer very happy), hence 2
cgi-scripts. Of course they are the same 2, with 2 names, with a PARAMS value in
the constructor:
Application -> new(PARAMS => {target => 'left', use_test_db => 0, verbose => 0})
-> run(); Also, target => 'right'.
Communication directly between the panes is currently not possible, since the
last time I tested Firefox there was a fatal bug [1] whereby onFrameLoad was
only triggered occasionally, apparently depending on the size of the data being
rendered. I assume the addition of unacceptable (to me) complexity would enable
inter-frame comms, but that does not appeal to me. I have other priorities.
Perhaps browser experts could enlighten me. Certainly I've read on-line people
doing astonishing things within a browser. But I have to support a range of
browsers. IE-only code is unacceptable too. Also, the uni, like most in
Australia I suspect, is moving toward Mozilla, and code which can be proven to
fail under that is also unacceptable. But this is getting off topic.
[1] http://savage.net.au/Ron/html/firefox-v-0.9.1-bugs.html
(This was August 2004)
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 19/06/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
