[FX.php List] Forms that create new records
Jonathan Schwartz
jonathan at eschwartz.com
Wed Oct 25 20:51:11 MDT 2006
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
More information about the FX.php_List
mailing list