[FX.php List] Forms that create new records
Andrew Denman
adenman at tmea.org
Fri Oct 27 08:59:41 MDT 2006
"And to mark it as submitted."
This is key for a multi page submit process where you write to the database
on each page. I learned the hard way, but you are most likely going to want
to know where in the creation process an incomplete record was stopped.
This way you can easily identify invalid records and do what you want with
them.
I'm a fan of the create-n-edit method, ESPECIALLY when asking for sensitive
data that needs to be secured. Though it's encrypted in the session, the
fewer places the data is stored the better. (<-- Me being paranoid)
One last thing, I concur with Erik about providing your users with an
overview of the submission process - before they start and during the
process. After I added a progress bar to the top of each page, I received
fewer questions about the process and a lot more completed entries. It
definitely helped.
Andrew Denman
-----Original Message-----
From: fx.php_list-bounces at mail.iviking.org
[mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Dale Bengston
Sent: Wednesday, October 25, 2006 10:33 PM
To: FX.php Discussion List
Subject: Re: [FX.php List] Forms that create new records
When you execute FMNew() of FMEdit(), FX returns the data on the
layout for the newly-created record. From its key, you can extract
the record id. (You can find the details in the FX documentation.)
If you're expecting your applicants to finish in one sitting, the
easiest approach is probably to grab the record id after your FMNew()
and stuff it in a session id. Then you can use it for finds and edits
until the app is ready to submit. (And to mark it as submitted.)
Dale
On Oct 25, 2006, at 9:51 PM, Jonathan Schwartz wrote:
> OK. So you are describing a process that can be revisited, probably
> with login access, and rejoin a partially completed process. It
> would certainly make sense to create a record and edit along the way.
>
> In this case, it will probably be designed to complete the process
> in one sitting. So, that particular advantage wouldn't apply
> here....although is makes perfect sense.
>
> Just on a technical level...how do you create a record and then
> continue modifying it? FMNew() creates the record. How then, does
> the php session get the recid of the newly created record to
> continue editing? Do you write the sessionID the new record upon
> creation and then perform an FMFind to search for the sessionID to
> retrieve the recid? I know this sounds basic, but my work so far
> has dealt with editing existing records or creating related records
> from existing records. i always had a known base record to refer to.
>
> Thanks
>
> Jonathan
>
>
> At 9:19 PM -0500 10/25/06, Dale Bengston wrote:
>> I think it comes down to volatility for me. Generally I build
>> solutions where I'm expecting people to complete their work and
>> submit an order, or application or whatever over a matter of days.
>> If I'm saving all the way along, the people using the site can
>> always pick up where they left off, whether it's two seconds from
>> now or two years.
>>
>> Dale
>>
>> On Oct 25, 2006, at 9:06 PM, Jonathan Schwartz wrote:
>>
>>> Hmmm. I like the non-linear idea also. So, with a hub system,
>>> the user clicking the BACK button would be hitting the hub and
>>> not a form, thus avoiding the error message. Sounds
>>> interesting, although I'm not sure how the masses will take to
>>> the non-linear flow. Worth a try.
>>>
>>> Back to your comment...can you describe your preferences for the
>>> create-then-edit approach?
>>>
>>> Thanks,
>>>
>>> jonathan
>>>
>>>
>>>
>>> At 8:43 PM -0500 10/25/06, Dale Bengston wrote:
>>>> Jonathan,
>>>>
>>>> The browser will put up an alert if you are about to re-post the
>>>> form to the server. The back button will trigger this if you
>>>> back up over a form submit.
>>>>
>>>> One way to handle this kind of multi-page data collection is to
>>>> have a landing page or "hub" that aggregates the entire
>>>> application, showing which pieces have been completed and which
>>>> have not. You give them the first page (form), and when they
>>>> submit that, they land on the hub, which allows them to edit
>>>> that section, or click on a link to complete any other section
>>>> they choose. If all your form submits land you back on the hub
>>>> page, then it's easy for your patrons to click links to re-edit
>>>> a section rather than go for the back button.
>>>>
>>>> Using a hub page allows people to see progress better, and fill
>>>> out your application sections in any order. When all the
>>>> sections are complete, your hub page shows a "submit" button. At
>>>> the point of submitting the application, and all along the
>>>> process, your patrons can review their work so far.
>>>>
>>>> I would opt for the "create record on first form and edit
>>>> subsequently" model rather than storing the entire app in
>>>> session variables.
>>>>
>>>> Dale
>>>>
>>>> On Oct 25, 2006, at 8:01 PM, Jonathan Schwartz wrote:
>>>>
>>>>> That's a good suggestion, Erik. In this case, it's Little
>>>>> League (American Baseball for kids) registration and I can
>>>>> imagine that there might be some info that the parent might not
>>>>> have readily available.
>>>>>
>>>>> I did discover another (apparent) benefit to using Session
>>>>> variables. It seems that when the browser BACK button is used
>>>>> in a regular form (re-populating the form with an fx.php
>>>>> call) , the browser issues a warning . No warning is issued
>>>>> when only Session variables are used. Does that agree with your
>>>>> experience?
>>>>>
>>>>> J
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> At 2:08 AM +0200 10/26/06, Erik Andreas Cayré wrote:
>>>>>> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-
>>>>>> Mail-5-978021615;
>>>>>> protocol="application/pkcs7-signature"
>>>>>>
>>>>>>
>>>>>> Den 26/10/2006 kl. 1.40 skrev Jonathan Schwartz:
>>>>>>
>>>>>>> New project. The process is filling out a series of form
>>>>>>> page to generate a single new registration record. I can
>>>>>>> think of two ways to approach the process:
>>>>>>
>>>>>>> 1) storing the data in session variables until the last page
>>>>>>> is reached, and then dumping it to FMP with FMNew(). One
>>>>>>> advantage is that no new records will be created until the
>>>>>>> process has been completed. It will also be faster because
>>>>>>> FileMaker will not be involved until the last step.
>>>>>>
>>>>>> Advantage: you won't get orphan records in your DB, when users
>>>>>> give up (computer crash, dinner, whatever...!)
>>>>>>
>>>>>>> 2) Create the record on the first page and edit the record's
>>>>>>> data as the user progresses from page to page.
>>>>>>
>>>>>> Only go with this if the users are provided a way to access/
>>>>>> edit the record at a later time. This would let the user leave
>>>>>> the process, and complete it later, when they have time or
>>>>>> have gathered information which they did not at first have at
>>>>>> hand.
>>>>>> This is a special case, so it's probably not what you're
>>>>>> looking for, but not having all the required info at hand is
>>>>>> still a relevant issue. It's good practice to present the user
>>>>>> with an overview of the complete process before she begins.
>>>>>> It's comforting to know where you're going before you start
>>>>>> the journey...
>>>>>>
>>>>>> just my 2¢
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Erik Andreas Cayré
>>>>>> Spangsbjerg Møllevej 169
>>>>>> DK-6705 Esbjerg Ø
>>>>>>
>>>>>> Home Tel: +45 75150512
>>>>>> Mobile: +45 40161183
>>>>>>
>>>>>> »If you can't explain it simply, you don't understand it well
>>>>>> enough.«
>>>>>> -- Albert Einstein
>>>>>>
>>>>>> »If you don't have time to do it right, when will you have
>>>>>> time to do it over?«
>>>>>> -- John Wooden, basketball coach
>>>>>>
>>>>>>
>>>>>>
>>>>>> Attachment converted: PowerBookG4 HD:smime.p7s ( / )
>>>>>> (001D0051)
>>>>>> _______________________________________________
>>>>>> FX.php_List mailing list
>>>>>> FX.php_List at mail.iviking.org
>>>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Jonathan Schwartz
>>>>> FileMaker 8 Certified Developer
>>>>> Associate Member, FileMaker Solutions Alliance
>>>>> Schwartz & Company
>>>>> jonathan at eschwartz.com
>>>>> http://www.eschwartz.com
>>>>> http://www.exit445.com
>>>>> 415-381-1852
>>>>>
>>>>> _______________________________________________
>>>>> FX.php_List mailing list
>>>>> FX.php_List at mail.iviking.org
>>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>>
>>> --
>>>
>>> Jonathan Schwartz
>>> FileMaker 8 Certified Developer
>>> Associate Member, FileMaker Solutions Alliance
>>> Schwartz & Company
>>> jonathan at eschwartz.com
>>> http://www.eschwartz.com
>>> http://www.exit445.com
>>> 415-381-1852
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
>
> --
>
> Jonathan Schwartz
> FileMaker 8 Certified Developer
> Associate Member, FileMaker Solutions Alliance
> Schwartz & Company
> jonathan at eschwartz.com
> http://www.eschwartz.com
> http://www.exit445.com
> 415-381-1852
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
_______________________________________________
FX.php_List mailing list
FX.php_List at mail.iviking.org
http://www.iviking.org/mailman/listinfo/fx.php_list
More information about the FX.php_List
mailing list