CFCs with Flex - Should I Break The Rules?
I've been working on a personal project in my "spare time" (ie, evenings til way past my bed time) that has me rethinking some "best practices" for CFCs. The project is mostly Flex, but some traditional CF is sprinkled in where it makes sense. The challenge I've been facing is determining how to keep my CFCs from interacting with shared scopes (like application, session). The more I think about it, the more it seems to make sense to "break the rules" when it comes to Flex.
From what I've learned, the main reason to avoid accessing shared scopes from your CFC is that it makes your component less portable. In the case of a Flex application, if the purpose of my CFC is to solely provide transactions for that application, do I really need the component to be portable? Maybe. But as I said I'm struggling with alternatives. For example, one of the methods in my CFC returns a string of HTML. The HTML will not be Flex safe so I can not use Flex to display the result. Instead, on result of the remoting call I'd like to launch a new window that will display the HTML. To me the perfect solution would be to store the HTML in an array of structures (or struct of structs) in the session scope, with each structure containing a uuid corresponding to the given HTML. Then the remoting call would return the uuid, passing it along to the new window via the url. The new window would display the appropriate HTML from the session structure based on the uuid passed. As I said, to me it's a perfect solution. My method would be putting data into the session scope, rather than querying the scope which would preclude that my app is relying on specific session data to exist (therefore reducing portability). Is this a bad thing?
I'm sure there are other CFers out there like me who are just getting their feet wet with Flex. What do you think? How would you handle this case? The only other alternative is to make the HTML Flex safe, but I really don't want to go down that road (though it could easily be done). Users of this product are very familiar with the HTML formatting and would not likely be too happy with the change.
P.S. Not to get all prophetic, but I promise that this project is going to be very helpful to many of you CFers out there.
RSS
Does it make sense then to store the base cfc in the application scope so that the proxy does not have to invoke it with each call?
In normal situations I wouldn't be outputting HTML in my 'model' code.
After all is said and done, rules are relative.
Agreed. Actually, it's not directly 'outputting' but retrieving and returning the HTML as a string. Would that technically still be breaking the 'no view in the model' rule?
There is an alternative that I am considering (which still requires the proxy, or facade). Haven't made the final decision, but if I told you the circumstances than I'd be letting the proverbial cat out of the bag. Not that this project is all THAT, but.....
As long as you separate your processing from your display elements, I don't have a problem returning HTML from a method.
Although, I wouldn't want to combine a method that both processes data and format it.
I've had situations where queries will filter data based on the user's login credentials. In CF, the login credentials would be stored in some sort of session variable and queries filtered accordingly.
With the Flex Front End, I used a Facade (Or is service layer the right term?). After login, a 'sessiontoken' is passed back to the Flex client. That value is passed to each remoting call as an argument.
Now that I say that out loud, I think i was storing the relevant server-side-session info in the application scope, and loading it up as needed based on the sessiontoken, which isn't use of the session scope at all.
An early release of the project should be good to go next week (assuming I can wrap some things up tommorrow). Keep an eye out here and in RIAForge!
this helped simplify things cf side & seems to work a bit better w/this particular GIS--it's very tempting to maintain its objects in session vars but it gets cranky when it's used all day long like that and "normal" GIS apps tend to be used that way. storing it's normal "session" bits in the flex client helped us remove that temptation ;-)
I've been doing remoting in Coldfusion Flash (Flex 1.5) forms for some time now, and the way I'd always set up my CFC's was as Ray Camden suggests: storing them in the application scope and using a lightweight proxy cfc to return the results of those methods.
However, all the Flex > Coldfusion integration suggests you create bindable mappings to cfc's in AS classes.
Doing this makes your Flex apps less portable as it requires Coldfusion at the backend. So yes... break the rules!