That's what I've done, expressed dynamic variables by slapping ##s around
the dynamic part.
> -----Original Message-----
> From: Steve Nelson [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 28, 2001 1: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
