>
> Very well, I will therefore create a new version of Harness with the extra
> parsing required to handle the mutually-exclusive notation. And Hal, try
to
> get some of the grime off that crystal ball so this doesn't happen again,
huh?
> ;>
>
Jeff,
before you do that I think we might reasonably ask Hal to also comment on
the variations that flow from
this newly allowed format:
if
--> Portfolio|Cluster|Market|Region : a INTEGER
means "one of Portfolio,Cluster,Market,Region" must be passed in then what
to do about these variations:
1) "one AND ONLY one"
2) "Portfolio AND any one of the other 3"
3) "Portfolio AND NOT Cluster"
4) what you're supposed to get one and only one but you get two? three?
four?
well the possibilities are endless. Rather, one idea to consider is that
that bracket notation used for "optional" might be sufficient *with respect
to Fusedocs* and let the rest of the "rules" be defined in the natural
language description that is supposed to follow. If you have something less
common that just required/optional, such as the example that started this
thread, then perhaps the Architect should just *say so* in the varialbe
description, rather than saying "an INTEGER" only.
The bracket notation suggested of
--> [Portfolio] : an INTEGER
--> [Cluster] : an INTEGER
etc...
is consistent insofar as each variable *might* get passed in. Shouldn't the
other complex rules be in the fuse's Responsibilities section and/or part of
the variable description? That seems a lot cleaner to read, than
--> [Portfolio]|[Cluster]|[Market]|[Region]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
