Sounds as though much of what you've done is FB4-ish in nature, with some bones thrown to FB3-thinkers. Nothing wrong with that approach, though I know of at least one other effort (can't remember who did it) to create an FB4 plugin that would cause FB4 to emulate FB3's layout inheritance behavior (i.e., all outputs are stored to fusebox.layout, and all layout fuses reference fusebox.layout to present content).
- Jeff On 21 Oct 2004 at 18:01, Tyler wrote: > I agree, it's not quite an implicit requirement, but FB4 does lean towards > MVC development. When I mention MVC, I usually talking about the "need" for > breaking up your fuseactions and circuits, and the handling of conflicting > content variables. You can bend the content variables to your liking, of > course, but you have to exert a lot more effort on each call which can cause > additional hassles. If you do go down the MVC road, these problems seem to > disappear. > > I wouldn't want to use strict MVC for 80-90% of my projects, because most of > my apps are built for reuse, and I don't want to have to copy 3x times the > amount of folders, when I could just copy one or two circuits per each new > installations. (I can still divvy up my inner fuseactions in a model/view > fashion if I like.) > > I personally enjoy being able to make my layout decisions after the majority > of the important processes have completed, which means I save all of my > generated content into a variable ala Fusebox3. So I found that I was > repeating a great amount of code; I was adding the same > contentvariable="SomeVar" and append="True" for every display fuseaction in > my site. Also, I'd have to build the same functionality into multiple fuses > because I couldn't call FuseActionUno directly from the browser and from > within FuseActionDos (the content variables would overwrite each other > depending on your code and the prefuseaction and postfuseaction phases would > be called on each call.) Basically just extraneous code. > > I attempted to remedy this in MOBX by treating in two ways: > > 1. I let content variables inherit each other. So if you have identically > named content variables, they would append to each other by default, instead > of overwriting each other (All of which can be further controlled with > additional attributes.) In the current MOBX demo posted on cfopen.org, I > treat <do> calls as automatic content variables and includes just as simple > includes. This worked to a point, but it was really overboard in thinking > that all 'do' verbs are going to add to the generated content. Since then, > I've added a <content> verb that adds all child commands to a content > variable, defined by the 'DefaultContentVariable' parameter. Even if the > <content> call is located inside another <content> call, as long as the tag > does not call for a different content variable, it will append or overwrite > the current content variable. > > I've created a shorthand version for 'include' and 'do' calls like so: > > <content.include template="somefile" /> > > And... > > <content.do action="SomeAction"> > <xfa name="Name" value="Value" /> > </content.do> > > You can also save to other variables besides the 'DefaultContentVariable' by > using an attribute of 'variable'. It really helps to clean up repetitive > code and leads into number two: > > 2. I treat layout files/decisions as normal fuseactions. I have a 'Layouts' > circuit, that has several different layout fuseactions. Because of my > <content> tag, I can apply or not apply the referenced-layout inline, and > not have to worry about nested content variable calls. I then added a > current request property (like myFusebox) for the current content variable > named 'ThisContentVariable' (good name, eh?), so that you can "apply" > layouts to almost any existing variable. I also added boolean properties for > IsTargetCall and IsSuperCall to assist in determining when and where to call > a layout fuseaction. > > Honestly, I can't remember how different this is from FB4. I know I added a > good amount of little benefits like IsTargetCall and ThisContentVariable > throughout the language. Originally, when FB4 came out, I started building a > project with it, and I had rather bloated code, because I had to label > almost 90% of the do calls with a contentvariable attribute and I ran into > problems when I wanted to apply a layout if I was calling a fuseaction > directly, but not if I was including the fuseaction in another fuseaction, > especially if they were both located in the same circuit. > > My plan was to get MyOpenbox up on cfopen so that some of my ideas were out > there in the public, and then I was going to build the same demo app in > fusebox 4 and be able to demonstrate the differences between the two. And > when it comes down to it, the ideas are basically the same, it's the > implementation that's different. > > Hopefully, I've gotten at a couple of the benefits across in this email. My > next release should explain the rest of the "enhancements", I'm hoping to be > finished by tomorrow or Sunday...please let me know what you think so far-> > > Tyler http://www.GrokFusebox.com "Fusebox 4 & FLiP: Master-Class ColdFusion Applications" Now available at ProtonArts.com -- Outgoing mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.280 / Virus Database: 264.12.0 - Release Date: 10/19/2004 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Purchase from House of Fusion, a Macromedia Authorized Affiliate and support the CF community. http://www.houseoffusion.com/banners/view.cfm?bannerid=34 Message: http://www.houseoffusion.com/lists.cfm/link=i:12:6583 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/12 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:12 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.12 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
