I think the bane of development planning can be those conversations where you personify your framework and start debating about what a service should "know", whose "job" a particular operation is, or what the handler should "care" about. This is one of those sort of questions, but I'll keep it brief since I'm more interested in your opinions than my ramblings.Here's the setup: We have an application built with ColdBox (MVC). The existing interface is all in HTML with a smattering of Ajax thrown in. We have been careful to maintain the separation of our model (services, beans, and DAOs), our controllers (All the ColdBox handlers), and our views (HTML output so far with a few proxies used by Ajax to return HTML or simple data). We are at a point in our application where we want to go back and rewrite a few pieces in Flex, and after that, some much larger portions. Our thought all along was that the magical separation of our views from everything else would aid in this since, in theory, the same service calls and handlers could return the exact same data back to any view; be it HTML or Flash. The first problem we are running into is the widespread interaction of our model with the views. For instance, we used the IBO pattern, so a screen listing a user's addresses would start in the addressList handler which asks the AddressService for the list of applicable addresses. The service creates an Address IBO, asks it to load itself via its DAO, and returns it to the handler. The handler, happily sets the Address object full and brimming with all its addresses into the request collection and asks the view to renders itself. The view, knows to look in the event's request collection, pulls out the address object and proceeds to loop over its members whilst creating the HTML table on the screen. This is just one basic example, but it carries one major assumption: The view will be able to understand and use anything in the request collection including CFCs. Now, instead of using an HTML view which is created in a .cfm file, I will need to call my handler via a proxy and return the data via my web service to the Flex front end. Of course, a CFC like an IBO cannot be passed to Action Script, so the data must be placed into a form that can be transferred easily like a result set. Here are a few problems/questions about that:
  1. The request collection is a struct containing any number of items the view needs. Should my Flex app make a series of atomic hits to the web server to get everything it needs separately, or should I return a struct back with everything all crammed in there?
  2. Massaging all that data out of the objects and into a result set seems like a lot of extra work; especially since my model layer just went through all the work of of building objects out of my result sets.
  3. Who should be doing this dissemination of data into a form palatable by the view? The handler? The proxy?
  4. Is it cheating for us to use CFCs directly in our views instead of only simple data (strings, numbers, result sets)?
  5. Was it silly of me to think we would be able to reuse handlers for both HTML and Flex views?
  6. Why do I keep wishing I had my CF model in Flex? It doesn't feel like just a "view", it feels like an actual client-side application that I've got to keep stupid because it doesn't speak CF.
  7. The little mapping of my result set to an array of Action Script objects seems silly to me. They're nothing more than glorified structs with getters at that point. Even if I mapped my user.cfc to a user.as object in AS it's not like I could call user.getCompany() in my Flex app and expect the company object to be lazy loaded in.
  8. Are we over-thinking this?
  9. What would Hal Helms do? Wait, don't answer that unless you're Hal.
  10. I promised I wouldn't ramble, sorry. *sigh*