***************************** Former Team Allaire :-)
*****************************
You've got a good point, but I personally think the logic is too much.
In my opinion the architect should never touch the logic, otherwise he
will have to spend extra time debugging the fusedoc to make sure the
logic is correct.
I don't want expensive architects worrying about that, i want peons like
Natty P and Stan Cox writing that logic.
Steve Nelson
lee borkman wrote:
>
> Hi all,
>
> I agree that these are requirements that will probably not be EASILY
> incorporated into FuseDoc, and most of use will be happy to put then in as
> text, BUT...
>
> Clearly, the more that can be expressed in a formal language, the more we
> can do in the way o automated tools, etc. So we have a trade-off - more
> formalisation=better automation, though possibly at the expense of
> comprehensibility, learning curve, acceptance, etc.
>
> So, bear with me - I just woke up seconds ago, but I have to write something
> before you all go to bed ;-)...
>
> WHAT IF there were a new optional sub-class of FuseDoc statement that
> signalled "here is a complex requirement expressed in the symbology of
> formal logic", or something like that. Of course, you can't really use
> formal logic symbols with a normal keyboard, but some substitution could be
> arranged.
>
> eg.,
>
> LOGIC
> ((x = 3) AND (exists(y)) => {
> -->[attributes.z]: the volume of a cone of height x and radius y
> }
>
> So we have a header like LOGIC, then statements of the form:
> logical_condition => {
> standard_set_of_FuseDoc_attributes
> }
>
> Now that's nasty, and I daresay that nobody would ever use it or anything
> like, but perhaps the automation freaks out there (like me, or Jeff, or
> possibly HH) might see some use in it.
>
> yawn,
> time for my wheet-a-bix,
>
> LeeBB.
>
> >From: "Hal Helms" <[EMAIL PROTECTED]>
> >Yes, I agree that those examples almost certainly fall into the category of
> >"True statements that are not expressible in Fusedoc". Sure, we could
> >create
> >a symbology that would allow us to express that, but I think you're
> >right--why bother?
> >
> >I'm more interested in the grey areas between something Fusedoc clearly
> >should be able to convey and those examples of things I think should be
> >outside the realm of Fusedoc. For example, should Fusedoc be able to
> >express
> >this?
> >
> >I'll get one (and only one of the following): a, b, XOR c
> >
> >-----Original Message-----
> >From: Erik Voldengen [mailto:[EMAIL PROTECTED]]
> >> > 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.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
