I've tried to do that, but I've always found that people who write qry_
files (and act_ files that do updates/deletes/inserts) should have a copy of
the DB schema on hand, and it is up to them to extract the data however they
need. I don't want to define which tables should be used for the query - I
let the smarter DB person do that. Also, since much of my DB access is via
stored procedures, there is no need to describe anything about db
interaction in the fusedoc, because the only interaction is via the SP name,
which I always name the same as my file. (qry_ReturnValues.cfm runs a SP
named "ReturnValues", and I set the procresult name to "ReturnValues").
NAT
> -----Original Message-----
> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 9:58 PM
> To: Fusebox
> Subject: Re: Fusedocs and database objects
>
>
> It would be in query files. It's just a way to remember which
> tables/views/SPs you were thinking about using when you wrote the
> Fusedoc.
>
> Steve
>
> Hal Helms wrote:
> >
> > Steve, is this for when you don't include a qry file? Or would
> this be on
> > the qry file itself?
> >
> > Hal Helms
> > Team Allaire
> > [ See www.halhelms.com <http://www.halhelms.com> for info on training
> > classes ]
> >
> > -----Original Message-----
> > From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 26, 2001 7:40 PM
> > To: Fusebox
> > Subject: Re: Fusedocs and database objects
> >
> > I just wanted to bring this thread back to the surface... I just added
> > this ||Database Objects|| section to my fusedocs and so far it's
> > awesome! Made development 'that' much faster. I'm curious to know how
> > well it would work in a distributed environment.
> >
> > Steve
> >
> > Steve Nelson wrote:
> > >
> > > Has anyone come up with a good way to describe which tables/store
> > > procedures/etc are necessary for a fuse from within a Fusedoc? I'm
> > > thinking maybe something as simple as the Fusedoc below (note the
> > > "Database Objects" section). I think by knowing which tables the Fuse
> > > will be using will be enough information to obtain fields and such by
> > > looking in the db.
> > >
> > > <!---
> > > || BEGIN FUSEDOC ||
> > >
> > > || Properties ||
> > > Name: act_updatecoworker.cfm
> > > Author: [EMAIL PROTECTED]
> > >
> > > || Responsibilities ||
> > > I will update the roles that a coworker plays in an application
> > >
> > > || Attributes ||
> > > -->attributes.application_id an integer
> > > -->attributes.roleslist a comma list
> > >
> > > || Database Objects ||
> > > FuseCAD_Coworkers: a table
> > > FuseCAD_Roles: a stored Procedure
> > >
> > > || END FUSEDOC ||--->
> > >
> > > P.S. Wait until you see my Fusebox CAD tool. OH BABY! It's 100+
> > > Fuseactions of PURE Fusebox Adrenaline!
> > >
> > > Steve Nelson
> > > You're not smart enough!
> > > http://www.secretagents.com/training
> > > (804) 825-6093
> > >
> > >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
