On 05/07/05, Michael Peters <[EMAIL PROTECTED]> wrote: > Paul Campbell wrote: > > I'm interested in any feedback anyone might have for this module. > > I know that you probably wrote most of this before the full callback > system was done, but it would be really neat if more of this was > invisible to the user. For instance > > $self->run_modes > ( > 'index' => 'index', > 'multiply' => 'multiply', > 'divide' => 'divide', > 'upload' => 'upload', > &AJAX_run_modes, > ); > > You don't need the &AJAX_run_modes() since your plugin can register them > behind the scenes.
I'm thinking about upgrading to 4.x of CGIApp so I can get access to these callbacks. Developing on Debian/Etch which is still on CGIApp-3.31. I want to make it transparent. Really, I do. So much so, that getting rid of this specific call is mentioned in the [1]TODO file. [1] http://kemitix.net/cgi-bin/darcs.cgi/cap-ajax/TODO?c=annotate > sub index > { > my $self = shift; > my $ajax_client = AJAX_load_client; > my $ajax_init = AJAX_init; > ... > my $html = <<EOT; > <html> > <head> > <title>Kemitix::AJAX::App::TestCGIApp</title> > $ajax_client > </head> > <body $ajax_init> > ... > } > > It would be wicked cool if you used a callback registered at postrun to > actually post process the HTML to add this javascript to the <head> and > <body> tags itself. Another feature that now becomes invisible to the user. Now /that/ is an idea. Of course, we'd need to include an option to disable it, just in-case someone doesn't want the HTML post-processed. That, I think, will be going onto the TODO list. Thanks. > As for the AJAX_register_run_mode(), I got a little confused as to which > portions where Perl and which were JavaScript on the initial reading. > I'm still not completely certain of how it works but maybe that would > become clearer as I play with it some more. That confusion struck me too. Given that we are mixing JavaScript and Perl code into the same file, that is going to happen. Unless we moved the JavaScript out to another file (XML?) that defined the JavaScript components. We loose the ability to use interpolation from Perl variables into the JavaScript. Not that I can think of an immediate instance where that would be useful - but I'm sure someone could come up with one given time and the opportunity. If the whole register_run_mode element was moved out to an XML file (pulling this format out of the air): <?xml version="1.0"?> <!-- declare namespace here --> <cap-ajax:events> <!-- an event corresponds to a potential call to a run mode --> <cap-ajax:defaults> <!-- default setting go here --> <cap-ajax:event-method protocol="get"/> </cap-ajax:defaults> <cap-ajax:event name="multiply"> <!-- click the button or change one of the two values --> <cap-ajax:event-source source-id="btnMultiply' source-event="onclick"/> <cap-ajax:event-source source-id="term1" source-event="onchange"/> <cap-ajax:event-source source-id="term2" source-event="onchange"/> <cap-ajax:event-trigger> // javascript code var t1val = ajax_elid('term1').value; var t2val = ajax_elid('term2').value; var t3val = ajax_elid('term2').value; // this variable is here to confuse you if(length(t1val) && length(t2val)){ return true; } return false; // don't call server if either term is blank </cap-ajax:event-trigger> <cap-ajax:event-cgiarg name="term1"> <cap-ajax:event-cgiarg-parameter value="t1val"/> <cap-ajax:event-cgiarg-parameter value="t3val"/> </cap-ajax:event-cgiarg> <cap-ajax:event-cgiarg name="term2"> <cap-ajax:event-cgiarg-parameter value="t2val"/> </cap-ajax:event-cgiarg> <!-- would give a query string like: term1=t1val;term1=t3val;term2=t2val --> <cap-ajax:event-callback> // javascript code </cap-ajax:event-callback> </cap-ajax:event> </cap-ajax:events> Having written that I'm tempted by it, or something like it. It would give a seperation of JavaScript from the Perl. I've tried my best to allow HTML to be created with the only JavaScript visible in the BODY onload attribute, then gone and mixed JS in with Perl. I don't know about your text editors, but might gets confused trying to highlight it meaningfully. There is more information available in the [2]repository to explain where all the different parts of AJAX_register_run_mode are for and how they work together. Such as the trigger must return true or the ajax_client won't actually make the request to the server. Admittedly that last bit still has to be written into it, but that is where that 'return true;' comes in. [2] http://kemitix.net/repos/cap-ajax/README I suppose this could be the justification for the X in AJAX. :P -- Paul Campbell <[EMAIL PROTECTED]> http://kemitix.net/bitware/ --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
