All about Ajax!

[eluser]RESPECT[/eluser]
I just finished my bare bone application, it works and does what it needs to for each part. Currently I'm re-factoring and rethinking my code. After that step is done I'm adding in some AJAX....I have a couple questions and I need expert advice from all you gurus out there

How do you degrade gracefully? Saying the user doesnt have javascript enabled? Or AJAX simple doesnt work with their browser? code examples?

Do you bother with authentication in AJAX or do you base it in the controller action that AJAX itself invokes?

What does unobtrusive AJAX mean to you?

Are there any AJAX plugins for codeigniter? jQuery? Other then the ones mentioned in the wiki? I believe some sort of AJAX support was planned for EE (old blog post) if this ever comes to fruition will it trickle down to CI?

Thanks in advance!

Respect

[Edit]
For future readers, this helps w/ degrading.
http://michaelwales.com/projects/request/

[eluser]Pascal Kriete[/eluser]
I guess I'll give it a shot.

[quote author="RESPECT" date="1223102901"]How do you degrade gracefully? Saying the user doesnt have javascript enabled? Or AJAX simple doesnt work with their browser? code examples?
...
What does unobtrusive AJAX mean to you?[/quote]
To me, javascript should be transparent. There is nothing worse than overkill effects. It's only cool the first time.
Make sure the base functionality is available regardless of javascript setting. So a wysiwyg (which I'm not really a fan of, so far only gmail got it right, imo) will turn into a textbox.
Actually, when building the app I approach it the other way around. It starts out as a textbox with working validation, et al. Then I add the javascript layer to turn it into a wysiwyg. Progressive enhancement.

Code samples? Hmm... if you don't mind YUI: Editor and Dialog

[quote author="RESPECT" date="1223102901"]Are there any AJAX plugins for codeigniter? jQuery? Other then the ones mentioned in the wiki? I believe some sort of AJAX support was planned for EE (old blog post) if this ever comes to fruition will it trickle down to CI?[/quote]
I'm pretty sure it will trickle up, not down. The next version of EE will be built on CI. So core functionality, such as the announced jQuery support, will hit CI first.
I've openly said that I'm not convinced of the idea, but I won't reject it before I see it :lol: . I believe learning javascript has made me a better programmer, so I would hate for others to have an easy way out .

[eluser]Pascal Kriete[/eluser]
Whoops, missed the authentication part. I don't change anything except for the response.

Basically, my auth lib would look like this:

Code:

// asnyc_request() is defined in a helper
if ( ! $this->CI->session->userdata('logged_in') )
{
    if (async_request())
    {
        $this->output->set_status_header('401');
        echo json_encode(array('redirect' => site_url('login'));
        exit;
    }
    redirect(site_url('login'));
}

The javascript checks the header and acts accordingly. In this case it will redirect to the url in the response.

[eluser]Jamie Rumbelow[/eluser]
What I like to do is check for the AJAX request server side, so a user could visit the ULR that AJAX is requesting and it would work fine. As long as you check the URLs and get them from the <a> tag, if the user has js turned off it still works.

It's also a good idea not to add AJAX stuff to an element that doesn't have a click event natively. Things like divs, h1s and spans arn't clickable, and thus arn't clickable by programs like screen readers.

[eluser]Jay Turley[/eluser]
My approach is similar. I focus on adding AJAX functionality, rather then baking it in. In the authentication case, I would first build a login page that worked. Once that was successful, I would hijack the form submission using javascript by preventing the default event for the form submission and then submit it using an AJAX request. If I was really on my game, I would also build the interface for the login using javascript by injecting the DOM elements, instead of simply using CSS to hide them and then showing them using javascript.

I've never worried about what Jamie mentions above about checking for the AJAX request server side because I don't use GET requests, only POST except for the case when I expect to receive HTML that will be injected into the DOM (extremely rare). However, I will keep his suggestion in mind for the next time, as I feel it is a good point if you are using a GET. Almost always, though, I return JSON.

I also like to include a token with my AJAX posts so that I can use the same function to return JSON objects or return an HTML view if the token isn't there (i.e. user-submitted).

Edit: although now that I saw the link to Michael Wales' Request library, I will be trying that.

[eluser]Jamie Rumbelow[/eluser]
Another thing to remember is that the browser will cache your requests - you must remember to avoid this if your content changes frequently.

By adding a random hash to the end of your url, javascript side, you can prevent caching.

[eluser]RESPECT[/eluser]
Thanks for the great response guys really helpful!

Another quick question, is it really that important to make the site function without javascript? saying its all ajax based. Facebook for example doesn't even attempt to make the site work if javascript is disabled, if a large site like facebook with millions of users is so successful and a little warning isn't even offered to the user then is it really important for smaller sites to offer a non-javascript solution?? Javascript's roughly enabled on 98% of all browsers now-a-day so is there much need for it? Would it be acceptable to give the user a warning inside a <noscript> tag? And sorry I know this discussion almost falls into the category of offering support for old decrepit browsers...*cough*IE*cough*

Thanks, Respect

[eluser]Nick Husher[/eluser]
It depends on our audience; if you're building for a very broad audience (impared users, users operating from behind strict corporate firewalls, the paranoid linux dorks, and grandmas running Netscape 4.1), you should be eating and drinking progressive enhancement. If 98% is good enough for you, go the Facebook route.

I'm of the opinion, by the way, that Facebook can largely get away with forcing their users to use JS because their user base trends toward the young, who tend to be both tech-savvy and tend to be fairly casual with the potential security risks involved with web technologies. Users who know what javascript is, and have a problem with it, wouldn't be interested in having a Facebook presence anyway.

It’s also a good idea not to add AJAX stuff to an element that doesn’t have a click event natively. Things like divs, h1s and spans arn’t clickable, and thus arn’t clickable by programs like screen readers.

I disagree: WAI-ARIA indicates that an appropriate role attribute should be sufficient to trigger screen readers. Then it's up to you to write the necessary keyboard navigation. As a shameless plug for my favorite JS library, YUI now has plugins that make many of its widgets WAI-ARIA-complaint, which if you're into that kind of thing, is a huge amount of work done for you, right out of the box.

The way I've been doing it lately is to develop one or more modules (in YUI, but other libraries have similar design patterns) and load them all in as I need them with the YUILoader function, which inserts them into the DOM tree after the basic document has finished downloading. The advantages of this is that it immediately displays the document information to the user while deferring complex and time-expensive UI loading. You can do some basic javascript style manipulation to show controls as they've finished loading and update the user on the progress of the enhanced UI effects.

The disadvantages of this are an increased code overhead--I have to load the loader and define my modules to insert the code on the page--and a longer lag time before enhanced controls become active.