Posted by dwees on March 12, 2007 at 10:21pm
I don't know if this is a bit of a foolish plan or not, but I was wondering about the feasibility of creating a framework for allowing modules to relatively easily create Ajax-loadable content.
Basically I envision is a module that creates a new hook (called hook_ajax) for lack of a better name. This module would also include an API for module developers to make the dynamic creation a bit easier (for instance a version of the l() function, but one that modifies the URL to point at our module's MENU_CALLBACK, perhaps with some additional information attached).
Now the question is, if this is implemented, what is the proper structure for this, and what is already built in Drupal to handle this kind of functionality?
Dave
Categories: Ajax Dynamic
Comments
actually, it's already quite
actually, it's already quite simple to do ajax in drupal:
something like this works like a charm:
<?php
function mymodule_menu($may_cache) {
if($may_cache) {
$items[] = array(
'path' => 'mymodule/ajax_callback',
'title' => 'foo',
'callback' => 'mymodule_ajax_callback',
'type' => MENU_CALLBACK,
'access' => user_access('access content')
);
}
return $items;
}
function mymodule_ajax_callback() {
// do whatever you want, for example create some json object via drupal_to_js
$mydata['foo'] = "bar";
$mydata['baz'] = "lorem";
$return = drupal_to_js($mydata);
print $return;
exit();
}
?>
Now, in your javascript, just call example.com/mymodule/ajax_callback to get the response. You can of course add more url arguments or GET queries that will then be available in your callback function.
What exactly would hook_ajax do to simplify this?
Javascript written for the user
Well your example doesn't include the client side JavaScript required to do this. It just shows the callback for the Ajax.
What I propose is a way for a non-Javascript developer to create an array of information that is parsed by our Ajax module, and then our module writes the Javascript necessary to implement the Ajax for the user module.
So for example we have a module that does a database pager (like block showing new users or something similar). This module implements a hook_ajax with a an array returned, something like so:
<?phpfunction mymodule_ajax() {
return array(
'#type' => 'pager',
'#callback' => 'mypagerfunction',
'#noscript' => 'mynoscriptfunction',
'#element' => array('id' => 'userwrapper')
);
}
?>
and our function writes the JavaScript necessary to automatically convert the pager links in the 'userwrapper' element to Ajaxified links, and changes the URL to something informative like:
"http://www.mydrupaldomain.com/ajax/pager/mypagerfunction/mynoscriptfunction/userwrapper'
which our module then parses (because it has a callback path of 'ajax') and sends back the correct information back to the browser.
Does this make more sense?
Ahah forms framework
Hi Dave,
Have you checked out the work I have been doing with the Ahah forms framework? It's very similar to what you are describing, only instead of using a hook, it extends the formAPI with an #ahah_binding element.
The bit that I have been chewing on lately is how to get multiple Ajax modules to play nicely together. This came up when I was modifying views_ui and trying to swap out a fieldset. The fieldset came back, but without the collapse behavior attached (of course). So I prototyped a javascript to javascript binding registry, and put it in ahah_forms.js (and rewrote collapse.js to use it). It all worked pretty well, but, of course, only on the pages that include ahah_forms.js. As drupal gets more ajax modules, I think something like this binding registry will need to go into core.
Making js behaviours reattachable
Pls review these two issues on core. Better yet, please start working up patches. Together these two patches would make it possible to reattach behaviours. (They would need to be complimented with methods for dynamically loading js and css files.)
http://drupal.org/node/120360
http://drupal.org/node/125153
Thanks for the links
I definitely want in on this conversation. This is exactly what I have been thinking about (and I already have a patch to collapse.js to make it reattachable).
SoC project
I'm talking to a prospective SoC student right now about building a universal Drag-Drop-Sort API.
http://groups.drupal.org/node/3225
The idea is to abstract the drag-and-drop elements of Interface to allow it to be used like collapse.js.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
mmm :-)
mmm :-)
Ahah forms improvement
This is definitely an improvement, and forms are a large part of what causes Drupal page reloads, but I'm hoping for something more extensive.
For instance I have a form I've built which includes a pagered search functionality and I've managed to get all aspects of the form to be Ajax enabled, including the pagered search results. I had to code all of the JavaScript for this myself, and set up separate callbacks for the pager query and the various form elements.
I'd much rather route all of those calls through the same Callback and let my Callback sort out the mess on the Php side. What I am suggesting is that we build a framework to allow module developers to focus on writing their code in Php, and try to handle the Ajax ourselves. Obviously forms probably need to be handled in a different way because of the complexity in their construction.
Maybe what I need to do is to try and set this up and show a demo of what I mean.