***************************** Team Allaire *****************************
I've been using ampersands for that Steve, so your example I'd write as:
--> attribute2_&attribute1&
-----Original Message-----
From: Steve Nelson [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 28, 2001 5:41 PM
To: Fusebox
Subject: Re: Fusedocs Q
I think you're right. As long as we keep complex boolean statements out
of fusedocs and keep the total amount of syntax down to a minimum.
There is also the issue of dynamic attributes like this:
--> attribute1: an integer
--> attribute2_#attribute1#: an integer
Do the #s work for that?
Steve
"Riccomi, Laura" wrote:
>
> Hi all,
>
> As the demon-originator of this thread (and now that discussion has calmed
> down a bit)...
>
> I'm not all that keen on sticking more than basic logic into fusedocs. I
> agree with lots of people here that detailed logic is for the
specifications
> section. However, I still feel that it's within reason to have some way to
> show an exclusive or situation.
>
> Reasoning:
> The current notation for fusedocs allows you to specify AND by stating
> --> Variable
>
> and OR by stating
> --> [Variable]
>
> It even allows you to specify number of occurances like
>
> --> Variable*
> or
> --> Variable+
>
> Exclusive OR is just as basic in the logic arena as the statements listed
> above and it should still be basic enough to be understood by any
programmer
> that can understand the other statements.
>
> Of course, exclusive or's aren't as common. But when they're necessary I
> think that it's more clear to state something like
> --> Variable1 | Variable2 | Variable3: an INTEGER
>
> instead of
> --> [Variable1]: an INTEGER only exists if Variable2 and Variable3 do not
> exist
> --> [Variable2]: an INTEGER only exists if Variable1 and Variable3 do not
> exist
> --> [Variable3]: an INTEGER only exists if Variable1 and Variable2 do not
> exist
>
> Now, I know I keep saying 'logic this' and 'logic that', but I'm not
really
> suggesting putting logic into the Attributes section (no, really!). I
still
> consider this type of exclusive or to be a description of the attributes
> expected. Just as
>
> --> [VariableA]
> --> [VariableB]
> --> [VariableC]
>
> says that you can expect to receive any or none of these variables,
>
> --> VariableA | VariableB | VariableC
>
> says that you can expect to receive one of these variables.
>
> While the more complex notation suggested by borkman is intriguing, it
would
> increase the learning curve; and one of the things I love about fusedocs
is
> that it's simple enough for our co-op students to learn in an afternoon.
>
> And, by the way [chuckle], I've since changed the logic in the scripts so
> that they expect to receive all of the variables with only one of them
> having a value (cuz it's a little easier on the coders -- but a little
> uglier in the fusedocs).
>
> Laura R
>
> -----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
