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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 21, 2004 1:40 PM
To: Fusebox
Subject: Re: Test
I think there's an unfortunate misconception with regard to FB4 and MVC.
John Q and Hal teach the gospel of MVC at the same time they teach FB4,
leading many to believe that FB4 necessitates the flavor of MVC advocated by
them. This is not so.
The only real aspect of FB3 that FB4 doesn't have is the hierachical nature
of layouts, based on physical directory structure of the app. The FB4
layout method is much more flexible. It allows MVC a la Hal/John to be
implemented much more easily than FB3 did, but it doesn't require that you
work that way.
There are plenty of ways to implement MVC as a design pattern. Fusebox has,
in essence, always been somewhat MVC in nature, in that we segregate
database/action (Model) and display (View) code, and the Fusebox file is the
controller. The Hal/John approach just explicitly renders this relationship
in separate directories--an approach I don't take, generally speaking.
All that said, I'm glad to see there are active explorers out there. Tyler,
how does your approach to MVC differ from that commonly seen in FB4, and
what does MOBX solve in that regard?
- Jeff
On 21 Oct 2004 at 11:36, Kay Smoljak wrote:
> On Wed, 20 Oct 2004 16:48:57 -0400, Tyler <[EMAIL PROTECTED]>
wrote:
> > MyOpenbox is a CFC based framework that follows a good amount of the
> > Fusebox
> > 4 language and conventions. The MVC aspect of the FB4 didn't gel
> > with the way we write and re-use circuits, so I decided to create my
> > own version of Fusebox that allowed me to test out some enhancements
> > I had been thinking of, most of which were from the Fusebox 3 timeframe.
>
> Just for the record, I think this is a great idea. A dis-inclination
> to slice up really simple apps - my bread and butter - with the MVC
> approach is what has kept me from fully embracing FB4. I haven't
> really looked far into MOB yet, but I might yet.
>
> --
> Kay Smoljak
> http://kay.smoljak.com/
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
The annual ColdFusion User Conference is being held Sat 6/26 - Sun 6/27/04 8am-5pm in
the Washington DC Area.
http://www.houseoffusion.com/banners/view.cfm?bannerid=44
Message: http://www.houseoffusion.com/lists.cfm/link=i:12:6582
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
