> 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 ==^================================================================
