An Architect's View

26 responses so far ↓

• 1 James Marshall // Oct 24, 2007 at 1:29 AM

  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)?

• 2 todd sharp // Oct 24, 2007 at 5:01 AM

  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?

• 3 CoolJJ // Oct 24, 2007 at 5:16 AM

  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?
  
  CoolJJ

• 4 Sean Corfield // Oct 24, 2007 at 6:26 AM

  @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.
  
  Keep the feedback coming folks!

• 5 Brian Kotek // Oct 24, 2007 at 7:50 AM

  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).

• 6 RyanTJ // Oct 24, 2007 at 7:56 AM

  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.

• 7 Sean Corfield // Oct 24, 2007 at 8:21 AM

  @Brian, it hasn't reached the UML stage yet :)
  
  @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!).

• 8 Devin // Oct 24, 2007 at 8:31 AM

  Not sure what I would like to see in something like this... that's something I could better answer after playing with such framework.
  
  Nevertheless, if this is something you're thinking of building, I'd definately be interested to see what you come up with.

• 9 RyanTJ // Oct 24, 2007 at 9:40 AM

  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.
  
  I hope this helps.

• 10 Sean Corfield // Oct 24, 2007 at 9:56 AM

  It is server-side.
  
  It would not replace your controller - but your controller could talk to it (it would sit between your MG code and your business model).
  
  Yes, it will need some sort of event/listener config, either programmatic or XML (or convention based).
  
  A service locator is a good suggestion - I'm still on the fence about that.
  
  Global request lifecycle processing is likely (I would probably want to hook into Application.cfc).
  
  The flow would be less procedural - everything would be triggered by events (some "system generated", 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.

• 11 Dan Wilson // Oct 24, 2007 at 11:04 AM

  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.
  
  I would also be willing to donate time and effort to the cause.
  
  DW
  
  
  
  
  
  
  
  
  
  

• 12 Daniel D // Oct 24, 2007 at 12:58 PM

  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.

• 13 Nathan Strutz // Oct 24, 2007 at 1:24 PM

  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.

• 14 Sean Corfield // Oct 24, 2007 at 2:01 PM

  @Daniel, thanx - feel free to join the Google Group (see my follow-up blog entry) and post your notes there!
  
  @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 "architecture". 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!).

• 15 Devin // Oct 24, 2007 at 3:59 PM

  I understand people's comments about "not another framework!" 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.

• 16 Sean Corfield // Oct 24, 2007 at 4:21 PM

  @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 "I do see it more as something to be used with other frameworks rather than replacing any of them", I meant it in the same way that CS, LW, R and T work rather than "extension to an existing framework".

• 17 Brian Meloche // Oct 24, 2007 at 7:40 PM

  Why is it we always think alike??? :-)
  
  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.

• 18 Sean Corfield // Oct 24, 2007 at 10:03 PM

  @Brian, Mach-II cannot backend a Flex app.

• 19 Brian Meloche // Oct 25, 2007 at 4:29 AM

  @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.

• 20 Zach // Oct 25, 2007 at 5:06 AM

  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.

• 21 Sean Corfield // Oct 25, 2007 at 10:06 AM

  @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.
  
  @Zach, thanx. Yes, that is my feeling too.

• 22 Brian Meloche // Oct 25, 2007 at 2:06 PM

  Touche, Sean. You are right, of course. You can't do AMF with Mach-II. I didn't say it was the preferred method. :)

• 23 Sean Corfield // Oct 25, 2007 at 2:19 PM

  @Brian, and that's really my point: folks are so attached to their framework of choice that they try to force all requests through it, even when it is totally inappropriate.

• 24 sal // Oct 25, 2007 at 5:31 PM

  mmh, sounds interesting, perhaps this will get my arse up to speed on learning Flex before I'm seeing FlexMX... ;-)
  
  cheers
  
  actually would rock my current app, in which I've been wanting to implement some flashy flex charts...
  
  :-)
  

• 25 Matt Quackenbush // Oct 26, 2007 at 7:44 AM

  Sounds awesome. Looking forward to seeing Edmund grow up and mature. :-)

• 26 Patrick Whittingham // Apr 9, 2008 at 6:55 AM

  Sean -
  
  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.

Leave a Comment