|
|
Posted by Anirudh Dutt on 03/02/05 03:35
On Tue, 1 Mar 2005 14:56:57 -0800 (PST), Richard Lynch <ceo@l-i-e.com> wrote:
> Anybody got a better idea for handling this sort of design in any
> reasonable fashion?
how about storing all the form info using sessions/session-style
steps. for stability/security, u can store all variables associated
with users' sessions. when a form is semi-submitted (i.e. not
finalized or whatever by the user but info has been sent). to keep
track of each variable and not mix them up between pages, use the page
name or the name of the procedure/task as the main array keys to the
arrays of variables.
$_SESSSION['adding_user']['user_name'] = 'foo' ;
$_SESSSION['adding_user']['home_page'] = 'example.com' ;
$_SESSSION['adding_user']['continue_at'] = 3;
the 'continue_at' is what is used to keep track of what the user has
half-done. so when he returns to a page that may have it's info set up
across several pages, u can directly show the (1.) next page to be
filled. even if it's on the same page in (2.) different sections, u
can use it to indicate what's needed next. u can even use it to store
the (3.) tab index of the form entry to be filled next, or depending
on the situation, the last form entry filled.
u can store the order of half-done stuff ('steps') as an array whose
values are the task names above.
this methodology has no behavioural dependencies on where u choose to
store the info. u need not even use sessions, but store the variables
for each task separately. once a log in situation is acknowledged, the
data can be picked up from anywhere. i'd use serializing it and
storing ALL of it in one row: (id , vars). easier to access lots of
info at one go. even if it's a large chunk. better than several slow
accesses for various checks.
i only mention this coz though my examples are with $_SESSION,
_anything_ can be used.
so when any task is performed, u can check which ones are left. in
fact, u can even add the page that has to handle it as part of the
stored info. so if half of user_add is complete and half of group_add,
if group_add needed info that user_add was to supply, then as soon as
all the user_add info is provided, u can re-direct to the page
(handler) for group_add.
$_SESSSION['steps'][0]['step'] = 'user_add' ;
$_SESSSION['steps'][0]['handler'] = 'adduser.php' ;
$_SESSSION['steps'][1] = array (
'step' => 'group_add' ,
'handler' => 'addgroup.php' );
use some common format for GET vars to indicate to that page that it
should process the info, like '?do_it=1' and auto append when
re-directing or add it to handler for specific cases.
though, it would normally check for sufficient info before proceeding anyway.
once a task is processed completed, remove it's variables. ditto for
when a user cancels a task. u can even use the structure to record and
track dependencies between tasks and inform the user and/or have
cascading effects.
a not so elegant solution for the transaction handling of incomplete tasks...
for each independent data set could have an incomplete flag which u
check for while processing, so u can decide on what data u want based
on completion status. if u're using stored procedures or functions,
store the logic in them transparent to ur queries. so u can use the
data u have in the db, whether or not it's part of a completed
process.
(whether u keep fetching data from the db or store it in two places:
one for the forms, the other in the db as data...i leave to u to
decide).
modularity:
create functions or use classes handle all the tasks. since each page
only has to understand/use a subset of those vars (which would usually
be under one key); it'll be easy to work with each page's chunk of
data.
storage, propagation, ordering, etc. covered.
--
]#
Anirudh Dutt
....pilot of the storm who leaves no trace
like thoughts inside a dream
Navigation:
[Reply to this message]
|