views:

259

answers:

6

Do you fire ajax requests through the MVC framework of choice, or directly to the CFC?

I'm leaning towards bypassing the MVC, since I need no 'View' from the ajax request.

What are the pro's of routing ajax calls through MVC framework, like Coldbox?

update: found this page http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbAjaxHints but I am still trying the wrap my mind around what benefits it brings over the complexity it introduces...

+1  A: 

The purpose of the "view" in MVC frameworks is to show the data after the "model" and "controller" have generated it. If you don't need the "view", then what's the point of using such a design pattern?

Luca Matteis
The only point I can think of is that MVC framework would have the singleton services readily available, and maybe some authentication support... not sure if I'm missing any other benefits, if any.
Henry
But why wouldn't you need the "view" for ajax requests?
Luca Matteis
A: 

I agree with Luca. It also bypasses any kind of sanitization and filtering logic you have in your MC stack. It basically negates any kind of query processing that you may or may not have in place.

Cody Caughlan
+3  A: 

Henry, I make my Ajax requests to proxy objects of my model. Typically, I am outside of a 'framework' when doing so. That being said, it may be (very) necessary to utilize your framework, such as working within a set security model.

Steve -Cutter- Blades
*Every Single Time* I've tried to go to a CFC directly, I've regretted it. Cutter's point about security is not one to be taken lightly. You mention ColdBox and "complexity", but I fail to see how going through a proxy adds complexity. For me, it has simplified things greatly: add a new function into the proxy that delegates to whatever code does the real work, and then render the result. This is where frameworks like ColdBox shine.
marc esher
+3  A: 

I can't really see any benefit of bypassing the MVC framework - in combination, those three elements are your application.

Your ajax elements are really part of the view. As Luca says, the view outputs the results of the model and controller.

Look at it this way - if you made an iPhone-friendly web interface (that is, a new View), would you bypass the model and controller?

Antony
+2  A: 

Luis Majano, creator of ColdBox said:

These are the two schools of ajax interaction henry.

I prefer the proxy approach because it adds the following:

  1. Debugging
  2. Tracing in the debugger
  3. AOP interception points
  4. Security
  5. Setting availability
  6. The proxy will relay to the event model, so I can use local interception points, local AOP, plugins, etc.

In other words, it can be a highly monitored call instead of a simple service cfc call, which you can still do.

I, for one, love to have my execution profiler running (part of the coldbox debugger), so I can see when ajax requests come in and when they come out. I can see the data requested and the data sent back. I don't have to look in log files, or try to imagine results or problems. It really helps out in debugging.

However, it would be a developer choice in which way you decide to go. My personal preference is to always use my proxy to event delegation because it gives me much more flexibility, debugging and peace of mind.

Henry
A: 

Yeah, I wouldn't bypass your framework, figure out what's causing you grief and hunt down the offending pieces, adding logic to exclude common components such as headers or footers, and looking for methods injecting whitespace that while fine for html is annoying or down right problematic when parsing json.

Adding output="false" especially in your application.cfc and it's methods would be the first thing I cleaned up.

I am a strong believer in NEVER directly accessing the CFC's directly, I find it creates long term problems when a major refactor might want to consolidate or eliminate components, the direct accesses potentially make this harder than it should be, especially if a third party is hitting your ajax from another domain(e.g. flash remoting).

+1 to Steve's answer.

np0x