Hi Steve, > Fusedocs indirectly tell you what the database needs to look > like. By knowing what data you need in your site, you know > what data needs to be stored.
Hmmm... that's interesting. I have been looking at it the other way - you don't know enough to start writing Fusedocs until you understand the data you are storing. I look at the requirements for the app - say there's an events listing - I then figure out I need to store the name, venue, time, ticket price etc. Then I say well, ticket prices are fixed in categories so that should be a separate table... and so on. Once I figure out everything I design the database, THEN design the app. Too late now but next time I might try it the other way - I'm not really sure how it will work though :) > the fuses can be coded without the database even built. that > means your programmers aren't sitting around waiting for the > 5th normal form to be figured out. Instead they are building > the fuses that do not need the database. I guess it depends on the scale of your apps - maybe I'm thinking too small a scale. This app will involve me and another coder (not counting html, graphics etc) pretty much full time for about six weeks. *I* think it's big... but in the grand scheme it's probably not. The complete database design took me about three full days. > I'd suggest creating an data alias map, which is something This sounds like the kind of thing that would fill the gap, I guess. No sneak-previews? > btw, when you do finish your fusedocs, buzz me, i'll help you > test them. This testing process will save you if you're > having someone else doing the coding. Great, thanks! Kay. > > Kay Smoljak wrote: > > > Hi all, > > > > I'm working on architecting a large app where someone else will be > > doing the bulk of the CF coding - in the past I've written FuseDocs > > for other people to write the HTML but never the whole thing. I'm > > curious as to the process other people go through when > beginning a big > > project. > > > > I got the client to work with a wireframe (which they hated!), then > > created a mind map. Using this I worked out the database > design, then > > created the database and generated a document that is essentially a > > huge fusedoc with all the database fields in it. Then I used a > > modified fuseminder to roughly generate all the files and switches, > > and now I'm going through and writing the fusedocs for each fuse. I > > use the database fusedoc to cut and paste the variables into the > > individual fusedocs. > > > > It's working out ok, although it's a long laborious process > - I never > > realised how slack I got when I knew I was writing the fusedocs for > > myself. But because the database has already been designed, I keep > > feeling like I should include some actual db infomation in the > > fusedocs to make it clearer to the coder (who is new to CF > as well as > > Fusebox!) - things like when a field is from another table > etc. At the > > moment I am indenting the fields that are coming from a different > > table, for my own reference as well. > > > > I know that the reason why the fusedocs don't have database info is > > because in theory the database may or may not be defined > already when > > they are written - which is fine. But my databases are > always already > > designed - I consider that one of the first steps once I > know what's > > going to be involved in a project. I also like to add a length="" > > attribute to my strings, so that the html person knows how > big to make > > the field. If the database is not designed, that would > stuff up that > > info as well. > > > > So how do other people do it differently to combat this? How many > > people are actually designing their databases *after* the app is > > designed - and what's your reasoning? How much do you leave > up to the > > fusecoder - am I trying to hold their hand too much? > > > > Thanks if you got this far, > > Kay. > > ______________________________________ > > Kay Smoljak Web Developer > > Custom Tags: developer.perthweb.com.au ==^================================================================ 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 ==^================================================================
