« Adobe Pushing Flex | ^ Main | Adobe Products on Labs »
JSMX Testimony
Todd Kingham from AZCFUG created an Ajax wrapper called JSMX. As you know I recently posted about using Sajax and gave it MUCH praise. Well, I went last night to create an Ajax interface for another KM product and had serious trouble getting the ColdFusion version of Sajax working. I fought with that thing for about 5 hours and couldn’t get it to work to save my life.
The problem was I couldn’t return anything but simple values. If I returned a struct, array, or query (complex values) I wouldn’t get a result. It was terribly annoying. I even used 3 different versions of Sajax+CF and none of them would work. It was quite puzzling why this was working. I decided to move on.
Having experience with CFAjax I thought I’d checkout AjaxCFC first. Instead of downloading and going through the code I checked out a few examples and saw DWRUtil, which is the same thing CFAjax uses. That was somewhat deterring and an eye opener. It seems AjaxCFC is CFAjax ported to a CFC. I could be wrong about this. Either way, I went back to checkout CFAjax but it just didn’t excite me like it once did.
I decided to try out JSMX. Lately I’ve been speaking with Todd, via email, about issues I saw in JSMX, namely not being able to return native objects. He promptly fixed this issue and provided a pre-release version for me to test. I wasn’t thrilled about having a CFC open to the public where the path could be easily found in the source of my page but I figured I’d work a way around that. It is already late so I’m not wanting to go through a whole mess of work to get this thing going. Keep in mind, I worked with Sajax+CF for about 6 hours by now. I was pretty frustrated with it and the slightest issue with JSMX would’ve caused me to drop it as well.
I started dev’ing and within 15 minutes I had JSMX setup and my code ported to a CFC. Wow! Wondering how easy it was to setup? I’ll show you.
http( "POST", "my.cfc?method=myMethod", myMethod_Result, getElement("Settings"));What you see here is the 1 line it took to make the call. I actually passed it my entire form object (Settings) instead of me having to go through each element one by one. It is important to note the getElement() is part of MochiKit not JSMX. I forgot to show 1 more step. Here it goes.
Import the engine.js. That’s it. :-)
From here I just had to handle my data. It was that easy. I was thoroughly impressed. JSMX gets a HUGE thumbs up from me. There is more goodness in it as well. You can create JS objects (new Object();) and pass them as params or you can send simple values. Very nice stuff Todd!
You can checkout JSMX here.
Posted by John C. Bland II on March 14, 2006 12:18 PM | Permalink
TrackBack
TrackBack URL for this entry:
http://mt.katapultmedia.com/mt-tb.cgi/71
Comments
John/Todd,
How did you get around publicly exposing your cfc?
Ray
Posted by: Ray Ragan | March 14, 2006 1:45 PM
My cfc is currently publicly exposed but I’m going to try to work on some authentication you can only get by being on our server. An example could be setting a session variable that holds certain information based on their visit. I’m not sold on this method but am going to at least explore it.
This is the only downfall I found BUT this is the same issue with Remoting except you can’t easily see the cfc and/or method the swf is calling. If you have any ideas I’d def like to hear them.
Posted by: John C. Bland II | March 14, 2006 2:57 PM
I think this topic covers security in general and is not really a JSMX/AJAX debate.
There has always been the debate about how to publicly exposing your CFC’s but I don’t see a difference between a publicly exposed CFC or an “action” file that I would POST a form to. I take the approach of “Security through Best Practices”. Using cfqueryparam in queries, the “accept” attribute in cffile tags, etc…
To date, I have never encountered a situation where solid architecture couldn’t address a security concern. But perhaps, I’m missing the point ;)
Posted by: Todd Kingham | March 14, 2006 6:04 PM
You are right Todd. As I said, this is the same issue for Flash Remoting. By setting your CFC functions to “remote” you put your file out there for the public to consume. The only way around it is authentication which I’d say Remoting has over Ajax but I’m sure JSMX could implement.
Posted by: John C. Bland II | March 15, 2006 10:40 AM
Hmm, sounds like a facade to the rescue?
Facade is a proxy component that you can access your underlying model, but with out exposing more than you mean to.
Thoughts?
Ray
Posted by: Ray Ragan | March 15, 2006 4:49 PM
John,
BTW, your code box is messed up in IE 6, unless you intended us to see it 3 pixels at a time ;)
Lucky I happened to be using IE.
Ray
Posted by: Ray Ragan | March 15, 2006 4:51 PM
Ha! :-) I’ll have to look into that. It was working before.
Yes, anytime you do Remoting or Ajax you should use a facade/proxy. You NEVER want to open your core cfc’s to the public, especially CRUD cfc’s (database interactions that is). This is what I did with JSMX. I have my worker CFC’s in assets/cfcs/ and my facade next to my cfm so I can just call my.cfc?method=mymethod.
Posted by: John C. Bland II | March 15, 2006 5:15 PM
quick fyi John, ajaxCFC is not a port of cfajax. The fact is that both were based on DWR, which is actually an Ajax framework for Java. ajaxCFC does not reuse a single line of code from cfajax, which IMHO was very poorly written. ajaxCFC is based on OOP and the best design patterns practices.
as for your security problem, I also recommend using facades, which is the way I suggest to program when using my framework.
If you need me to extend on best practices, just drop me an email and I’d be happy to assist you.
Cheers,
~Rob
Posted by: Rob Gonda | March 15, 2006 8:08 PM
Yes, I used DWR outside of CFAjax before just for the element retrieving, etc. Essentially, this is what deterred me from using ajaxCFC. I don’t necessarily care for DWR. It is good…don’t get me wrong but I guess CFAjax kind of burned me out with DWR so when I saw it in ajaxCFC it threw me and instantly brought me back to CFAjax. I was kind of sure I was wrong with the “CFAjac ported to a CFC” comment which is why I followed with “I could be wrong.” :-)
I did see however ajaxCFC was usable in ModelGlue, etc. That is very promising. I don’t use frameworks myself but it is good to see someone making strides here.
In a little search today I ran across a small group of people using a cross-domain.xml in Ajax, or at least discussing it. I am going to start a new post about this and would like to get some feedback from you fella’s and anyone else reading here.
Posted by: John C. Bland II | March 15, 2006 9:31 PM
Ray,
Another option that I use when I really don’t want someone to hit an exposed CFC function outside of the application is to place a “roles” argument in the cffunction tag. Then drop a CFLOGIN/CFLOGINUSER tag group in a common file (outside the Application.cfc). Example:
--- Publicly exposed CFC --- <cffunction name="myFunction" access="remote" returntype="string" roles="JSMX"> <cfset myResult="foo"> <cfreturn myResult> </cffunction> --- common.cfm (outside Application.cfc/Application.cfm) --- <cflogin> <cfloginuser name="anonymous" password="password" roles="JSMX"> </cflogin>
This works for me because I do not use CFLOGIN and the function I apply this to are strictly used by the JSMX engine so I don’t need to worry about External WebService Calls. As long as the function is called to from within the Application it works fine. Trying to call the CFC directly will result in no permissions on the function.
This may not work in every situation but seems to work great for my purposes.
Posted by: Todd Kingham | March 22, 2006 10:24 PM
hi Todd
Could u plz tell me if I can return more than one JS variable
to the call back function.
Joshi
Posted by: Joshi Thomas m | April 13, 2006 2:41 AM
Joshi, you may want to contact Todd direct. He was merely responding to my blog post. Go here.
Thank…
Posted by: John C. Bland II | April 13, 2006 3:35 PM