[FX.php List] Forms that create new records
Jonathan Schwartz
jonathan at eschwartz.com
Thu Oct 26 06:53:13 MDT 2006
Thanks Dale. I didn't realize that FMNew() did
that. Well....that was easy. ;-)
>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.)
This makes more sense after learning the technique above.
J
>
>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
--
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
More information about the FX.php_List
mailing list