"I think we manage to get away with it as long as a fuseaction for the most part does nothing but include fuses, we don't allow fuses to include other fuses and we don't allow a fuseaction to include a fuse from another circuit. If we deviate from those rules even a little bit our code becomes hard to maintain."
hmm...now that i'm getting in to developing fusebox apps more i'm definitely not following this approach. I have my act fuses call various qry fuses depending on certain factors. They then do conditional logic, perhaps call another query, and set up variables based on the results. Do you guys put all this conditional logic within the index.cfm switch statement? Where else would you put it? i have to put it somewhere. Oh, i'm using fusebox 2 right now (need to finish the app before can think about converting to 3). Generally my fuseactions look like this: case blah: include act_setup (sets up the fuseaction, does any validation, runs necessary qry fuses, etc) include dsp_page (actually display the results) I actually prefer this type of approach. It leaves the index.cfm pretty lean, and easy to read and I personally think maintenance is a lot easier because of this. I definitely wouldn't let fuseactions use individual fuses from a different circuit, but i can easily see calling a different circuits fuseaction (especially fuseactions which only have act fuses). But i havn't had to do that yet, so havn't given it much thought, though that's gonna change since i just copied over some code from another circuit that could easily be generalized. I'm also a little lost in where you say fusebox flies in the face of conventional wisdom since all fuses in a fuseaction share the same data. Why shouldn't they? I thought the point was that fuseactions themselves were logically distinct, but the fuses within the fuseaction work together to get the job done. Sharing data between these fuses, at least for how i'm coding, is almost always necessary. If i'm worried about trampling data, i use a module call instead. Apparently i'm doing things in a whacked way so enlightenment is welcome. :) Of couse, the usual newbie disclaimers apply to everything i say. :) Bob >>> [EMAIL PROTECTED] 06/05/02 07:47AM >>> > Hal wrote: > > The problem you stated, Patrick, is the one that led > me to embrace the idea of FuseQ for MVC. Since all > fuses in a FuseQ request are in the same lifespan, the > problem of caller v. variables scopes goes away. Using > FuseQ, a VIEW calls the CONTROLLER that sets one or > more fuseactions into the FuseQ. I have no doubt that FuseQ makes your approach easier, and my problem is really the approach itself. Conventional wisdom says that each fuseaction should have its own data and that one fuseaction shouldn't be directly writing to another's data. Of course, Fusebox flies in the face of conventional wisdom by having all fuses in a fuseaction share the same data. I think we manage to get away with it as long as a fuseaction for the most part does nothing but include fuses, we don't allow fuses to include other fuses and we don't allow a fuseaction to include a fuse from another circuit. If we deviate from those rules even a little bit our code becomes hard to maintain. As our apps become more complicated, it becomes increasingly difficult to stick to those rules. And if we do stick to them, as I said before, we end up with a lot of duplicated code. Do you agree so far? I think we've each broken the rules by allowing one fuseaction to include/queue/call another one and allowing data to be shared across circuits. The difference is that I'm also removing the need for those rules by submitting to conventional wisdom and encapsulating my fuseactions. I just don't think FuseQ can produce applications that are easy to follow and maintain. But maybe this goes back to the methodology. Whereas you lack structure in the code itself you have a lot of supporting documentation. I can imagine that if I was responsible for maintaining an app built by John and Hal I would rely heavily on the Adalon and/or mind maps. Also, I build apps one fuseaction at a time (read: emergent design) and I can't imagine trying to do that with FuseQ. But I'm sure it wouldn't be hard if I designed apps using a top-down approach. In fact, now that I think about it part of the reason that with not encapsulating our fuses is that we document the interface with fusedocs. Well, that's something I never really thought about before: Less structure in the methodology requires more structure in the code, and vice versa. Does that make sense or am I thinking too hard so early in the morning? Patrick ==^================================================================ 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 ==^================================================================
