***************************** Team Allaire *****************************
What other sort of things would you want to see Fusedoc express, Lee? Is it
just the case where the existence of one variable implies the existence of
something else?
What about these English statements. Should they be expressible in Fusedoc?
1. Create a client variable called CurrentUser if we get an incoming
variable called userID.
2. You're going to get in a variable called "Substitute_xxx" where xxx is
the name of a productID.
3. You are going to create a client-WDDXd structure called Users with keys
for every user returned by a query. If there are more than 50 users, you
need to divide this into multiple structures so that no one has more than 50
users. Name the structures Users1, etc. and if there is more than one create
a client variable called "NumberOfStructures".
I'll wait to see what you (and others) think about these before offering any
more.
And me, an agent provocateur? Never! Well...hardly ever.
-----Original Message-----
From: BORKMAN Lee [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 28, 2001 12:26 AM
To: Fusebox
Subject: RE: Fusedocs Q
Hi "Q",
I agree that you don't want to tell the coded HOW to do the job. The
conditional FuseDocs I am proposing, however, certainly in my more recent
(ie awake) version, are used exclusively for defining which inputs and
outputs are required, and precisely when. There is no attempt to define how
this should be accomplished, and the internal workings of the Fuse can still
be treated as a black box:
*************
-->[personID]: the primary key of the person record
IF (not(exists(personID))) {
-->surname: the surname of the person in question
-->zipCode: the person's zip-code
}
<--phone: the phone number of the person in question
*************
I also suggest that many coders (ie, the kind of people that would ask to
build your fuse) will find this easier to understand than a potentially
ambiguous bit of free text (how many of us are highly-skilled err ummm...
wordsmiths?). I can also guarantee that any kind of automatic validation
tool will find it easier to understand. In short, if it's not-real-hard to
write and not-real-hard to understand, then I'd prefer a formal language
every time.
Anyway, it's certainly gratifying to live so far away that I'll never meet
one of you in a dark alleyway ;-)
Thanks again,
LeeBB
-----Original Message-----
From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]]
.....
It seems to me, and here a lot of you will hear my most latest refrain, is
that the Fusedocs should be designed to tell the developer WHAT the template
will do, not HOW to do it.
.....
IMPORTANT NOTICE:
This e-mail and any attachment to it is intended only to be read or used by
the named addressee. It is confidential and may contain legally privileged
information. No confidentiality or privilege is waived or lost by any
mistaken transmission to you. If you receive this e-mail in error, please
immediately delete it from your system and notify the sender. You must not
disclose, copy or use any part of this e-mail if you are not the intended
recipient. The RTA is not responsible for any unauthorised alterations to
this e-mail or attachment to it.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
