> Mach-II is based on the same general ideas as MVCF,
> namely the MVC methodology | architecture | paradigm
> | design pattern (depending on where you think MVC
> falls into the overall spectrum!).
Design Patterns -- was the definition I neglected to include in the
presentation... Which is somewhere between methodology and
architecture -- I think... :)
Though I have yet to see a framework that prevents the use of an MVC
approach. If you look at the code for the Plugin Manager and the Login
component for the onTap framework, you might notice that the way these
are designed is actually rather similar to the way I would put
together a Mach-II application -- and that all boils down to MVC --
separating the different layers of an application.
> While MVCF is somewhere slightly beyond a very basic
> methodology, since there are at least a few hints of
> framework involved,
I should probably have another look at Hediard's work... It's been a
while since I looked at it, I guess I probably didn't look as closely
as I should have, because I end up hearing more talk about MVCF than I
would have expected, especially considering that he's not really
promoting it the way we do for Mach-II or onTap.
> the major difference between Mach-II and MVCF
> is that Mach-II is a full-blown framework. This can be
> seen as both good and bad as I'm sure we'll discuss at
> the next meeting. It's a fine line between flexibility
> and mandating how things need to be done that all these
> frameworks walk, and in the end we all have to decide
> whether the benefits are worth it.
That's a certainty... And a lot of it has to do with perception... You
can get very OO behavior/functionality from procedural code and vice
versa, so the actual tools available can often reflect less on the
resulting application than you might expect. Imho Fusebox and Mach-II
have a lot more rules requirements, whereas I've tried rather hard
with the onTap framework to make most of the features optional. Good
or bad? Depends on your point of view.
There are those who say that ColdFusion _encourages_ bad programming
habbits. I disagree. I think it's just as easy to have bad habbits in
any language or framework. I'll admit that there's something to the
idea that a lot of "slackers" end up getting involved and doing CF
work because of it's being so much easier and more accessible than
other languages, but I don't think that's a negative reflection on the
language or the server by any means, I think it's just the natural
effect of having something that's really well designed / well
conceived that it's easy(er) to use and people want to use it.
So the major differences between onTap and Mach-II end up being that
Mach-II is much more stringent in its efforts to make the code conform
to a specific pattern. For instance, events are never nested in
Mach-II -- they're processed in a queue, so when you want to announce
one event from within another event, you're forced to think through
your entire request in advance and figure out how to get to your end
result. This was one of the things that tripped me up when I started
working with it, because I wanted to be able to have an event and
within it simply say "run this other event, then display this view".
But Mach-II doesn't allow this. So you have to stop, take a step back,
and figure out how it is this is accomplished. And the answer is that
instead of announcing one event, you separate your view into a
separate event and you announce two of them.
As an example:
<event-handler event="showPageX" access="public">
<announce event="actionPageX" copyEventArgs="true" />
<announce event="displayPageX" copyEventArgs="true" />
</event-handler>
<event-handler event="actionPageX" access="private">
<notify listener="blah"
method="something"
resultKey="request.content">
</event-handler>
<event-handler event="displayPageX" access="private">
<view-page name="myViewPage">
</event-handler>
Why would I do it this way instead of simply placing the listener and
the page view in the showPageX event? Code reuse. I want to reuse the
event actionPageX in other places... _but_ ... the event ActionPageX
may also need to trigger some other events dependant on conditions
known only to the listener (using the announceEvent method). Now
suddenly my xml no longer works, because content in the optional
triggered events is required to generate the view. So in order to
accomodate that, I have to also remove the <announce> for the view
event from the showPageX handler and instead announce the event within
the listener. Why? Because when the announce tag is in the first event
handler, the event is announced before the listener is notified and so
the view is then queued prior to the events which need to be triggered
by the listener, so any content generated by those triggered events
won't be available by the time the page view is displayed. Hence the
need to move the announcement of the 2nd event into the listener.
(Normally the events would probably have a few other items in them as
well, but they're not really important to the illustration.)
By contrast, the onTap framework nests events by default. So in the
onTap framework, you'd have a similar structure, but the order of
events wouldn't be as much of an issue to trip over.
my/process/index/_local/100_actionEvent.cfm
<cfsavecontent variable="request.content">
<cfmodule template="#request.tapi.process()#"
netaction="alternate/process"
attributecollection="#attributes#">
</cfsavecontent>
my/process/index/_local/200_views.cfm
<cfset view.template = "view/myPageView.cfm">
my/process/index/500_displayview.cfm
<cfinclude template="#request.tapi.getRelative(view.template,"P")#">
Now by default the cfmodule call in the first template actually nests
the alternate/process event within the current event and you're able
to get the content right away, without having to queue an event and
then antiscipate what's going on after that event. But the framework
also provides the flexibility of queueing events for later in the
request -- for a different purpose than Mach-II. The callbacks in the
onTap framework execute in the onRequestEnd.cfm template, after a
cfflush tag, and so can be used to execute long-running processes
during the request, and at the same time provide a fast user
experience.
So the onTap framework gives you more flexibility. Now wether this is
a good thing or a bad thing may depend entirely on your point of view.
Anyway, sorry to ramble on there... I got kinda caught up in thought
there. :)
> As Hal Helms says quite often though, SOME kind of framework
> or logical code organization is better than none at all!
Yea, even if it's not a framework per se, a certain amount of
consistency and code reuse is always a good idea. I think there may be
such a thing as too much (I was talking to Sean about frameworks and
got the feeling he felt Struts was too much), but too little always
results in hours of hair-pulling. :)
s. isaac dealey 214-823-9345
team macromedia volunteer http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
