I use mod_rewrite on my projects and I can't use CGI::Ajax directly embedded on my pages because there is a conflict with script name (URL is located at /bla-bla/bla but real script works at /cgi-bin/bla/bla.pl?bla=bla)). But I use it in separate *.js files where I copying JS producing CGI::Ajax (CGI::Ajax uses /bla/bla.pl and I replace it with /bla-bla/bla in bla.js file manualy).
There are a number of contradictory reviews regarding this module, here is my own.
I have a lot of dynamic pages on my corporate LAN produced with good ol' CGI.pm. There is no performance issue, insofar as they are a run with a frequency that is measured in hits per day, rather than hits per second. A number of the programs are over five years old and these days present a lot more information, which makes the click/submit/refresh cycle cumbersome for the end user. The main problem being that after clicking on submit at the end of the page, the refreshed pages doesn't reset itself to the last field updated/modified.
Thus I cast around for an easy way to "AJAXify" the pages, to retrofit some user friendliness and allow updates to be made leaving the page at the same position. I had a quick scan an CPAN, skimmed the documentation of this module, and figured it would do the job. So I downloaded it, and after an hour of futzing around (which would have taken 10 minutes had I read the documentation more carefully), I had my asynchronous updates up and running.
I have therefore been able to earn my old CGI.pm programs a reprieve. They can continue to do their job and I can put off having to rewrite them using a clean MVC template-based approach. Which would be fun, but not really justified since they aren't really broken. If you find yourself in a similar situation, this module is ideal.
In short, CGI::Ajax gives you the worst in webapps as of 2006 combined with the worst in webapps as of 1996.
If you are serious and need to build more than a tinkertoy of an Ajax app (which, admittedly, not all of us need to), I would suggest to instead acquaint yourself with the following things:
c) ETags and conditional requests (beyond just their use for caching)
That will give you the tools necessary to build Ajax apps that scale up nicely â€“ with code size, in maintainability; and with your audience, in performance.
Of course, that wonâ€™t scale *down* as nicely. If you just want to slap together a page with a few buttons to change state on the server (youâ€™re doing home automation and have put your coffee maker on an X10 wire, say), then CGI::Ajax will allow you to get that done with the minimum effort possible.
If you wish to return multiple values from an external script (which is how I use CGI::Ajax), you need to return the results as a string, using the text â€˜__pjx__â€™ as a delimiter between each value. This is documented, but is not given much prominence, so itâ€™s easy to miss.
But the fact remains that this module enables you to write rich Ajax apps pretty quickly. Congrats to the authors
This can be a great module, it could be really useful. It needs more careful documentation and a more flexible interface.
This is a nice module with (almost) adequate documentation. However, its usage was hampered by some hidden bugs (as of V0.6) and slight interface deficiencies.
The main advantage the module provides is to encapsulate the routine AJAX code into easy-to-use functions such that you only have to worry about your script's own logic (and not AJAX details), what input your script needs and where (which html elements) on the web page to place the output. The packaged example scripts are in some cases much better than the documentation, which has some errors (like the first script in the synopsis wouldn't even produce anything 'cause it missed the 'print' in 'print $pjx->build_html( $cgi, \&Show_HTML);').
Another good thing I found out was that one could easily make the script deal with both AJAX request and traditional POST/GET requests. It came in handy for one of my web apps (since it needs to stream an Excel file in some situations).
Now the bad part: V0.6 has a hidden bug that took me longer to debug than I could've worked out an AJAX web app myself as AJAX is easy in itself. I emailed the authors of the bug (and its cousins) and hopefully it'd be soon patched. (Edit: author fixed the bug in V0.64)
Another thing is that the module does not deal with multiple select well at all. In fact, all selections are flattened into 1D array such that if you have multiple html elements, you don't know where the first selection starts (or the last ends) in the array you got in your perl_func. But it's also easily patchable and I emailed an suggestion to author. (Edit: fixed in V0.641)
All in all, this is a nice module that'll save your time when you build AJAX app many times. If it fixes its current issues, it'd be great.
Love it. Using it extensively with FormBuilder and Template Toolkit, and the prototype / script.aculo.us libraries combination for DOM related eye candy.
my $cgi = CGI->new();
$foo = "get_items(['my_value_div_id'],'returndiv')";
my $form = CGI::FormBuilder->new( #blahblah