Though I have yet to see a framework that prevents the use of an MVC
approach.

True--some frameworks just support it (or "force you to do it" if you're taking the negative side) better than others.


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.

From personal experience I've seen FAR more bad ASP code than CF, and
procedural Java code abounds, so you're right--bad coding is language-neutral.

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.

Yes and no--you can of course have events call other events in places other than in the XML file, so I don't think it's quite as limiting as you may think. I'll address this more in your example below.


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.

Maybe I'm not understanding what you're saying, but this is certainly allowed. If you think of it this way, the view is the end of any process. You can call events all day long before your display happens.


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.

Again, I may be misunderstanding, but I think you may be approaching this the wrong way, or at the very least there's more than one way to skin a cat. You don't have to do all these sorts of things in the XML file as you're doing it here. In other words, you don't have to have an event for actionPageX in order to reuse it (and this may be a semantic issue, but when I write Mach-II code I no longer even HAVE "action pages"), you can do all this with listener methods.


In other words, in order to accommodate what I think you're saying, you might end up writing a method in your listener to handle things in a particular way, and the beauty of this is you can write extremely granular listener methods and then write a listener method that calls these other methods and groups them as you want. The XML file doesn't necessarily have to be the be all and end all of what happens in what order. So in short Mach-II doesn't prevent you from doing anything, it may just be that you're focusing too much on the XML file as opposed to utilizing the CFC listeners to handle more of the work.

As an example (and this will show if I'm off-base in terms of what you're saying), let's say I have a page that runs some queries to get data for some drop-downs. Each of those queries could be announced as an event as you illustrate above, OR each of those could be called as methods within a single listener. The code reusability is the same--I either announce an event or call a listener method. I can do that as many times as I want or in any order I want before I display the page.

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.

Again, what you're saying may be true, but this isn't the ONLY way to do things. I could equally say that in onTap execution of things is forced, and that you're forrced into nested events, although I know from your talk last night that this isn't *necessarily* true. It all depends on how you do things.


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.

But isn't this where the numbering comes in? If I want things to happen in a particualr order, don't I *have* to prefix my page names with numbers? Six of one, half dozen of another I know--just pointing out that order may matter, it may not, and you can accomplish both in either Mach-II or onTap.


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.

This may be true from your perspective, but I think you may be limiting your view of Mach-II a tad. I have not run into anything in Mach-II yet (with four semi-large projects under my belt) that has forced me to do anything in a particular way. As we said after the meeting last night, I think maybe I'm just used to using CFCs a lot more heavily since I come from a Java background, but I'm not convinced Mach-II is limiting in the ways you describe. Please clarify if I'm misunderstanding, and at least we'll have some good background for my talk on 2/10.


Thanks,
Matt

_________________________________________________________________
Rethink your business approach for the new year with the helpful tips here. http://special.msn.com/bcentral/prep04.armx


-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org




Reply via email to