MVC Question: What Should The Controller Pass The View?
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.
TweetBacks
Working thus all her interfaces will be coupled to any data connector.
Regarding CFC, the kind conversion of given is transparent, do not worry, CF was worked for you if you do not worry with that, imagine the data going out from CFC and going to Flex naturally. I no longer can tell the same of a Struts, if there were no FXStruts, my life would have been a hell at the beginning of year.
I'm also a Coldbox CF and Flex developer. Haven't tried to remote to cfc's or CB handlers from a Flex MVC like Mate or Cairngorm, you tried that yet? Are you guys using a Flex MVC framework?
Any ways, I think you should read the <a href="http://ortus.svnrepository.com/coldbox/trac.cgi/wi...; target="_blank">Coldbox Proxy Integration Guide</a> if you haven't already. I'm not sure if it'll shed any light on your issues but it works.
My problem is trying to conceptualize juggling two objects between CF cfc's and a Flex model. Am I supposed to create and use the object on the CF side then pass it into Flex where I have to again create an object in AS for it? Essentially creating 2 beans or 2 vo's, etc..
No worries, though-- I got the gist of what he was saying. Basically that you have to change your paradigm when you do Flex from a request/response "web" model to a desktop app "single load" model.
We are still trying to decide which Flex framework we want to use. We are reviewing several of them right now. Do you have any suggestions? We'll probably only have 2 or 3 people working on the app (which is mostly for CRUD), so we're mostly looking for a lightweight framework to help with the organization of our code more than anything.
I have read the ColdBox Proxy guide in the past, have familiarized myself with the code, and used it for Ajax calls and I think I have a pretty good handle on how it works. My questions with it at this point are really organizational questions of _how_ I should be using it. In other words, I may know how my hammer works, but it doesn't mean I know how to build a house with it.
On your bit about juggling the two objects, that is exactly where I am at now. I don't want the duality of maintaining my model in two different places, but I can't reuse my CF model in AS and I don't want to write it all again. This is why I am wondering if my view (Flex in this case) shouldn't deal with the model. The problem with that is Flex really isn't just a view. It's a controller too and possibly another model as well. CF is really just a remote DAO at this point and I'm not sure what responsibilities should belong to whom anymore.
The key thing that you've already touched on is that:
- flex is a standalone and persistent app (which is mindshift)
- it will have it's own Model View and Controller.
What we've used with much success is a simple Cairngorm framework for the flex application (has pro's and con's, and is a bit maligned recently, but I think unfairly so). It gives good structure with very few boundaries.
You can still leverage much of you CF model in creating views - but your views become XML views which are purely for passing data into the application (or for receiving it back).
But you will definitely need a seperate model, view and controller. Suggest make that decision and keep it as simple as possible.
Have fun with it.
Mark
2. Maybe you should have asked your model layer (Service layer) to return the result set without objects
3. Service Layer, I'd pick.
4. Simple data are preferred., but it is okay to cheat, just always weight out the pros and cons and understand them.
5. not silly at all, I think they might work, but Flex app can do more than just a html page, so it call the service directly instead of calling the MVC framework's handler.
6. 'cause you're moving more logic to the client side with a Flex app. Therefore Flex is not just a view. You may end up with some core features implemented in both AS/MXML and CFScript/CFML.
7. I think you can add that functionality yourself in the AS level if u like.
8. maybe, maybe not.
9. I'm not Hal Helms.
10. Is okay to ramble. We all do~ :)
I personally shy away from converting queries to arrays of data objects, except in the sense of a string "array" that deliver xml or json to a non-cf consumer. Seems like a lot of thrash, whose net result is to lose a lot of the efficiency and fluent coding idioms that query objects provide. IBOs as view iterators give you the ability to have custom field-level behaviors etc, while still working directly off a single native query object.
You're right that from an end-to-end perspective, having a flex front end turns the whole cf app into a data provider. In that mode, it still has a final-rendering layer, whose function is to convert the cf query into a form its customer (flex) can consume.
So say the data returned by the model is a native cf query, which the view IBO takes as input. For a native-cf front end, it loads up the passed query, and iterates over it to generate the view html. For a flex front end, it does the same thing, but instead generates xml to be consumed by flex. (Unless flex can work with cf queries natively, which I doubt, but here's where my ignorance of flex shines through; need to fix that some day...)
Make sense?
e
@Henry: Thanks for the categorical replies. :) Here's a couple thoughts in response.
1) It's not that there's a problem as much as I'm testing the waters to see what other people's best practices are
2) I thought about that, but it seems to undo all the work we did to use objects in the first place. I'm sure you can understand how it's frustrating when you think people are telling you objects are the way to go; but as soon as you run into complications someone else asks you why you didn't just use a result set in the first place.
3) So, since I need my service layer to service both the handlers that use HTML views (returning objects) and the handlers feeding my Flex requests (Returning some simpler data type like a query), my services would need to have two versions of each method, some return type parameter to each method, or give up on returning bean objects and just revert to good-old result sets.
4) Point taken
5) I can't call the services directly because a) They aren't web accessible b) They require the framework to autowire them and provide the plugins they use and c) They assume the framework's security interceptor is securing their access.
6) I think I've come to that conclusion too.
7) True, but that would be way outside of the campy little "object generation wizard" that comes with Flex Builder.
8) heh :)
Thanks again for the comments Henry.
@enigment: thank you as well for weighing in. The thought that an IBO is just a wrapper around a "native query object" is a little bogus. It actually hacks the query up into a struct of structs. Thing is, even though we use IBO's we pack them full of composite objects (more IBOs of course) for a pretty deep domain model. That way we can do the equiv of CompanyUser.getUser(userID=57).get("company").get("address").get("zipCode") That was three IBOs right there.
As to your question about whether Flex can "work with cf queries natively"-- It actually can with ease. The come across the wire as an ArrayList. (Think array of structs)
We've come up with a clever way to dump out the contents of our IBOs as nested arrays of structs which we have mapped on the Flex side to corresponding ActionScript classes. I'll blog about it when we're sure it's actually going to work for us.