Essentially, "forms" in Access would become "display files" in Fusebox.
Display files have a "dsp" prefix. When you submit the form contained in the
dsp file, you usually call an "action file" (act prefix), which processes the
data from the form. Think of forms in Fusebox as unbound forms in Access;
there's no implicit processing. You have to build all the code to do database
updates, form population, etc. There are also a number of Javascript-based
approaches to creating form behaviors that are somewhat analogous to Access'
field properties and methods.
As a rough approximation, here are some definitions:
Access Fusebox
====== =======
Forms (unbound only) dsp files with <form> tags in them
Form modules act files and/or Javascript routines
Queries (select) qry files
Queries (update, act files
append)
Reports dsp files
-- Oddballs --
Macros no real analog
Modules in Fusebox everything is code.
I have a long history in Access development. If you'd like to start an off-
list dialog to continue this analogy, feel free to mail me.
- Jeff
On 7 May 2001, at 9:00, 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
