Hi there,
I think that my major point about extending FuseBox may have got lost
somewhere along the way...
We are now reaching the point where some architects want to define some
RELATIONSHIP between various parameters. That has not, until now, been a
part of FuseBox.
For example, we now have a new proposed syntax for saying "at least one of
these parameters must be present".
Hal has also asked for suggestions for encoding "if parameter A then
parameter B", and other similar ideas. )I suspect he is playing the agent
provocatuer.)
What I am proposing is that it would be unwise to try to create a new kind
of syntax for each new relationships that springs up. Better to create a
single more general optional construction that can encode ALL of these
relationships. My first stab at this kind of general construction is this:
IF conditional_expression {
parameter_specification_1
parameter_specification_2
parameter_specification_3
...
}
I make no claims that this is good or optimal. But accepting some
equivalent form may curtail an endless series of ad hoc "enhancements". In
the long run, I think that conditional specification may be more manageable,
comprehensible, and flexible than:
--> x | y | z
<-- (x|y)&!(z|y)
--> (x=>y) && (y=>!(z|x))
On the other hand, I do not believe that my suggested construction would
ever be used very often. And I don't think that anyone will be missing out
by not using it. But I don't think that anyone would be terribly confused
if they received a FuseDoc spec that included this kind of language. In
fact, they might be LESS likely to go back to that architect and say "sorry,
I'm not sure when this output is required". Who can say?
Thanks,
see you later,
LeeBB.
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
