Re: [cgiapp] RFC: CGI::Application::Plugin::AJAX v0.02
On 05/07/05, Paul Campbell [EMAIL PROTECTED] wrote: 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. Correcting myself: Etch appears to have upgraded to 4.01 when I wasn't looking. -- Paul Campbell [EMAIL PROTECTED] http://kemitix.net/bitware/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::Plugin::AJAX v0.02
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.
sub index
{
my $self = shift;
my $ajax_client = AJAX_load_client;
my $ajax_init = AJAX_init;
...
my $html = EOT;
html
head
titleKemitix::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.
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.
--
Michael Peters
Developer
Plus Three, LP
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::Plugin::AJAX v0.02
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
titleKemitix::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/cgiapp@lists.erlbaum.net/
[cgiapp] RFC: CGI::Application::Plugin::AJAX v0.02
I'm interested in any feedback anyone might have for this module.
More information:
http://kemitix.net/bitware/2005/07/02/cgiapplicationpluginajax-v002/
Download the code, including demo:
http://kemitix.net/files/cgiapp/CGI-Application-Plugin-AJAX-0.02.tar.gz
###
The buzzword of the moment in web development would appear to be
'AJAX'. Basically it is the use of the JavaScript accessible object
XMLHttpRequest to update the current webpage without have to go
through a complete, and expensive, page refresh cycle with the remote
server. Instead using XMLHttpRequest's asynchronous behaviour and an
appropriate JavaScript callback the updates are performed in the
background. Indeed several could be going on simultaneously.
What I have attempted here with CGI::Application::Plugin::AJAX is to
create a proof of concept that implements a flexible AJAX framework
into a CGI::Application module. The JavaScript comprising the core of
the AJAX client is a modification of [1]SAJAX.
[1] http://www.modernmethod.com/sajax/
I have a standard run-of-the-mill [2]demo. It implements what appears
to be the Hello World of AJAX: Multiply and Divide. There is also a
File Uploader. (Note: the file uploaded sends the file back to you, so
don't upload anything too large, neither you nor I will like it.)
[2] http://kemitix.net/cap-ajax/
Run modes are registered together with the JavaScript involved:
AJAX_register_run_mode
(
'multiply' =
{
# what element to attach the event to
id = 'btnMultiply',
# which event to attach to - onclick is the default if not given
event = 'onclick',
# what to do when the above event it triggered
trigger =
var term1 = ajax_elid('term1').value;
var term2 = ajax_elid('term2').value;
,
# which CGI parameters are passed using which values
# a parameter can be associated with an array for multiple values
cgiargs =
{ # map the cgi argument names to the values
# gathered by the trigger
term1 = 'term1',
term2 = ['term2'],
},
# Once the server replies, this is what we do with the answer
callback =
ajax_elid('result').innerHTML = '= ' + result;
ajax_elid('symbol').innerHTML = '*';
,
}
);
NOTE: Although I have named this module within an existing Namespace,
I am not claiming it. I'm open to suggestions for a more appropriate
name for the plugin.
Thanks for any comments you can give.
--
Paul Campbell
[EMAIL PROTECTED]
http://kemitix.net/bitware/
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC: CGI::Application::Plugin::AJAX v0.02
On Sun, 3 Jul 2005 01:02:49 +0100, Paul Campbell wrote:
Hi Paul
# Once the server replies, this is what we do with the answer
callback =
ajax_elid('result').innerHTML = '= ' + result;
ajax_elid('symbol').innerHTML = '*'; , } );
Which browsers support innerHTML?
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 3/07/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
