Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Greg Beaver
Hi Petre,

Multipart forms are the solution you need.  Here are the reasons why:

1) You can set the length of time that the session cookie will live 
(I've changed it to a week for the "Remember Me" feature of my website, 
works nicely)

2) if users are disconnecting, and not all information is being 
processed, then you can use register_shutdown_function() to catch this 
problem (i.e., if mid-processing, prior to database write, the user 
disconnects, the shutdown function will do any necessary cleanup).  All 
you will need to do is have a flag variable that you set when necessary 
tasks have been completed.  So, after form processing, set it to 1, 
after database write to 2, etc.  The shutdown function would check this 
flag variable and then do the next steps if necessary.

3) even if they switch off the PC and try to start from scratch, all you 
need to do is use sessions and I would recommend using the 
HTML_QuickForm package from PEAR (pear.php.net) as the freeze() method 
will be VERY useful.  Basically, when a field is complete and shouldn't 
be changed, you freeze it and it will display the value for the user, 
but not allow it to be changed.  There is a large userbase for QuickForm 
and many people using it in multi-part forms who can answer your 
questions easily.

4) in the final review process, if you require the user to submit each 
sub-section as "OK" there will be no chance of losing more than a few 
minutes of work.  In other words, the final review should also be 
multi-page, matching the original form.  The user will understand this. 
 Paper forms have more than one page, and you have to flip them back 
and forth, so if you model it that way, no one will have a real problem, 
even really computer-illiterate folks :).

Regards,
Greg
--
phpDoocumentor
http://www.phpdoc.org


Petre Agenbag wrote:
Hi Shiva
Appreciate your input. Wrt the spanning of the form, I think, in my
situation, it would actually make things worse... You see, my suspicion
is that most of the users who are experiencing problems, have very bad
connections, many complain that they lose connectivity while they are
busy with the form ( it takes them maybe 30 min or so to fill out the
entire form ( they basically transfer the data off paper forms they have
filled out earlier while "on-site", so it's not really alot of data, but
there are a lot of fields...)
So, my fear with this approach is that they will maybe get past the
first part of the form, submit that OK, then start getting trouble with
subsequent parts, leaving me with a whole lot of partial entries in the
DB., and how do I get them to "resume" at a a later stage?
You don't understand the mindset of these people, when something goes
wrong, they'll switch off their PC's and try to start from scratch, so
it's going to be difficult to try and get them to understand the concept
of multi-part forms... I shudder to even think what will happen, or
worse, how I will be able to allow them to make corrections on a certain
part of the form once they have submit it. And sometimes, to their
defense, it's not them that want to change the details on the form, but
the subject of the form who has decided to change their name etc...
I'm not ditching this idea, I will definitely give it some more thought,
it's just at this moment, my mind is running through my original idea of
PDF forms trying to evaluate it.
Each method will have it's pro's and cons, and I'll have to go and weigh
them. I must add, I don't see "effort" as a con for a particular
solution, as long as I know it will solve the problem without adding
other cons...
Thanks again, will take it up with you again ( need some more input on
this PDF thing to get some balanced views)
PS, if you have experience with using this method, I would appreciate it
if you could let me have your "field notes" and how successfull it's
working for you.
You see, the main thing here is that I need to KNOW when someone who
says they have submitted something actually have, and that they are not
trying their luck...
  
On Tue, 2003-07-01 at 13:43, Shivanischal A wrote:

hi,

seems u have complicated task on hand mate. cant u simply consider span the
user input over multiple pages? i mean using 2 or more form on different
pages instead of a single form on one single page. if this cant be done,
we'll think of other measures. but this is by far the most simple method
-shiva

"Petre Agenbag" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Hi List

OK, firstly, sorry if this has been on the list before...

What I'd like to do is something like this:

I currently have an app that takes user input via a normal html form,
and then pops the content into mysql.
The problem is that lots of user complain that the submit times out due
to slow/bad connections, and hence the data gets lost.
What I was hoping to do now, was to somehow create a PDF form from the
current html form ( should generate itself on the fly ) , the PDF form
will obviously need t

Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Petre Agenbag
Hi Kristin
Yes, of course that is a possibility, and it would surely address the
problem of "resuming" at a later stage. I'm just rather worried at
managing these "broken" submissions. They might start one, then for some
reason don't finish, and forget about it altogether...

But, I think my biggest problem is the way the app is currently working.
To have to change it to incorporate user-id's etc, would be almost as
big a task as trying to get the PDF thing to work, and unfortunately I
can't give you ALL the details of the app ( classified stuff and too
large anyway ;) ), I don't think it would be possible to do this.
But with PDF thing, I forsee that it *could* be possible, since one
would only change the process in one place, namely the form submit, iow,
I would "break" the process there, relay the process via another (PDF?)
route and re-connect at the submit phase. The coding would be difficult,
but the process to the user would seem to be identical, which it
probably wouldn't if I change the system to incorporate user-id's (and
possibly extra interfaces to view partial forms for a specific user)...
sound just too complicated atm (but don't get me wrong, I'm listening!
as I said in a previous comment, I'm not shooting down any ideas, I'm
just more biased towards ANYTHING that might help me out without
breaking the current process flow of the app...

Thanks again for the input, please continue!


On Tue, 2003-07-01 at 16:00, Kristin Schesonka wrote:
> Hmm, i don't know if you want it that way, but i got the idea of making the
> stuff personalized . . . I mean the user logges on and gets an Userid - then
> you always save your data with the Userid, so you can look which entries in
> your DB belong to this user and the user can start again at a different
> stage . . . .
> 
> Greetings
> 
> Kristin Schesonka
> 
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Kristin Schesonka
Hmm, i don't know if you want it that way, but i got the idea of making the
stuff personalized . . . I mean the user logges on and gets an Userid - then
you always save your data with the Userid, so you can look which entries in
your DB belong to this user and the user can start again at a different
stage . . . .

Greetings

Kristin Schesonka



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Petre Agenbag
Well, I'm still a bit concerned about what would happen if the
connection got broken while they are busy...
The session will time-out (by most defaults, after 1440s), so if they
cannot re-connect, and somehow get the same SESSID, then all would be
lost that they have done so far..., and that is the main problem;
The way I have it set-up atm, is that I place all the necessary details
as hidden elements into the form and I then allow them to actually
disconnect their connections ( if they want), and to then re-conncet
before they want to submit, and then try to submit. This works, but, wrt
saving what they have done so far; when the form has submitted
successfully, I re-construct it on the action page, and this gives them
the opportunity to save the page or print it out, all well and good if
the form actually submitted correctly. BUT, when something happens
DURING the submit, then it seems that the app behaves strangely;
sometimes, it will generate the "result" form, but will not actually
insert anything into the db, or it would only insert partial data...
Now on those, I don't think one would ever be able to do something, but
if I could at least find a way to let them save the form contents so
they don't have to start all over again...
The BACK button works sometimes, but some have reported (unconfirmed by
me) that it doesn't always return them to the filled out form before
they submit. One "solution" would be to have them save the form page
BEFORE they submit, BUT, I intentionally do not want them to do that,
because it would have the submit button on it, and I KNOW that some
"clever" bloke is gonna try to gippo the system by not going through the
whole process to generate the correct form (they all look the same , but
the hidden content differs, and are crucial,to the functionality of the
app)
So, it's a catch 22 I guess...
 

On Tue, 2003-07-01 at 15:18, Kristin Schesonka wrote:
> Hi :)
> 
> I'm actually working on an Multipart-Form and i'm saving all data during the
> "Fill-In" process in a Session - then, at the end, i save the whole
> sessiondata in my table.
> That will solve the connection-problems i hope . . .
> If I am wrong, please correct me :)
> 
> Greetings from Germany
> 
> Kristin Schesonka
> 
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Kristin Schesonka
Hi :)

I'm actually working on an Multipart-Form and i'm saving all data during the
"Fill-In" process in a Session - then, at the end, i save the whole
sessiondata in my table.
That will solve the connection-problems i hope . . .
If I am wrong, please correct me :)

Greetings from Germany

Kristin Schesonka



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Cesar Cordovez
I had the exact same problem with a form some time ago.  Definetely the 
best way to do it is "spanning" the form. I don't think the temp table 
will do.  I did it with a session variable wich saves the info from the 
form and what part of the form you are.  So the user can flip between 
pages in the form.  Here is some code that will help you do it.  (From 
the top of my mind, code not tested, use it with care!)



session_register("userform");

if (!isset($userform["step"])) $userform["step"]=1;
$step = $userform["step"];
if (isset($_POST["confirm"])) {
   switch ($step):
   case "1":
   $userform["whateverfieldname"] = 
$_POST["whateverfieldname"];
   // etc
   break;
   case "2":
   // more...
   break;
   case "3":
   // more...
   break;
   case "4":
   // more...
   if (This is the last step) {
   .. save $userform to the database
   }
   break;
  }
}

print("");
printf("");
switch($step) {
   case "1":
  // place here the fields for step 1
   break;
   case "2":
  // place here the fields for step 2
   break;
   case "3":
  // place here the fields for step 3
   break;
   case "4":
  // place here the fields for step 4
   break;
}
print("");
print("");
?>

HTH

Sævar Öfjörð wrote:

You could use a temp table in the database which gets cleaned up both
when the last page is completed or if there is data in it when the user
starts from scratch. Of course you would have to use sessions to
identify each user to each line of temp data. I'm not sure if this will
work, there are some problems to overcome here.
-Original Message-
From: Petre Agenbag [mailto:[EMAIL PROTECTED] 
Sent: 1. júlí 2003 12:01
To: Shivanischal A
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] Re: Form 2 PDF 2 Form

Hi Shiva
Appreciate your input. Wrt the spanning of the form, I think, in my
situation, it would actually make things worse... You see, my suspicion
is that most of the users who are experiencing problems, have very bad
connections, many complain that they lose connectivity while they are
busy with the form ( it takes them maybe 30 min or so to fill out the
entire form ( they basically transfer the data off paper forms they have
filled out earlier while "on-site", so it's not really alot of data, but
there are a lot of fields...)
So, my fear with this approach is that they will maybe get past the
first part of the form, submit that OK, then start getting trouble with
subsequent parts, leaving me with a whole lot of partial entries in the
DB., and how do I get them to "resume" at a a later stage?
You don't understand the mindset of these people, when something goes
wrong, they'll switch off their PC's and try to start from scratch, so
it's going to be difficult to try and get them to understand the concept
of multi-part forms... I shudder to even think what will happen, or
worse, how I will be able to allow them to make corrections on a certain
part of the form once they have submit it. And sometimes, to their
defense, it's not them that want to change the details on the form, but
the subject of the form who has decided to change their name etc...
I'm not ditching this idea, I will definitely give it some more thought,
it's just at this moment, my mind is running through my original idea of
PDF forms trying to evaluate it.
Each method will have it's pro's and cons, and I'll have to go and weigh
them. I must add, I don't see "effort" as a con for a particular
solution, as long as I know it will solve the problem without adding
other cons...
Thanks again, will take it up with you again ( need some more input on
this PDF thing to get some balanced views)
PS, if you have experience with using this method, I would appreciate it
if you could let me have your "field notes" and how successfull it's
working for you.
You see, the main thing here is that I need to KNOW when someone who
says they have submitted something actually have, and that they are not
trying their luck...
 
On Tue, 2003-07-01 at 13:43, Shivanischal A wrote:
 

hi,

seems u have complicated task on hand mate. cant u simply consider
   

span the
 

user input over multiple pages? i mean using 2 or more form on
   

different
 

pages instead of a single form on one single page. if this cant be
   

done,
 

we'll think of other measures. but this is by far the most simple
   

method
 

-shiva

"Petre Agenbag" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
   

Hi List

OK, firstly, sorry if this has been on the list b

Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Shivanischal A
Hi Petre,

I'm beginning to have second thoughts about my earlier idea too; coz that is
not solving the actual problem (u're have a slow n/w). Afterall how many KB
of form data is she/he actually sending? I'll think of other possible
solutions.



Regards,
-shiva


"Petre Agenbag" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Shiva
> Appreciate your input. Wrt the spanning of the form, I think, in my
> situation, it would actually make things worse... You see, my suspicion
> is that most of the users who are experiencing problems, have very bad
> connections, many complain that they lose connectivity while they are
> busy with the form ( it takes them maybe 30 min or so to fill out the
> entire form ( they basically transfer the data off paper forms they have
> filled out earlier while "on-site", so it's not really alot of data, but
> there are a lot of fields...)
> So, my fear with this approach is that they will maybe get past the
> first part of the form, submit that OK, then start getting trouble with
> subsequent parts, leaving me with a whole lot of partial entries in the
> DB., and how do I get them to "resume" at a a later stage?
> You don't understand the mindset of these people, when something goes
> wrong, they'll switch off their PC's and try to start from scratch, so
> it's going to be difficult to try and get them to understand the concept
> of multi-part forms... I shudder to even think what will happen, or
> worse, how I will be able to allow them to make corrections on a certain
> part of the form once they have submit it. And sometimes, to their
> defense, it's not them that want to change the details on the form, but
> the subject of the form who has decided to change their name etc...
>
> I'm not ditching this idea, I will definitely give it some more thought,
> it's just at this moment, my mind is running through my original idea of
> PDF forms trying to evaluate it.
>
> Each method will have it's pro's and cons, and I'll have to go and weigh
> them. I must add, I don't see "effort" as a con for a particular
> solution, as long as I know it will solve the problem without adding
> other cons...
>
> Thanks again, will take it up with you again ( need some more input on
> this PDF thing to get some balanced views)
>
> PS, if you have experience with using this method, I would appreciate it
> if you could let me have your "field notes" and how successfull it's
> working for you.
> You see, the main thing here is that I need to KNOW when someone who
> says they have submitted something actually have, and that they are not
> trying their luck...
>
>
> On Tue, 2003-07-01 at 13:43, Shivanischal A wrote:
> > hi,
> >
> > seems u have complicated task on hand mate. cant u simply consider span
the
> > user input over multiple pages? i mean using 2 or more form on different
> > pages instead of a single form on one single page. if this cant be done,
> > we'll think of other measures. but this is by far the most simple method
> >
> > -shiva
> >
> >
> > "Petre Agenbag" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > Hi List
> > >
> > > OK, firstly, sorry if this has been on the list before...
> > >
> > > What I'd like to do is something like this:
> > >
> > > I currently have an app that takes user input via a normal html form,
> > > and then pops the content into mysql.
> > >
> > > The problem is that lots of user complain that the submit times out
due
> > > to slow/bad connections, and hence the data gets lost.
> > >
> > > What I was hoping to do now, was to somehow create a PDF form from the
> > > current html form ( should generate itself on the fly ) , the PDF form
> > > will obviously need to be downloaded to the user's PC, and will be
> > > unique for each time they use the system, ie, I don't want to just
give
> > > them a blank template PDF, some of the values need to be
> > > "auto-completed" and inserted into the form as "read-only", as well as
a
> > > couple of "hidden" fields with identifying values so I can know where
to
> > > pop it into the db.
> > >
> > > The idea is that the user will now come to the point where he would
> > > usually have filled in the html form, but instead, the app must
> > > autogenerate a PDF with some values auto-completed and/or hidden, and
> > > the user then downloads the pdf to his/her PC, where they continue to
> > > fill out the pdf form.
> > >
> > > Then, on completetion, I'd like to investigate several delivery
> > > mechanisms, arguably, the easiest way for the users ( who are mostly
> > > techno-peasants), is to simply e-mail the pdf as an attachment to me),
> > > but then I will either have to create an auto-parser for the email
> > > (prolly difficult and prone to problems with making sure the
attachment
> > > is correct etc), or I will have to then manually process the
> > > attachments.
> > >
> > > Either way, I would need to "feed" the pdf to my app, where the
> > > form/hidden variables would need to be 

RE: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Sævar Öfjörð
You could use a temp table in the database which gets cleaned up both
when the last page is completed or if there is data in it when the user
starts from scratch. Of course you would have to use sessions to
identify each user to each line of temp data. I'm not sure if this will
work, there are some problems to overcome here.

-Original Message-
From: Petre Agenbag [mailto:[EMAIL PROTECTED] 
Sent: 1. júlí 2003 12:01
To: Shivanischal A
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] Re: Form 2 PDF 2 Form

Hi Shiva
Appreciate your input. Wrt the spanning of the form, I think, in my
situation, it would actually make things worse... You see, my suspicion
is that most of the users who are experiencing problems, have very bad
connections, many complain that they lose connectivity while they are
busy with the form ( it takes them maybe 30 min or so to fill out the
entire form ( they basically transfer the data off paper forms they have
filled out earlier while "on-site", so it's not really alot of data, but
there are a lot of fields...)
So, my fear with this approach is that they will maybe get past the
first part of the form, submit that OK, then start getting trouble with
subsequent parts, leaving me with a whole lot of partial entries in the
DB., and how do I get them to "resume" at a a later stage?
You don't understand the mindset of these people, when something goes
wrong, they'll switch off their PC's and try to start from scratch, so
it's going to be difficult to try and get them to understand the concept
of multi-part forms... I shudder to even think what will happen, or
worse, how I will be able to allow them to make corrections on a certain
part of the form once they have submit it. And sometimes, to their
defense, it's not them that want to change the details on the form, but
the subject of the form who has decided to change their name etc...

I'm not ditching this idea, I will definitely give it some more thought,
it's just at this moment, my mind is running through my original idea of
PDF forms trying to evaluate it.

Each method will have it's pro's and cons, and I'll have to go and weigh
them. I must add, I don't see "effort" as a con for a particular
solution, as long as I know it will solve the problem without adding
other cons...

Thanks again, will take it up with you again ( need some more input on
this PDF thing to get some balanced views)

PS, if you have experience with using this method, I would appreciate it
if you could let me have your "field notes" and how successfull it's
working for you.
You see, the main thing here is that I need to KNOW when someone who
says they have submitted something actually have, and that they are not
trying their luck...

  
On Tue, 2003-07-01 at 13:43, Shivanischal A wrote:
> hi,
> 
> seems u have complicated task on hand mate. cant u simply consider
span the
> user input over multiple pages? i mean using 2 or more form on
different
> pages instead of a single form on one single page. if this cant be
done,
> we'll think of other measures. but this is by far the most simple
method
> 
> -shiva
> 
> 
> "Petre Agenbag" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi List
> >
> > OK, firstly, sorry if this has been on the list before...
> >
> > What I'd like to do is something like this:
> >
> > I currently have an app that takes user input via a normal html
form,
> > and then pops the content into mysql.
> >
> > The problem is that lots of user complain that the submit times out
due
> > to slow/bad connections, and hence the data gets lost.
> >
> > What I was hoping to do now, was to somehow create a PDF form from
the
> > current html form ( should generate itself on the fly ) , the PDF
form
> > will obviously need to be downloaded to the user's PC, and will be
> > unique for each time they use the system, ie, I don't want to just
give
> > them a blank template PDF, some of the values need to be
> > "auto-completed" and inserted into the form as "read-only", as well
as a
> > couple of "hidden" fields with identifying values so I can know
where to
> > pop it into the db.
> >
> > The idea is that the user will now come to the point where he would
> > usually have filled in the html form, but instead, the app must
> > autogenerate a PDF with some values auto-completed and/or hidden,
and
> > the user then downloads the pdf to his/her PC, where they continue
to
> > fill out the pdf form.
> >
> > Then, on completetion, I'd like to investigate several delivery
> > mechanisms, arguably, the easiest way for the users ( who are mostly
> > techno-peasants),

Re: [PHP] Re: Form 2 PDF 2 Form

2003-07-01 Thread Petre Agenbag
Hi Shiva
Appreciate your input. Wrt the spanning of the form, I think, in my
situation, it would actually make things worse... You see, my suspicion
is that most of the users who are experiencing problems, have very bad
connections, many complain that they lose connectivity while they are
busy with the form ( it takes them maybe 30 min or so to fill out the
entire form ( they basically transfer the data off paper forms they have
filled out earlier while "on-site", so it's not really alot of data, but
there are a lot of fields...)
So, my fear with this approach is that they will maybe get past the
first part of the form, submit that OK, then start getting trouble with
subsequent parts, leaving me with a whole lot of partial entries in the
DB., and how do I get them to "resume" at a a later stage?
You don't understand the mindset of these people, when something goes
wrong, they'll switch off their PC's and try to start from scratch, so
it's going to be difficult to try and get them to understand the concept
of multi-part forms... I shudder to even think what will happen, or
worse, how I will be able to allow them to make corrections on a certain
part of the form once they have submit it. And sometimes, to their
defense, it's not them that want to change the details on the form, but
the subject of the form who has decided to change their name etc...

I'm not ditching this idea, I will definitely give it some more thought,
it's just at this moment, my mind is running through my original idea of
PDF forms trying to evaluate it.

Each method will have it's pro's and cons, and I'll have to go and weigh
them. I must add, I don't see "effort" as a con for a particular
solution, as long as I know it will solve the problem without adding
other cons...

Thanks again, will take it up with you again ( need some more input on
this PDF thing to get some balanced views)

PS, if you have experience with using this method, I would appreciate it
if you could let me have your "field notes" and how successfull it's
working for you.
You see, the main thing here is that I need to KNOW when someone who
says they have submitted something actually have, and that they are not
trying their luck...

  
On Tue, 2003-07-01 at 13:43, Shivanischal A wrote:
> hi,
> 
> seems u have complicated task on hand mate. cant u simply consider span the
> user input over multiple pages? i mean using 2 or more form on different
> pages instead of a single form on one single page. if this cant be done,
> we'll think of other measures. but this is by far the most simple method
> 
> -shiva
> 
> 
> "Petre Agenbag" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi List
> >
> > OK, firstly, sorry if this has been on the list before...
> >
> > What I'd like to do is something like this:
> >
> > I currently have an app that takes user input via a normal html form,
> > and then pops the content into mysql.
> >
> > The problem is that lots of user complain that the submit times out due
> > to slow/bad connections, and hence the data gets lost.
> >
> > What I was hoping to do now, was to somehow create a PDF form from the
> > current html form ( should generate itself on the fly ) , the PDF form
> > will obviously need to be downloaded to the user's PC, and will be
> > unique for each time they use the system, ie, I don't want to just give
> > them a blank template PDF, some of the values need to be
> > "auto-completed" and inserted into the form as "read-only", as well as a
> > couple of "hidden" fields with identifying values so I can know where to
> > pop it into the db.
> >
> > The idea is that the user will now come to the point where he would
> > usually have filled in the html form, but instead, the app must
> > autogenerate a PDF with some values auto-completed and/or hidden, and
> > the user then downloads the pdf to his/her PC, where they continue to
> > fill out the pdf form.
> >
> > Then, on completetion, I'd like to investigate several delivery
> > mechanisms, arguably, the easiest way for the users ( who are mostly
> > techno-peasants), is to simply e-mail the pdf as an attachment to me),
> > but then I will either have to create an auto-parser for the email
> > (prolly difficult and prone to problems with making sure the attachment
> > is correct etc), or I will have to then manually process the
> > attachments.
> >
> > Either way, I would need to "feed" the pdf to my app, where the
> > form/hidden variables would need to be harvested from the form, and noly
> > then (after validation), be entered into the db.
> >
> > So, simple concept, but I'm sure many pitfalls, the least being probably
> > that I have never done this, and don't know where to start, or even if
> > it's possible/advisable to follow this route.
> >
> > Hence my post here...
> >
> >
> 
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php