This question came in today and I thought it was pretty interesting:
We are building a family of applications (using Coldfusion and Coldbox), all of which run off the same database - for a client. I've also built a chat system (using coldfusion Websockets) for one of the apps. So, people logged on to that app can chat with one another.
But we think it would be cool if the chat system could be extended across all the sister apps. That is, a person logged on to any one app could chat with a person logged on to another sister app. Since we define websocket channels at the application level, it seems channels cannot span across multiple applications (but that's what we want to achieve).
So, in case you don't quite get it, ColdFusion 10's websockets are specific to one application. Given a websocket channel named "chat" in application one, if you have one with the same name in application two they won't share messages.
One of the first things I did was recommend Node.js. And no - I wasn't saying to give up ColdFusion. You can easily use Node.js services along side ColdFusion. If you were to set up a Node.js websocket server on - say - port 8888 - then your apps could all make use of it. (I first saw Simeon Bateman demo this.)
But outside of that - I suggested using a simple iframe. Dropping in an iframe would let you quickly include your chat application inside it. I built a quick demo of this. I created two apps (and by apps I mean one page with a dump of the Application scope) and then simply added an iframe to the chat app:
The result is pretty much what you expect. As an FYI, my chat demo wasn't really built for an iframe. It could be improved.
So... there's that. But I was curious about doing something a bit more than chat. What if you wanted the iframe to communicate with the parent window? Turns out that's slightly complex due to browser security issues, but that may not impact you depending on your use case. (For the book on the topic, see Third-Party JavaScript.)
I began with a simple example where all apps were hosted on the same domain:
foo.com/app1
foo.com/app2
foo.com/chat
In that case, your chat app could communicate to the parent rather easily:
if(window.parent.msgHook) window.parent.msgHook(message.data.chat);
Where in app1 I may have:
I'm not actually doing anything with the message, but you get the idea.
Moving to different domains though gets tricky. Imagine you have these domains:
x.foo.com
y.foo.com
chat.foo.com
If you want x and y to be able to iframe the chat server and receive messages, you have to use something like postMessage. In compatible browsers, this lets you add event listeners for messages being broadcast from one iframe to a parent (or vice versa).
As an example, I added this bit of code in my app:
And then my chat server broadcasted a message using postMessage. Note that I'm using * for the targetOrigin. I can make this more specific to my domains.
window.parent.postMessage({"msg":"foo"},"*");
Make sense? I've included all 3 iterations of the app as an attachment to this entry.
Archived Comments
Hi Ray, has been a few since I commented on something. Nice chat option for any CF site. Took a quick look at it for a few minutes. The only question I got is about the Application files. The way it is coded, is that cfscript or OOP? Reminds me of OOP. Hope that is not to silly of a question, just not the usual way for me when programming with CF.
I hate to say it is a silly question (grin), but it is a badly worded question. "Script" is a way to write code in terms of syntax. OOP is a way to *organize* your code. You can do OOP in CF with all tags. Most advanced developers though prefer script as it is quicker, especially for stuff that isn't doing any output - just logic.
So would it be safe to say that when CF tags are looked at behind the scenes, this is what it looks like; JAVA more less? Reminds me of AS a lot.
Um - well - CF gets compiled down into Java bytecode. All scripting languages look similar in some ways I suppose. I think you would say cfscript looks closer to Java than cftags do, but it's really not something I'd use as an example.
I was referring more to what makes the CF tags tick. Someone may have a tag on the page they are coding, but what does it look like behind the scenes to make it work. Because technically, is CF not actually JAVA in the background? :) Appreciate your input by the way.
The CF server is written in java but as far as I dont think the CF code is compiled to java. It justs gets interpreted then passed to the client.
@micah - That makes perfect sense to me. You ever looked at the view source of a browser and noticed the code printed for the cfform? Looks something like this: _CF_submit_status["CFForm_1"]=null; it is actually javascript. But the tag still has to be interpreted on the server and then output. All other tags of non form type are interpreted as well by the server but never output to the page as the cfform tag gets output. So overall you are correct from my understanding.
The code is processed by the CF Server which is JAVA as Ray stated as well. This is my meaning by the fact I believed CF tags are being processed/compiled behind the scenes with JAVA. Definitely more advanced programming happening if you can do it that way.
"All other tags of non form type are interpreted as well by the server but never output to the page as the cfform tag gets output. "
Im not sure I understand what your getting at here. The other CF tags as well as their logic and formatting (if they are done correctly of course) are output as well. Maybe im totally missing what your getting at. BTW, this would not even be close to the first time this has happened.
The cfform (again, depending on the attributes and other logic built into the cfform) will build js logic in the client webcode as that is passed on to the next page for processing or will be used for client-side js processing.
Hi Ty,
Why not download the source code for the opensource cfml server Railo and take a look around, it isn't that hard to follow.
I recommend all developers have a deeper understanding of whats going on under the hood.