On Sat, 17 Dec 2005 14:48:37 -0500, Bruce McKenzie wrote:
Hi Bruce
> There was a thread here in October with a request for an example of
> a simple implementation of CGI::App and Ajax. But then it went on
> and got a little too complicated -- at least I don't see any
Yes, that's a pity.
I suggest you simply try it for yourself. I'll be something worth learning even
if - initially - it's not clear what's going on.
I use JavaScript::RPC::Server::CGI rather than CGI::Ajax, but the end result it
the same. I will try to create a demo or 2 next week. Here's hoping I get an
energy supply for Xmas :-).
With the docs for CGI::Ajax, there are a few things to note (the docs are quite
good, actually, I'll just mention things which are unclear [to me]):
o The synopsis has:
<input type="text" name="val1" id="val1"
onkeyup="exported_func( ['val1'], ['resultdiv'] );">
I think it would have been clearer to say:
name = "some_name"
so that you do not get the wrong idea about the usage of id.
o In section 4 Usage Methods, part 3 Sending Perl Subroutine Output to a
Javascript function, the part in bold is important, but the example below that
uses innerHTML. I've never used innerHTML myself. It would have been clearer if
the author had said: This is just one (1) way to do things.
To be specific, my JS functions populate fields with names such as:
input_add_entity_parent_entity_id
which in this case is defined as:
<select tabindex="1818" name="input_add_entity_parent_entity_id"><option
value="<tmpl_var name=add_primary_parent_id>"><tmpl_var
name=add_primary_parent_name></option></select>
I needed a menu, so I used a select, and I needed to set a default value, hence
the tmpl_vars.
This indicates you can output HTML (here a pop-up menu), not just output passive
text.
It also indicates I did not output to a field identified by a div, because
JavaScript::RPC::Server::CGI does not work that way. I started using this module
before I saw CGI::Ajax was available, but since my file of manually-written JS
functions is over 300 lines long, using the latter module to auto-generate JS,
while /very/ neat, is not an option. Converting my code to use CGI::Ajax is not
worthwhile, on the principle of Don't Fix It If It Ain't Broke. I have nothing
against CGI::Ajax, of course.
This simply indicates that what you do is up to you.
o In part 4 URL/Outside Script CGI::Ajax example, it may not be clear, but in
the example:
my $url = 'scripts/other_script.pl';
my $pjx = new CGI::Ajax( 'external' => $url );
'external' is just some arbitrary name, not a reserved word.
With CGI::Ajax, choosing to use a URL is optional, which is good, whereas with
JavaScript::RPC::Server::CGI, you always do that. Here's a bit of JS:
jsrsExecute('/cgi-bin/mids/rpc-server.cgi',
find_add_primary_parent_callback,
'find_entity', prefix);
where find_add_primary_parent_callback is another JS function which receives the
output from Perl, and 'find_entity' is the Perl sub which gets called.
It's a good design, IMHO, to have a stand-alone CGI script for your AJAX work,
and I also have a Perl module (containing 'find_entity') dedicated to this too.
o Also in part 4 URL/Outside Script CGI::Ajax example, there is:
onClick="exported_func(['args__$input1','args__$input2'],
['resultdiv']);"
I think what the author is saying here is that the Perl script which outputs the
HTML containing this onClick, can pass data values to the Perl script called by
the AJAX process, by using the special prefix 'args__'.
o Dive in!
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 18/12/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
---------------------------------------------------------------------
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]
