> if i get a then i will also get b
>
> or
>
> if the value of fuseaction is "XFA.onSubmitForm" I set
> client.CurrentUser;
> otherwise I set client.Unregistered.
>
I wonder if it really matters if you can symbolically represent this
logic. Why not just use text comments to fill in the blanks for such
tricky situations, keeping fusedocs nice and clean.
I agree Erik,
One of the issues that creeps up constantly around our shop is too many
rules/formats to consider when you want to just write your code. Most of
the time there isn't someone who writes the specifications or prepares the
fuses. The developer plays all the roles required to get the project
working and its hard to keep the fusedocs "exactly" current when you're
faced with tight deadlines and pressure from looming bosses.
Also, trying to represent complex logic with symbols on the page where
you're representing logic seems a little repetitive. If you have a
situation involving complex logic, its more helpful ( I find ) to put some
comments directly before the code runs. This way you can see the logic and
a reason behind the logic or why that logic is there.
>From my experience, fusedocs do an excellent job at describing the "IO" of
each template but what are we improving by adding more over head to the
�preparation� of each fuse? Keeping fusedocs simple and in �people� terms
(properties, responsibilities) will provide the high level map required to
interpret the corresponding code.
What would be some benefits of trying to represent more complex logic? I
haven't run into many situations where this has even been an issue? What
are some possible usages?
Cheers,
Emilio
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
