CFML, Clojure, Software Design, Frameworks and more...

Event-Driven Model Framework?

October 23, 2007 ·

As folks start adopting more AJAX and Flex for their applications, I see a lot of questions about "how to use <insert favorite HTML framework> to handle AJAX/Flex calls?"
This is based on two things (in my opinion - putting on my flame-retardant suit)...

A fairly fundamental misunderstanding about how AJAX/Flex work

An unnatural attachment to one and only one tool of choice

I'm not going to address the first issue beyond referring people to this excellent blog post by Brian Kotek about data requests vs content requests (again - I blogged Brian's post back in July).
The second issue is an interesting one for me. The reason why folks want to continue to use XYZ framework for AJAX/Flex that they already use for HTML applications is that they've gotten used to the whole MVC pattern and the organizational benefits it brings to their applications. They've also gotten used to the event model (in Mach-II, Model-Glue and ColdBox at least) and they like wiring together their control logic in this way.
Of course, the bottom line is that those frameworks are really designed for creating HTML applications and, at a stretch, XML data - but what AJAX/Flex really need is to talk to CFCs, passing data in and getting data back.
This brings me to a question: would people be interested in a framework intended to support AJAX/Flex data requests that implements an event-based model like Mach-II, Model-Glue and ColdBox?
If so, what would you want to see in such a framework?
This framework could sit between those HTML MVC frameworks and your business model (and allow for a much simplified controller layer) as well as exposing a remote API for AJAX/Flex.

26 responses

This is definitely something that would interest me. While playing around with AJAX data requests I've never quite got my head around accessing my CFC's and the resulting solutions have been cumbersome (harking back to my days of spaghetti coding).

A unified approach would be excellent, but would you make it library agnostic or tie it to a single library (Spry, jQuery)?

I guess I'm not sure why you think there should be another MVC framework as an intermediary? Brian's post (if I remember correctly without re-reading it) stated that data requests (something you might use an ajaxproxy for) should be routed through a remote facade and content requests can be routed through the controller. How much more could the controller be simplified?

I understand the difference between using a framework for content and ajax/flex for data, but the thing I'm curious about is how you secure those ajax/flex calls to a CFC's remote methods to an authenticated user? I admit I haven't looked into that, but I don't see anybody talking about that part either. Could this be one reason why people are not using ajax/flex properly?

@James, it would be a service framework so it would, by definition, be library agnostic (it would work with Flex or any AJAX library).

@Todd, it would not be an MVC framework. You could use it with any MVC framework. See CoolJJ's comment about securing remote calls.

@CoolJJ, yes, this is part of the motivation. When folks use MVC frameworks to build HTML applications, they often wire their security into that layer and then find it hard to figure out how to apply security to the service layer. If security etc could easily be wired into the service layer, it becomes more reusable (across different UI treatments).

ColdSpring's AOP and its Remote Factory go some way toward this but since people are getting used to an event-driven approach for their HTML applications (through Mach-II, Model-Glue and ColdBox) and an event-driven approach for their Flex applications and, to a lesser extent, an event-driven approach to their AJAX applications, it seems a better fit to offer a way to build rich services using an event-driven approach as well.

Sounds interesting Sean. Could you whip up a UML or sequence diagram that lays out what you're thinking? I think it would help if I could see more about what you have in mind (even if it is very basic and preliminary).

We aready use AJAX with our Model-Glue application. The AJAX calls an event in MG, maybe passing some form data, and updates parts of the page. You just need to have events that are more focused, yet they can still be combined for traditional navigation. Works like a champ. Another thing we do is to put a handler/service layer between the controller and model. We make the MG controller only determine the view flow and the handler/service the data flow. The key is to keep the separation, so the handler does not know about the view event but is more data event driven. We can then expose 90% of the event logic to either ajax, flash/flex or web service. Its does make for more code and sometimes just pass through controller functions but in the end we are not tied to a specific view layer.

@RyanTJ, did you read Brian's article? Yes, you can use AJAX with an MVC HTML framework to render HTML page fragments and that works really well but I'm talking about data requests. I'm focusing on the service layer (trying to make that richer / easier to build). Sounds like you have a good architecture (and one I wish more folks would adopt!).

Sean, I think I understand now. We don't do a lot of data requests today but our handlers only return data to the MG controller. Here are some ideas based on that. (I'm assuming this is a server side framework): * if its replacing my UI controller then it may need an event to listener style setup/config. So you can define a method or cfc to run. * a service locator method (for getting model/services rather than wiring) Like we use one to get ColdSpring beans. * a global on request start/end style method. * a global error handling or error object.* Not sure but a data formatting/serialization method may be needed.

So maybe some flow like: request start, listener, data formatter, request end. With things like the error handler and service locator being done as needed.

The flow would be less procedural - everything would be triggered by events (some &quot;system generated&quot;, some application generated).

Good feedback, thanx.

A bit more background: this will almost certainly be CF8-only (because I think I need both threading and onMissingMethod() for what I have in mind - perhaps Railo can support this, not sure whether New Atlanta are adding onMissingMethod()?). The event model will support synchronous and asynchronous operations.

I like the idea of Fetching Data through a remote service framework. At the moment, there are a lot of one-off approaches of differing quality.

I would prefer a consolidated community approach to this as I think it would help ensure overall software quality, level the playing field for newer folks and further encourage best practices in the community.

This sounds very much like an I idea I have had bouncing around for a while now. I was origanaly thinking of it as a replacement for the front controler frameworks. I relized about a year ago that and event drive model is what I was looking for as you are talking about here. I will see if I can put some notes together here in the next few days on the type of problems that I was looking to solve.

Sean,I can't say I'm terribly interested in another framework, unless it brings something truly unique to the table. This project sounds like a great add-on package or plug-in to the existing frameworks. Somewhat side-by-side makes sense to me, so I could have a controller for my HTML output and a controller for raw data output, so the two wouldn't have to be far apart, written in separate frameworks.

At worst, this would be a forked framework project. At best, it would be a best practices document, basically, no code written, and extensive horn blowing for how to use something like ColdSpring's remote stuff and tie it in with your application.

@Nathan, that's good feedback and I do see it more as something to be used with other frameworks rather than replacing any of them. I'm hoping that it will be a relatively small amount of code and, perhaps, more &quot;architecture&quot;. I guess the question is whether you feel that there is a problem to be solved for backending Flex and AJAX apps?

@All, if you are interested in discussing this in depth and/or contributing to the project, please join the Google Group. Having said that, feel free to continue to comment here if you just want to express an opinion or ask for clarification and don't feel the need to get more deeply involved (yet!).

I understand people's comments about &quot;not another framework!&quot; But I think most of that comes from a CF developer's point of view... and wanting a single solution for their html and flex apps, or a single framework that powers both Flex and CF/HTML versions of the same app. But I don't believe most Flex apps have an html equivalent ( that's the reason for using flex, for being able to do what html can't, right? ), and I don't believe most flex developers are interested in accessing their server model through a framework that was meant for html apps.

Sure, I'm a cf developer as well ( even though I haven't touched it in almost a year while transitioning to primarily a Flex dev ), so my only interest in CF anymore is nothing more then a backend to a Flex app. With that being said, I'd much prefer a framework that was meant and built specifically for what I was intending to use it for.

And as for making it an extension to an existing framework, such as MII/MG, I hate for people to be forced into learning those simply for the access to the extension, especially when they have no desire in building html apps.

@Devin, yeah, the one-size-fits-all mindset needs to go the way of the dodo. Frameworks are tools and it makes sense to be able to pick and choose the right combination for your particular application. That's why you can use ( ColdBox OR Fusebox OR Mach-II OR Model-Glue ) AND ( ColdSpring OR LightWire ) AND ( Transfer OR Reactor ) etc.

You can also learn - and use - ColdSpring (or LightWire or Transfer or Reactor) in isolation from the other frameworks.

When I said &quot;I do see it more as something to be used with other frameworks rather than replacing any of them&quot;, I meant it in the same way that CS, LW, R and T work rather than &quot;extension to an existing framework&quot;.

Yeah, I'm in. I am not 100% convinced existing frameworks can't be used in this way (I've already done this a lot with AJAX and Mach-ii), but I am interested to see if we can come up with something that is made to work with AJAX and Flex with APIs. A sort of MC framework with APIs, as opposed to MVC.

@Sean, actually, Mach-II CAN backend a Flex app. The Mach-II backend needs to be configured differently than a typical Mach-II application. It sounds like I'll have to blog about it when I get a chance.

I think this is a great idea. Right now I feel like this is a void yet to be filled. We're currently using the Coldspring/AOP approach also, but we're moving in a direction where all of our applications (about 150 of them) will turn into a collection of services. Doesn't make much sense to create a remote facade on the whole service layer if it is only going to be called remotely. We might as well just create remote methods directly in the service layer, but that would negate some of the advantages of Coldspring. We also have our own implementation of security, some of it is based on session information and database entries. I guess what I'm saying is that it feels like we've hacked some things together to work but standardizing on a framework would be good news.

@Brian, well, if you're using it to return XML and doing REST calls from Flex, yes. But if you're using AMF - which you really should be - you have to talk directly to the CFCs in the model *bypassing* Mach-II.

I think an CFMX Ajax/Flex framework would be a good starting point. Since Ajax been around since IE 5 and many other Ajax frameworks beside Adobe's should be allowed. This framework should work with 'all' of the popular frameworks together w/Flex.