I understand exactly what you're saying and I went through the same questions when i first started with Fusedocs. Here's what I found.
Say you wake up in the morning and BAM! a new idea hits you, instead of submitting information to the database on that multistep form, you can just pass a WDDX recordset from page to page. Hmmm, but you've already coded it, it *sort of* works. What to do? Say you've got 5 fuses that need to be modified. Open up the first fuse, STOP. Now, think about what you're going to change. Don't just jump into the code. Sit and think for 1 minute, that's not a big deal is it? You do that anyway right? Think about this new WDDX variable that will be passed into this fuse, modified, then passed out. Now, instead of jumping into the code. Right down what you thought about for that 1 minute.... Update the fusedoc as you see fit. Now, go into the other 4 fuses and do the same thing. That WDDX variable will be passed from fuse to fuse. Before you start coding ANY of those 5 fuses, just sit and think for 1 minute, then write down what you're going to do. Jumping into the code before you figure out what you want it to do can be dangerous, and while it may feel counterintuitive, it's a VERY slow development process. If you map out all 5 fuses first THEN code them, you know EXACTLY what to code. So instead of experimenting on those 5 fuses, you just code what the fusedoc says to code. So here's a deeper question I think you might be asking: "How do you fusedoc something if you've never done it before?" If that's what you're asking, how about this. Practice first. Architects in the building industry don't just start building skyscrapers, they go to school, they do an apprenticeship, etc etc. Don't just jump into the production code and start messing with it. If you've never played around with WDDX and you're positive you want to use it. Don't make that change to your production code until this is AT LEAST the second time you've used WDDX. Hop onto your development machine and start dreaming up different scenarios for using WDDX. Learn it, understand it. Just do that learning before you start messing with your production code. Get to the point where you understand what you're going to do well enough that you can write it down into a fusedoc. Then code. Steve Keith Young wrote: > > Steve, > > I will confess to not using Fusedocs the way they are meant, but I have always >wondered, do you find you have to go modify the fusedocs you pre-wrote for an >application very often? > > For example, the application I am working on right now, I started with one method of >passing variables around from page to page. Then proceeded to a second method, and >finally a third (which I now believe is the best way for the complexity of the forms >I am using). If I pre-wrote the fusedocs I would at best have to modify it once to >match my final method of handling, and in a worst case I would modify it every time >thinking that "this time" I am doing it the best way. > > Perhaps my perspective is merely one of not having years of dynamic web development >behind me? That as time goes on I would find the need to go back and redo whole >sections/pages of code to be better would lessen, and therefore I could approach the >"write the doc, code the doc" (once), levels of achievement? > > I have stayed away from fusedocing because I know that I will go back through my >code several times and it will end up potentially different, or I may have completely >overlooked a component I needed and have to add it in later. > > I'm not sure what the answer to my ponderings above should be... I *know* I would >like to "code the doc", but I am not sure if it of large benefit when I go back and >rewrite code alot to be better... > > Cheers, > Keith. > > >>> [EMAIL PROTECTED] 05/23/02 09:43pm >>> > Rey Muradaz wrote: > > > > Yes, but that info would be pretty helpful if you're trying to add on another >floor, don't you think? (BTW, I hope you're not saying that all of your development >projects end up in a heap of wreckage . . . :). > > > > Maybe, maybe not. I've tried this two ways and they both seem to work about the > same, but for different reasons. I've tried one way where I make changes to the > prototype, then use the existing fusedoc to modify the new one. I've also tried, > making changes to the prototype, scraping the old fusedoc and refusedocing the > changed pages in the new prototype. I guess it has to do with how much you're > changing in each fuse. If you're changing a lot, that old blueprint will just > slow you down. > > Here's an analogy. My mother has been a home renovation architect for 30 years. > If the house she's working on will be ripping off the roof to put on another > floor, having the blueprints for that roof won't do her any good. She just needs > measurements to create the new blueprints. The NEW blueprints get submitted to > the engieers for structural review and the builders to build the new floor, not > the old ones. > > > Documenting up front is the best, but documentation at *any* point in the process >is still useful when you have to pick up someone else's work weeks, months or >(yikes!) years later. > > I'd say it fully depends on the type of documentation you get. Stupid > documentation does you nothing regardless of when it's written, like this: > > <!--- loop over query ---> > <cfloop query="somequery"> > > or > > <!--- setting first_name variable ---> > <cfset first_name="Steve"> > > That just won't do you any good. Now Fusedocs documentation at any point in the > process... it might help it might not. I'd still start with the wireframe, go to > the prototype, fusedoc, fusecode and unit test, regardless of how much was > already built and working. If *some* of the fusedocs were already written, then > great, it helped. If you added new stuff, new fusedocs would need to be written. > > btw, as far as wreckages go. Sure, i've had my share of wreckages, and my share > of successes. My biggest flop crashed 2 weeks before we were going to sign a > contract for $26,000,000 (that's a lot of zeros!!). That was the day I began to > really take Fusebox seriously. > > Steve Nelson > > > > > REM O- > > > > >>> [EMAIL PROTECTED] 05/23/02 12:36PM >>> > > Is it? Knowing how much weight a steel beam can hold seems pretty pointless to > > me.... if the building has already collapsed. > > > > Steve Nelson > > > > "Benjamin S. Rogers" wrote: > > > > > > > Steve is right; documenting post-development is pointless; > > > > Fusedocing up front is powerful. > > > > > > Pointless? That's a bit extreme, isn't it? > > > > > > Benjamin S. Rogers > > > http://www.c4.net/ > > > v.508.240.0051 > > > f.508.240.0057 > > > > ==^================================================================ 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 ==^================================================================
