At 09:00 AM 5/7/01, Janine Jakim wrote:
>I need to know how take my knowledge of access and "convert" it
>to the theory of fusebox to use fb properly.

OK, there are a couple of things to keep in mind when programming on the 
web vs. Access.   Again, these issues are universal to the web, not just to 
ColdFusion and FuseBox.  So, there is nothing special about FuseBox that 
will help you here, except that FuseBox help you keep your work more 
organized, unified and structured.  Maybe other's on the list have other 
opinions?

I will only cover the general issues, and not go into specific CF code, 
since there are really so many different techniques for the desired 
actions.  Hope it helps, at least a little!

1) When editing existing records, Access loads the form with data for 
you.  You will have to program this in yourself in any web 
language.  Generally, this is done by doing a single query on a key value, 
and using the resulting value in the VALUE property of the HTML form field.

2) When saving records, Access saves the record automatically when you 
close the form or go to the next record.  You will have to program the 
"save" functionality separately in CF. This is generally done in the 
"action" page of the form (or the resulting FuseAction in FB) which runs 
when you hit the "submit" button.  Generally you do an an "UPDATE" query in 
this action page.  If you go to a different record, and the user made 
changes, the changes won't be saved unless you program it as part of the 
"go to next record" functinality.

3) When validating user input (ie, requiring field entry, making sure data 
types match, etc) this can generally be done 3 ways:
         a) Javascript (client side)
                 Write your own Javascript, or use <CFFORM> and <CFINPUT> 
fields, and CF will write some basic Javascript for you.
         b) Custom Validation on the Server Side
                 This is generally on the same action page as above, but 
before saving records.
                 Do things like <CFIF Not IsDate("Form.MyDate")> 1) DISPLAY 
ERROR MESSAGE, 2) don't run the update query 3) return to form page
         c) ColdFusion Server Side Using Special hidden fields
                 ColdFusion has a built in validation functionality that 
uses special hidden fields in the format:
                 <INPUT type="hidden" name="fieldname_date" value="user 
validation message">
                 <INPUT type="hidden" name="fieldname_required" value="user 
validation message">
                 <INPUT type="hidden" name="fieldname_integer" value="user 
validation message">


4) When moving from record to record, Access allows you to browse the 
recordset, and go the next record smoothly.  There is generally no way to 
do this on the web without a lot of fancy code.  General solution: a) a 
search page, b) list the search results c) Choose one of the records to 
load into the form to edit.

5) When inserting new records, be aware that with auto-numbering fields in 
general, you don't know which record it is you just inserted, because the 
DB creates the new key field value for you.  So, you generally can't 
immediately re-access the new record or do ANY action where you need to 
know the key field value.  This is because you generally need to know the 
key value of the record in order to do stuff with it in SQL.  However, in 
SQL Server, there is a special variable in called @@IDENTITY which will 
tell you the value of the key field just after you insert the new 
record.  There is probably an equivalent value in Oracle and most 
professional DB servers.

You can drop auto-numbering, and create the new key value yourself.  For 
example: LAST KEY VALUE = KEY VALUE +1.  This method has it's own set of 
problems on high volume web sites, and generally needs to be put in a 
transaction so two instances of the web page can't accidentally lookup the 
same highest key value.



At 09:00 AM 5/7/01, Janine Jakim wrote:
>Thanks for taking so much time to give me some insight about this process.
>I realize I have a ways to go before I become comfortable with all this.
>As far as Access/forms/subforms.  It isn't that I want to duplicate them in
>a fusebox situation.
>
>I guess what I'm saying is I am not sure how to design/execute it all
>together.  I need to know how take my knowledge of access and "convert" it
>to the theory of fusebox to use fb properly.
>
>But I need someone to explain to me how to design in fb vs access.  I guess
>that's my key point- I'm confused on how to set it up- how/where the pieces
>fit together.  I was hoping that someone with an Access background could say
>"instead of subforms you....blah blah/put all your queries together
>here/etc...  I am confused on how to make my program functional in fb
>because I keep looking in terms of access!  (Forms/subforms) It isn't that I
>want to do my program exactly like I would in Access, I want to how to
>design/execute a fusebox program but from an access "terminology"
>discussion... Does that make sense?
>
>
>
>
>-----Original Message-----
>From: Douglas Smith [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 04, 2001 6:42 PM
>To: Fusebox
>Subject: Emulating Bound Forms and SubForms (was Practicals of Fusebox)
>
>
>Whew!  That's a lot to ask!
>
>Seriously though, this is a general problem with any WEB development you
>do, and is not limited to FuseBox.  The web is generally stateless and
>queries or recordsets cannot be "bound" to HTML forms like they can with a
>Windows client like Access or VB.
>
>On the other side of things, I made some tools a couple of years ago that
>automated some of the form functionality you are talking about (warning,
>huge project ahead :-)
>
>For example, I used a list of key field values to manage or emulate my
>"recordset"  When I wanted to go from one record to the next I hit the next
>button on the form, and I got the next key from the list, and did a SELECT
>query for that single record on the key value from the list, and loaded the
>form with that data.
>
>That way, if any data was changed since I generated my key list, I would
>not be looking at cached data, but I still had a "set" of records that I
>was working with.
>
>I had buttons for last record, next record, save changes, insert new,
>delete.
>
>I could also say things like "Record 25 of 105" at the bottom of my form.
>
>I also had an automated "browse mode" for this list, so you could browse
>the data, and skip to the record you wanted.  It also had a "sort" feature,
>so the key field list could re-indexed by any field.
>
>As long as each table had their own unique key, it worked fine.
>
>You could also do queries to get the set of records you wanted, for example
>
>          SELECT KeyField from MyTable WHERE Condition
>
>so you don't have to be editing the entire recordset in the form emulator.
>
>As far as joins go, I could make them display in the form, but they were
>not updatable using this method.
>
>I had to do a LOT of fancy custom tags to get all of this to
>work.  Inserting new records in the same set of form tools was also
>challenging.
>
>As far as emulating sub-forms go, yes, FRAMES sound like a good solution.
>
>If you really want true bound forms (to emulate Access), you should go with
>ActiveX objects, and run them in IE, but then you are browser limited, and
>you should only do this for intranets, not general web sites.  ASP is
>generally best used for this approach.  See AspXtras.com
>
>
>
>At 10:42 AM 5/3/01, Janine Jakim wrote:
> >I have a favor of the list.  Can someone who knows Access explain how to
> >accomplish the same type of thing by using fusebox.
> >1.  In Access I would make a main form that is attached to a query.
> >2.  This main form would be filled with many subforms showing specific
> >information.  Each subform would have its own query- usually just 2 tables
> >so that info could be added updated.
> >(ie: the main form would show the client demographic info- one subform
>would
> >show spouse info- another subform would show medical history, etc/on/on) I
> >could have a dozen subforms on a main form.
> >3.  These subforms would be attached to the mainform through a
> >primary/foreign key combo.  This part was very easily to accomplish- it was
> >set in the form properties.  In the properties section I would list as the
> >parent/child link the id# of the primary/foreign id#.
> >A user would see the main form- would be able to navigate through forms
>with
> >buttons and with permission edit add info into the subforms.
> >
> >I'd like someone to explain how you accomplish the same type of thing in
> >fusebox.  I assume this would best be done with frames.(?)
> >How are the pages best set with each other and to the query to show the
> >information. (ie: in access linking the pages with parent/child link would
> >do this.  So although my query for a subform may say list all the spouse
> >names only main form person's spouse name would show up).
> >I keep feeling like I understand the logic of fb, but my background and
> >practical experience is all in Access/sql.
> >Can someone please explain the fb practicals in terms of access
> >forms/subforms only background.
> >Thanks in advance.
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to