Dave, 

I completely agree with you about using the CF8 AJAX components. Not only are 
they not XHTML strict compatible, but they cannot be customized properly. Hence 
it is much better to use either jQuery or Ext JS directly. The same can also be 
said about using CF Form validation. Anyways I am going to try to integrate my 
AJAX data calls into the M2 framework and see how that works out. That is 
probably going to be the best usage of time rather than banging my head against 
the wall some more until a better solution to this problem presents itself.

Jordan

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Dave Evartt
Sent: Thursday, October 22, 2009 7:41 PM
To: [email protected]
Subject: [Mach-II] Re: Mach II Properties in an AJAX request


Well,

I for one disagree with the basic premise that ajax calls for data 
should not go through M2 but UI content should.

I am a firm believer in letting the framework do what it does so well, 
and that's 'controlling' the application.  Because there is no 
substantial reason to treat one kind of browser call any differently 
than another browser call, in addition to Peter's observation about the 
duplication of security functions, necessitated by stepping out of the 
M2 environment, simplicity just makes the application easier to develop 
and maintain.

Now having said all that, there is a huge difference between using the 
cfajaxproxy methods included with CF8 and using the much more robust and 
flexible functions available the jQuery. I've been using the CF8 ajax 
functions for the last couple of years and while they are handy for 
people who only dabble with ajax, they are poorly suited for enterprise 
level use. jQuery is a whole different world and my experience with it 
is that it took me less to to become proficient with jQuery than it took 
to figure out how to make the 'simpler' CF8 function perform the way I 
wanted them to.

When that article came out (2007), it might have made sense, I've only 
been on M2 for a couple of years. Considering how little understood 
ajax, and the CF8 implementation of it, where at the time, it might have 
born up. But that was then and this is now.

I remember when using a PC was considered a waste of time (yes that 
dates me and my 34 years of computer programming) but just think how 
that sentiment would hold up today. One of the things I've learned over 
those long , hair pulling years, is that anything that makes my life 
easier, the more I like it. On the other hand, I must be doing something 
right from time to time; I'm still doing it 12-14 hours a day.

I for one think that the CF ajax functions should only be used by people 
who can't do javascript. For those who can, it's so much easier and 
friendly to use jQuery that  it's a lot like  the difference between 
driving a Chevy and a Porsche. They'll both get you where you're going, 
but wouldn't you really like to enjoy the ride?

It's just that for experienced programmers, CF ajax gets in the way more 
than it helps. Again, my opinion...
-dave

Jordan Gouger wrote:
> Peter, 
>
> This is the article that I'm referring to: 
> http://www.briankotek.com/blog/index.cfm/2007/7/25/AJAX-Data-Requests-vs-AJAX-Content-Requests
>
> I agree with what he is saying, because essentially, what I'm trying to 
> accomplish is an AJAX data request, not a content UI request. While this 
> application isn't going the FLEX route now, it is conceivable that later in 
> the future it might. Obviously if that ever happens, then I will rewrite the 
> authentication into a SSO that powers a WSDL. 
>
> Jordan
>
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Peter J. Farrell
> Sent: Wednesday, October 21, 2009 4:51 PM
> To: [email protected]
> Subject: [Mach-II] Re: Mach II Properties in an AJAX request
>
>
> Dave Evartt said the following on 10/21/2009 03:32 PM:
>   
>> Granted that there are security concerns with hidden calls to the 
>> application, but really, are they really any less secure than the same 
>> call from a browser link. I think not. but it's about the user 
>> experience, and if we're not concerned with that then we can just say, 
>> 'no javascript, no java, no cookies, and nothing but plain old text'. 
>> But since few developers fall into the Luddite category, and ajax really 
>> has nothing to do with the M2 architecture anyway. I wouldn't think 
>> twice about it.
>>   
>>     
> Actually, this is a good point.  Most people already have implemented 
> some sort of login / security process via filters or plugins in 
> Mach-II.  If you run your AJAX outside of Mach-II, you have to re-create 
> those security measures again which lead to two implementations that are 
> trying to solve the same thing.  Running AJAX through Mach-II means you 
> can leverage your already existing infrastructure.  Having two 
> implementations is a security concern if one works slightly different 
> than the other.
>
> Just curious why you abort your AJAX events in your example code?  If it 
> has to do with Mach-II debugging output, you can programmatically turn 
> that off on an event by event basis (see the doco for the event-arg you 
> need to set).
>   
>> When it comes down to it, making an ajax call should never be treated 
>> any differently than any other call from the browser, regardless of the 
>> platform the application  runs under, since it is always under the 
>> direct control of the browser anyway.
>>   
>>     
> I totally agree normal browser requests and AJAX requests are just plain 
> old HTTP calls.  It's just that AJAX is inside the user agent already so 
> it's probably going to do more stuff.  They both of be secured the same way.
>
> You can do some additional security because most AJAX libraries some 
> additional information in the user agent string and/or HTTP request 
> headers that identify it as an AJAX request.  You could easily write a 
> plugin that looks for this information for AJAX events in Mach-II. This 
> would disallow the casual person from requesting that even via the 
> browser url -- however it's no replacement for true security in case 
> somebody spoofs headers / data via some other mechanism.
>   
>> All of this is of course, just my opinion. your mileage may differ.
>>   
>>     
> Jordan, I'm curious where you read AJAX through Mach-II is bad.  I think 
> is the past a few people have vocalize that they thought this might be 
> bad, but I've never been very convinced due to the lack of reasons.  Bad 
> for bad sake isn't true reason to me.  I guess Team Mach-II has never 
> really said otherwise to use AJAX in Mach-II, but from what we've talked 
> about for future versions of the framework -- AJAX integration / hooks / 
> tools for you to use will be expanded  (my arm is being twisted a bit by 
> former team member Kyle Hayes to use DOJO -- he just wrote a book on 
> DOJO and I must admit people are over looking that framework).
>
> Best,
> ..Peter
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.423 / Virus Database: 270.14.22/2446 - Release Date: 10/20/09 
> 18:42:00
>
>
>
> >
>
>   



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.423 / Virus Database: 270.14.22/2446 - Release Date: 10/22/09 
18:44:00



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets: 
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
-~----------~----~----~----~------~----~------~--~---

Reply via email to