RE: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Hi Steve, -Original Message- If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX it's basically a way for web pages to communicate with the server and return information through JavaScript without having to refresh the page. Very cool stuff indeed. I converted their demo app - http://www.modernmethod.com/sajax/sajax- 0.8/php/example_multiply.php to one running on my code using C::A - http://www.unobserved.org/misc/rs/ [*SNIP*] The example uses 2 very simple run-modes, a multiply and a divide run- mode. The divide() run-mode takes advantage of how to handle error messages when communicating with the script remotely. I posted about a similar technology on the list just over a year ago [1]. It uses a library called JSRS [2]. I've written a perl module to interface with the library -- it can be found under the JavaScript::RPC namespace [3]. My module works slightly different in that you need to use it as your base class. Also, method parameters are sent to the sub via @_ rather than through the query string errors are reported just by die()ing. (Though, obviously you could write a module to do things similarly for AJAX) You can see these differences in the demo usage [4]. Anyway, I'm glad that this is finally becoming main-stream -- perhaps it will influence the way we write applications. Cheers, -Brian [1] http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg01593.html [2] http://www.ashleyit.com/rs/ [3] http://search.cpan.org/dist/JavaScript-RPC/ [4] http://search.cpan.org/src/BRICAS/JavaScript-RPC-0.06/demo/jsrpc.pl - 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] Re: RFC: CGI::Application::RunModeCache
Mark, -Original Message- If there's nothing dynamic, why not write out a bunch of HTML files ahead of time, and dispense with CGI::App altogether? Good point, however, part of my goal is to allow all of the HTML-ized Gedcom records to be auto-updated when the Gedcom data file is updated (thus eliminating the need of a generator script). Why? ... I have no idea -- why not? :) -Brian http://www.gordano.com - Messaging for educators. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ 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::RunModeCache
Hi Cees, -Original Message- - you use exit() to short circuit the execution of the program. In a CGI environment that will probably be OK, but in persistant environments that may cause problems. I'm pretty sure that mod_perl overrides CORE::exit so that the program doesn't end, but I'm not so sure about FastCGI and SpeedyCGI. TO get around it would probably require a change to CGI::Application though. I was thinking that might be an issue -- but I haven't been able to find any information that might say either way. As far as I can tell there's no way to short-circuit a CGI::App in a clean way. - you have effectively hijacked the prerun and postrun methods which means they are unavailable to any sub/super classes. This brings me back to my request from many months ago for the ability to register prerun and postrun hooks so that you can have multiple prerun/postrun execution points (patch available here: http://cees.crtconsulting.ca/perl/patches/CGI-Application- 3.21.callbacks.patch) . As an interim solution you may want to include a comment in your docs that lets people know they need to add $self-SUPER::cgiapp_postrun to their own custom cgiapp_postrun method if they use it (same for cgiapp_prerun). Otherwise your cache code stops working. Right. In order for these methods to be called automatically, I've had to use pre-existing and possibly already overridden subs. Ideally I could just tack on to the app flow, but that would require your patch. :) - Is there a specific reason you are using Data::Dumper to flatten the object? I would think that Storable would be a better choice, since it removes the need for the 'eval'. Not a big deal though. No particular reason other than it was there. - maybe a useful addition could be the ability to decide whether a runmode is cachable from within the runmode itself. something like this would do: Yeah, that seems like a more obvious approach. I'll add that in. Thanks! -Brian http://www.gordano.com - Messaging for educators. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ 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::RunModeCache
Hi Sam, -Original Message- Why not just Memoize the methods that access Gedcom.pm? It's not obvious to me that caching the entire page is right choice here. Often-times an application will include dynamic components and static cacheable components on the same page. Well, you're probably right. Since I don't have any dynamic components in the app to speak of, that aspect never crossed my mind. I'll have to think about it -- and I'll probably come out to the conclusion that in a lot of situations the caching in my module is happening at the wrong level. Cache::FileCache is used by default, but you can pass in your own Cache::* to replace it. The Cache::* modules are quite slow in my experience. I've used Cache::Mmap for disk-based caching and I've heard Cache::FastMmap is even better. I'll check 'em out. Thanks! -Brian http://www.gordano.com - Messaging for educators. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] OT: Many HTML select's ... one Data Source
Bill, -Original Message- From: Bill McCormick [mailto:[EMAIL PROTECTED] involved the ability to programmatically link select's together and change the options of one based on the selection of another - without having to submit the form. Not having to submit after each user selection is, of course, key and I think not possible with just Perl/Apache/MySQL ... or is it? While this is perhaps not exactly what you're looking for, you may be interested in JavaScript remote procedure calls. Brent Ashley has a free library [1] [2] for which I've written an accompanying CGI-based server (in Perl of course) [3]. Brent's select-box demo [4] does what you're talking about. HTH, -Brian [1] http://www.ashleyit.com/rs/ [2] http://www.ashleyit.com/rs/jsrs/test.htm [3] http://search.cpan.org/dist/JavaScript-RPC/ [4] http://www.ashleyit.com/rs/jsrs/select/php/select.php http://www.gordano.com - Messaging for educators. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Calling external modules?
Hi Clint,
Correct me if I'm wrong, but I believe $self is already passed to the
sub.
package MyApp;
use base 'CGI::Application';
use strict;
use warnings;
sub setup {
my $self = shift;
$self-run_modes( mode1 = 'Module1::mode1' );
}
package Module1;
sub mode1 {
ref $_[0];
}
1;
prints:
C:\cgiappperl i.pl rm=mode1
Content-Type: text/html; charset=ISO-8859-1
MyApp
HTH,
-Brian
-Original Message-
From: Clint Moore [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 10:59 AM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Calling external modules?
I swear that it is probably something that I am doing but I
can't
for
the life of me figure out where I'm going wrong. I have some
run_modes
defined in a separate file and referenced like this:
sub setup {
my $self = shift;
$self-run_modes(
'mode1' = 'Module::method(\$self)',
'mode2' = 'Module::method2(\$self)',
);
}
In 5.6.0 this worked no problem. Now that I have upgraded to
5.8.x,
I
cannot get this to work for anything.
Now the modules 'use' just fine. But I get ye olde cannot
locate
object method method(\$self) in package Module error when I
actually try to use that run mode in the program. I'm, of course,
'use'ing the Module in the CGI::App subclass package.
The curious thing is that, in setup... i've not tried it
elsewhere,
I
can call new and run the methods off of the module no problem. I
cannot find any reference to possible changes in how 'use' is handled
in 5.8.x that might be relevant to this but maybe I'm looking in the
wrong places or something.
Can someone tell me what I'm doing wrong? I can post more
complete
code if required.
-cm
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://www.gordano.com - Messaging for educators.
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] get_previous_runmode() ?
Hi Michael,
It may be useful for the prerun_mode() function to auto-log any changes
(in an arrayref of some sort) for access later via
get_previous_runmodes().
However, prerun_mode() can only be called during cgiapp_prerun(). Things
get a little odd when we start doing things like Cory suggests (return
$self-main_menu()) in the middle of runmode execution.
I would probably stick with custom logging of runmodes in order to keep
track of all changes:
--- 8 --
sub log_mode {
my $self = shift;
my $mode = shift;
my $prev = $self-param( '_PREV_MODES' );
$prev= [] unless $prev;
push @$prev, $mode;
$self-param( '_PREV_MODES' = $prev );
}
--- 8 --
So, you can access an arrayref of previous runmodes in any function you
desire.
You would have to manually call it before any switches:
$self-log_mode( 'thismode' );
return $self-main_menu;
or in cgiapp_prerun:
$self-log_mode( $mode ); # $mode being what was passed to cgiapp_prerun
$self-prerun_mode( mainmenu );
It's easy to see how things went:
my $prev = $self-param( '_PREV_MODES' );
print prev: $_\n foreach @$prev;
$prev-[0] being the initial runmode, $prev-[ -1 ] being the runmode
prior to the current one.
Someone may have a better solution...
-Brian Cassidy
-Original Message-
From: Michael Hirmke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 11:18 AM
To: [EMAIL PROTECTED]
Subject: [cgiapp] get_previous_runmode() ?
Hi *,
one more question:
Would it be possible for C::A to not only maintain the current
runmode,
but also the previous one? A function like get_previous_runmode()
would
be really nice. What do you think about it?
I know, I can implement it in my own code - that is, what I do at the
moment - but IMHO it would be a desirable improvement for C::A.
http://www.gordano.com - Messaging for educators.
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Re: Re: Weird Error with CGI::App and HTML::Template
Hi Lance,
That's a good idea -- I would always suggest you leverage
HTML::Template's power (and code/content separation) where possible.
I would also suggest that you consider replacing CGI.pm with
CGI::Simple. It's basically CGI.pm without any html generation
capabilities. The nice side-effect of using CGI::Simple is that, in
general, your app will run faster.
Docs:
http://search.cpan.org/author/JFREEMAN/Cgi-Simple-0.06/Simple.pm
Some benchmarks:
http://search.cpan.org/src/JFREEMAN/Cgi-Simple-0.06/cgi-simple_vs_cgi-pm
.html
By default, CGI::App uses CGI.pm. To override this behavior, overload
the cgiapp_get_query() sub.
sub cgiapp_get_query {
my $self = shift;
use CGI::Simple;
my $q = CGI::Simple-new();
return $q;
}
NB: To debug a script that uses CGI::Simple from the command line you'll
have to change the DEBUG level to 1 to get key-value pairs from @ARGV or
2 to get them from STDIN. See the docs for more:
http://search.cpan.org/author/JFREEMAN/Cgi-Simple-0.06/Simple.pm#DEBUGGI
NG
Anyway, HTH,
-Brian
-Original Message-
From: Lance A. Brown [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 2:37 AM
To: CGI Application List
Subject: [cgiapp] Re: Re: Weird Error with CGI::App and HTML::Template
OK. Y'all have convinced me. I'm gonna write the form stuff into the
HTML and pull the CGI.pm calls and see what happens... Bedtime for
bonzo here first, though. We'll see what tomorrow brings.
http://www.gordano.com - Messaging for educators.
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
