[FX.php List] Forms that create new records
Dale Bengston
dbengston at preservationstudio.com
Wed Oct 25 20:19:53 MDT 2006
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
More information about the FX.php_List
mailing list