Oh yea, definitely fusebox related. MyOpenbox is how I would improve Fusebox 4, it's my implementation of suggestions I've come up with from working with Fusebox 3 & 4, or heard throughout the last couple of years. I'm not claiming 100% intellectual originality or anything of that sort. I built a new set of core files (a CFC) that allows me to develop how I'd like to develop. I started off trying to keep everything 100% Fusebox 4 compliant. Which was rather easy because all the hard work is done up front, but then I decided it was the ideas and features that were important. And if I could get those across, that would be good enough for the Fusebox community.
Some of my tags and verbiage will probably be able to be incorporated with the new custom verb lexicon, but I haven't checked that out yet. Other things might not fit into the current structure of FB4, and most likely never will. Tyler -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, October 22, 2004 1:08 PM To: Fusebox Subject: RE: Test 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Get the mailserver that powers this list at http://www.houseoffusion.com/banners/view.cfm?bannerid=17 Message: http://www.houseoffusion.com/lists.cfm/link=i:12:6584 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
