while i don't want to give your two cents back (every penny counts, har har)
this idea is only about halfway to where i'm going. i'm thinking about
adding something like a <link> element (or method) that would allow fusedocs
to refer to one another. your qry_findcar.xml example doesn't necessarily
alleviate the work it would take to keep however many files updated based on
one change in one line of actual code, like adding totalSalesVolume to the
selectlist in the member profile query.
with cross-references we may be able to advance fusedoc parsers to the point
where they can include or hyperlink to the sub-fusedocs that outline common
queries or variable sets.
another example of where this may come in handy is server variables: they
really need to be documented in only one place, so that when one is set by a
process,thus becoming available to all other processes on the server, those
other processes know they have it.
e.g.
<out>
<string src="serverVars.fd2">
</out>
ecd
<feel free to snip>
----- Original Message -----
From: "Lee Foster" <[EMAIL PROTECTED]>
Sent: Thursday, June 20, 2002 2:35 PM
| I'm still thinking of just making a reference to the fusedoc file in
| template as a comment, ie
| "C:\website\cardealer\fusedoc\search\qry_findcar.xml". This would keep
the
| template file size drop, decrease the parsing time and just make the whole
| thing run faster. I know when you are developing most people don't like
to
| have to go and open a new file. That it is better to find it all there.
| But once the site goes live you should have a hundred lines of fusedocs to
| parse through. At that point it would be better to keep it in a totally
| separated file.
|
| Just my 2 cents. Take it or leave it.
| -----Original Message-----
| From: eric davis [mailto:[EMAIL PROTECTED]]
| Sent: Thursday, June 20, 2002 1:28 PM
|
| a co-worker and i were having a ...conversation about fusedoc'ing
| recordsets. we've got an app, called as a custom tag, that handles our
| checkout process. as you can imagine, the 'order' query and the 'cart'
query
| hold quite a fiew fields, and are still open to field additions. there are
| 24 files in the directory, and they are nearly all involved in
manipulating
| those recordsets or detecting processes based on the data in those
| recordsets.
|
| still with me? good.
|
| that means that nearly all, if not all, of these files must contain the
| outline of the order and/or cart queries in the fusedoc.
| <recordset name="order">
| <string/number/boolean> (repeat oh, 75-100 times)
| </recordset>
| <recordset name="cart">
| <string/number/boolean> (repeat oh, 75-100 times)
| </recordset>
|
| that's a lot of code to update when i add one field to the select list on
| either query page.
|
| i'm thinking we need some way to externally contain fusedocs for large
| recordsets or commonly called variables across an application or
directory,
| and a way to refer to these external sources. granted, you won't have the
| outline of the query there immediately when you open the file, but- and
hear
| me out- after maybe a couple weeks, you'll be used to looking for that
other
| filetype or prefix. after a few months, there will be no files that refer
to
| or have available these queries that also contain out-of-date fusedoc
| outlines of the recordsets.
|
| <recordset src="docQryOrders.cfm"> or <recordset src="qryOrders.fd2">
|
| contained in either <in> element (for pages that process the queries) or
the
| <out> element (for query pages to define by).
|
| comments? suggestions?
|
| i'm still waiting, erki, to hear back on how to get into the
| [EMAIL PROTECTED] list.
|
| thanks!
|
| ecd
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
