But i LIKE to squat! And I do it so well. OK, I'm giving a talk on Fusedoc
at the upcoming Fusebox conference, so this is a good time to be talking
about this stuff. First, tell me what you DON'T like about the present
style. A quick refresher:
--> userID: NUMERIC, a primary key from USERS table
This indicates that an attribute will be explicitly passed into the fuse and
provides info on it
--> [userID]: NUMERIC, a primary key from USERS table
indicates an optional parameter
<-> userID: NUMERIC, a primary key from USERS table
indicates a "pass-thru" parameter, a var that is passed directly into AND
out of the fuse without change
++> application.userID: NUMERIC, a primary key from USERS table
indicates a global variable
+++ myFile.cfm
indicates an include file needed for this fuse to run
Each incoming symbol has an outgoing symbol for its counterpart so that
--> is matched with <--
and so forth. Here's what a real fusedoc looks like from a recent job I did:
<!-- CartSummary.cfm -->
<!-- [EMAIL PROTECTED] -->
<!---
|| Responsibilities: I show the user's cart summary based on the cookie
"cartID" that exists. If no cookie exists, I tell the user they don't have
anything in their cart.
||
--> RFA.continueShopping: a FUSEACTION
--> RFA.removeItemFromCart: a FUSEACTION
--> RFA.retotalCart: a FUSEACTION called when the Update_&partID&_&quantity&
is changed
--> RFA.checkout: a FUSEACTION
<-> fatherID: a STRING
<-> fatherType: a STRING ( Certification | Manufacturer | ProductLine |
HotDeals | searchString) default = Manufacturer
<-> fatherName: a STRING
<-- partID: PRIMARY KEY from Parts table on RFA.removeItemFromCart
@DeveloperNote: The ampersand indicates that this will be replaced by a
value at run time. For example, a valid variable name might be
"Update_2107_1"
<-- Update_&partID&_quantity: a NUMBER on RFA.retotalCart (may be multiple)
++> [cartID]: a COOKIE PRIMARY KEY from Carts table.
+++ qryGetCartSummary.cfm
+++ incHeader.cfm
+++ incFooter.cfm
||
END FUSEDOC--->
Now, the interesting thing about this job is that all the code for this job
was done overseas. Because of the time difference and the high cost of phone
calls, the only viable communication method we had was email. As it turned
out, almost no communication was required, as the coders understood how
Fusedoc worked and the fusestub contained all the info they needed to create
the code.
Can we improve on this? If so, I welcome ideas.
-----Original Message-----
From: John Foulds [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 25, 2000 10:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Documentation System for Cold Fusion
Not only too darn hard to read, too darn hard to write, not to mention
zero-tolerance in the parser.
The main thing is just that the notation be constructed so that it can be
read and parsed by a spider which can database it.
It's easy with XML because of it's strict notation. The challenge is to
come up with a syntax that walks the line between features/parsability and
easy authoring/viewing.
Does anyone have an address for the FuseDoc spec? I can't seem to find one
(Hal, quit squatting on fusedoc.org and fusedoc.com, and put something up
there). I would like to propose a few amendments.
John Foulds
Ottawa, Canada
----- Original Message -----
From: "McCollough, Alan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 25, 2000 12:13 PM
Subject: RE: Documentation System for Cold Fusion
> Nah, I'll tell ya why I think so... The thing I like about FuseDoc is its
> simple enough where I can manually type in the fusedoc for a template with
> very little work. I've got a generic FuseDoc snippet stored in CF Studio,
> and I then fill in the blanks. FuseDoc as text is easily human readable.
> XML, WDDX, or other tagging schemes tend to have too much metadata in
> relation to the data. Too darn hard to read in Notepad or some other
> plain-text output.
>
> Its a balancing act between functionality and simplicity. But hey, doesn't
> every app we develop come under that principle?
>
> Alan McCollough
> Web Programmer
> Allaire Certified ColdFusion Developer
> Alaska Native Medical Center
>
> > -----Original Message-----
> > From: John Foulds [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, August 25, 2000 8:15 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Documentation System for Cold Fusion
> >
> > Perhaps FuseDoc should just be XML, with an external DTD residing
> > somewhere
> > common.
> >
> > But it's not the lingo of the schema that matters, just making sure that
> > an
> > engine can read from it, and then parse the documentation in an
> > application's templates and drop the results into a DB where it can be
> > utilized by other documentation programs. ie:
> >
> > *a parent/child template browser
> > *a todo list (add FuseDoc element "Outstanding Items")
> > *a template description manual
> > *a query or variable dependency browser
> > *a change management viewer
> > *an author work history
> > *etc.
> >
> > p.s. packet? So Allarian.
> >
> > John Foulds
> > Ottawa, Canada
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
