[cgiapp] Q on Data::FormValidator filters used in my C::A
Hello All,
The Data::FormValidator docs say:
field_filters
field_filters = {
cc_no = ['digit'],
},
A hash ref with field names as keys. Values are array references of
built-in filters to apply (trim,digit,etc) or an anonymous subroutine
which should take one parameter, the field value and return the
(possibly) modified value.
=
OK so far, I want to use the mentioned anonymous sub. I'm not sure on
the syntax. (How do I specify the input to pass in?) I set up a working
sub MyFilter that takes one param. I tried:
field_filters = {
my_filter = [ \MyFilter() ],
},
That doesn't work, which doesn't surprize me as I don't see how MyFilter
is getting its input.
Your comments and a working example would be much appreciated.
Cheers
--Fred
-Original Message-
From: Michael Peters [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 30, 2005 6:15 AM
To: Tim Colson (tcolson)
Cc: cgiapp@lists.erlbaum.net
Subject: Re: [cgiapp] Layout template ideas?
Tim Colson (tcolson) wrote:
Hey Michael -
I'm wondering if the internal (gooey center) template can
somehow be
reused? (i.e. I may want all the same params set, but just use a
different template file)
I think in most templating systems you just have to make
this decision
in your perl. Just load a different template.
Sorry -- I wasn't clear there. The Gooey Center Template
holds a bunch
of params, ex $tmpl-param(USER=$username). I'd like to wrap that
template -and- have those inside params available to the
wrapper --
without having to re-set them all. So the outside wrapper
could re-use
them. In the java world, I use Velocity and the idea there
is that you
have:
Oh, sorry. I didn't understand what you originally were
asking for. Yes, with TT, using WRAPPER the variables meant
for the inside template are available for the outside as well.
Context + Template = output
And they have the idea of chained contexts...meaning that
one part
of the code can stick stuff (i.e. params) into the context,
and then
another bit of code can grab the context and add more stuff
(i.e. more
params).
But in the cgiapp_postrun method, all the params set by the
action are
essentially lost, eh? :-(
If you use Template Toolkit this is very easy
Thanks for the example! That is what I'm looking for, so it
may force
me to dig into TT.
I had hoped to stay with H:T because I really don't like having all
the other bells available to the template. And because, well, HT is
easy and I'm lazy. grin
That's actually why I stayed away from TT for a while too.
All the examples show doing what is, IMO, a bad idea for
templates: doing DB queries, etc.
I basically confine myself to the features of TT that H::T
has except for the following:
+ WRAPPER
+ Boolean logic (OR and AND)
+ Using object methods (almost always accessor methods, ala
Class::DBI), and direct access to hashes. This is especially
helpful to keep things like date formatting within the template.
And sometimes I like the following, although it's not
strictly necessary:
+ Including templates with arguments. This is especially
helpful for recursive templates (eg, a threaded discussion)
where you can pass the root node to a template much like you
would for a recursive function.
--
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]
-
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]
[cgiapp] Question on passing a list via param method...
Hello all, I'm trying to pass a list via the param method. I don't see this discussed in the docs, and it seems via some brief experiments that I need to pass a reference to an array. Am I missing something? --Fred - 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] XMLHTTPRequest / Remote Scripting / AJAX
Very Fine Work. Thanks for contributing this to the community. Cheers --Fred -Original Message- From: Steve Comrie [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:54 AM To: cgiapp@lists.erlbaum.net Subject: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX Good Afternoon, 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. You can read more about it here: http://www.adaptivepath.com/publications/essays/archives/00038 5.php and see it in action here: http://www.google.com/webhp?hl=encomplete=1 There are currently some useful applications for AJAX and, I'm sure, lots of superfluous ones too. I'm hopeful that the number of useful ones will grow as the technology becomes more wide-spread and easy to use, which brings me to the point of my post. I stumbled across a site called SAJAX (http://www.modernmethod.com/sajax/) today that has developed a *S*imple AJAX method that can be used with Perl, via their Sajax.pm file. After playing around with it for a while, I was able to strip down their code (actually getting rid of all their Perl code, and leaving only the JavaScript, which I edited and packaged up as a .js file) in-order to figure out exactly how AJAX works and more importantly, how to easily integrate it with a CGI::App based module.pm file. 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/ I invite anyone that's interested in learning more about using AJAX to take a look at my sample app. I've provided source files for download from the page which include: - index.html - remotescript.js ( the required javascript library that does all the XMLHTTPRequest magic ) - rscalc.cgi ( C::A instance script ) - RemoteScriptCalc.pm ( C::A Application Module ) 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. As far as I can tell, I see no problem with including a couple of AJAX based run-modes into an existing C::A module (provided you setup the JavaScript on the calling page properly). Hopefully, some others will find this useful and hopefully be able to use it in their C::A apps. I know I intend to implement it soon for apps where I know the browser requirements are met. I didn't document the code very much, but I kept it nice, clean and organized to help readability. Good knowledge of javascript is needed to hack the remotescript.js file, but you don't need to be an expert in-order to use it. If you want to talk about the applications of using XMLHTTPRequest with C::A I'm sure we can keep this on the list, but if you're having trouble getting my sample code to install or work on your server contact me directly so we don't clutter up the list. I'll try and help out time permitting. BTW - I don't know what the exact browser requirements are however, I just know it works on my WinXP IE6 or Firefox. The SAJAX site might have more info on that. That URL again is: http://www.unobserved.org/misc/rs/ Steve Comrie LEAD SOFTWARE ARCHITECT | OCTANE T: 416.977.2525 F: 416.977.8481 355 ADELAIDE ST. W. SUITE 1B TORONTO, ONTARIO M5V 1S2 WWW.OCTANE.TO - 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]
[cgiapp] Document Management
All, In my next project I'll be making a lightweight document management system. The specs are fairly simple: * use existing infrastructure: Oracle DB, perl on vanilla cgi webserver and existing authentication system * Provide upload, storage and access to .PDF, .xls, .doc etc. * Support Meta data like keywords I could write this, but I'm sure there a lots of existing solutions that I could modify. I did a search on document management on perlmonks.org and I didn't find anything even close to what I was thinking of. CPAN search didn't yield anything that appeared to be applicable (I'm sure I'm missing something...). I also looked on sourceforge, and found some projects but they look like they assume MYSQL and apache. Anyone have any helpful pointers to either frameworks, full blown apps, or just Modules that might make this easier? I already know and use CGI::App, HTML::Template, Class::DBI ... Cheers --Fred - 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] Proposal: improving mode_param()
I take it that this works exclusively under mod_perl and not on a vanilla web server.
--Fred
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Mark Stosberg
Sent: Wednesday, September 08, 2004 7:00 PM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Proposal: improving mode_param()
In 2001, I posted on this list a suggestion for improving mode_param:
http://www.mail-archive.com/cgiapp%40lists.vm.com/msg1.html
Years ago, Jesse realized the value of passing the run mode through
PATH_INFO. My own years of experience since then have validated this
as a very functional and efficient technique.
My code has been updated a bit since then. Here's what it looks like
now:
#
sub cgiapp_init {
my $self = shift;
$self-mode_param(\get_mode_param);
}
# This function provides another way to get the CGI::App run mode
# Use the first piece of PATH_INFO, or fall back to the usual technique.
sub get_mode_param {
my $self = shift;
my $pi = $ENV{PATH_INFO};
# remove the leading slash
$pi =~ s!^/!!;
# just grab the first field
$pi = (split q'/', $pi)[0];
return (length $pi) ? $pi : $self-query-param('rm');
}
I would like to again propose that support for this technique be added
to CGI::App directly. It could be done by publishing get_mode_param as
a plugin, but I think it's reasonable for inclusion in the core.
Here's what I have in mind for the API:
$self-mode_param('rm', path_info = 1);
This should be backwards compatible with the current options.
Mark
--
http://mark.stosberg.com/
-
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]
-
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: Report generation...
I should mention that I use Text::CSV and Text::CSV_XS (the difference being pure perl
vs. not AND that the XS version supports binary data in the fields).
# Output
use Text::CSV_XS;
my $csv_out = Text::CSV_XS-new( {'binary' = 1});
while ( my @row = $sth-fetchrow_array ) {
if ( !( $csv_out-combine( @row ) ) )
{ # die if combine fails
die output failed: , $csv_out-status(), \n;
}
$out .= $csv_out-string();
$out .= \n;
}
# testing only
# my $t = $self-load_tmpl('simpleText.tmpl',die_on_bad_params=0);
# $t-param( output_text = $out,);
# return $t-output;
# this is the correct, documented way to do this
$self-header_props(
-type = 'application/x-download',
-Content-Disposition = attachment; filename=$filename,
);
return $out;
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Mark Stosberg
Sent: Tuesday, August 24, 2004 9:12 AM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Re: Report generation...
On 2004-08-24, franki [EMAIL PROTECTED] wrote:
Any idea if that works with openoffice?
I just checked it and it works perfectly and seamlessly on OpenOffice. I
use OpenOffice on my own desktop as my primary office suite.
It is ironic that we have rtf as an open standard for word documents,
but apart from csv there is no similiar open standard for spreadsheets.
There is SYLK:
http://www.jkrieger.de/programming/delphi/sylk.txt
It also works with MS Office and OpenOffice, I believe.
I have never fussed with generating it from Perl, though. (And it
appears there are no Perl modules on CPAN to help you with it).
Mark
-
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]
-
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: Proposal for Error handling runmode
I think it would be a good idea to have this as part of C::A, mostly due to the
reasons tha Cees sited; that it is very simple to understand and use once it has been
written, but it is not necessaraly obvious before it is written.
I do find it interesting that most programmers that use C::A have seperately written
this type functionality but that the code hasn't made its way to the wiki or to CPAN.
Cheers
--Fred
-Original Message-
From: Michael Peters [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 21, 2004 4:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [cgiapp] Re: Proposal for Error handling runmode
Mark Stosberg wrote:
On 2004-08-19, Kinyon, Rob [EMAIL PROTECTED] wrote:
What do folks think about allowing an error-handling runmode within
CGI::Application. Do something like:
sub setup
{
my $self = shift;
$self-error_mode( 'error_in_page' );
$self-SUPER::setup( @_ );
}
Then, within C::A::run(), eval around the call to $rmeth and, if $@ is
set, set $body equal to the result of a call to $self-error_mode. If
that sets $@, then continue as it happens today.
Or maybe have a built in error() sub that would be overridden in the
application. This way, existing C::A wouldn't have to change and
newer apps could benefit from it.
I think this is a useful suggestion. In my own sub-class of
CGI::Application, I have an error handling run mode that I use to send
messages to browser.
Since I don't believe in showing technical gibberish to website
visitors, usually my messages have titles like Technical Failure, or
Insufficient Information, with short descriptions of what's wrong.
[ Thanks about implications. ]
This solution is a little less flexible, because the only input you give
to error_mode is $@. You would then have to parse the string to see
whether you got back a friendly error message (from an intentional
die), or some deadly error from deeper in Perl.
If we do it as an overridden method then it can take any arguments
that you want to recieve. Also, as a built in method it could be
used as Rob suggested earlier to catch any errors from the eval of
the run mode. This would still keep the flexibility that you use now
and would also give the ease of doing something like ...
die 'HERE';
inside of a run mode (while debugging, etc) and still being able to
handle that error as you see fit (showing it inside of the browser,
etc).
Maybe it's just me, but I ran into some issues when trying to run a
C::A as a mod_perl handler and getting CGI::Carp to show
fatalsToBrowser since CGI::Carp does different stuff under mod_perl
with evals. If something like the above had existed in C::A it would
have made things much simpler. Now I'm just tailing the error logs.
It's so simple that I have to wonder whether it's even worth adding to
CGI::App, even as a plug-in.
It is simple and a couple of lines to C::A code would add this
functionality without changing stuff for you or anyone else.
--- /usr/lib/perl5/site_perl/5.8.3/CGI/Application.pm 2004-08-17
12:19:28.0 -0400
+++ Application.pm.modified 2004-08-21 19:09:18.419310432 -0400
@@ -142,7 +142,7 @@
}
else {
$body = eval { $autoload_mode ? $self-$rmeth($rm) :
$self-$rmeth() };
-die Error executing run mode '$rm': $@ if $@;
+$body = $self-cgiapp_error($@, $rm) if $@;
}
# Make sure that $body is not undefined (supress
'uninitialized value' warnings)
@@ -179,6 +179,12 @@
OVERRIDE METHODS
+sub cgiapp_error {
+ my ($self, $error, $rm) = @_;
+die Error executing run mode '$rm': $error if $error;
+}
+
+
sub cgiapp_get_query {
my $self = shift;
How does everyone feel about this?
--
Michael Peters
Developer
Plus Three, LP
-
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]
-
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]
[cgiapp] OFFTOPIC: RE: [cgiapp] FW: A couple of questions for a newbie
Hello Dan, (as an aside, I visited Kiwi land recently and found it amazingly wonderful). I wanted to interject: You don't need Root to install perl modules for your purposes. If you find it troublesome to have the modules installed in the default perl installation, you can simply install the needed modules (compiled or no) in a directory near your script like myModules. In each instance, simply add: use lib ./myModules/; before your use Foo::Bar; Many admins will happy install modules for you, but if not you can work around it. Check out perlmonks.org for a lot of good general info. Cheers --Fred -Original Message- From: Dan Horne [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 1:34 PM To: 'Peter Masiar' Cc: [EMAIL PROTECTED] Subject: [cgiapp] RE: FW: A couple of questions for a newbie Thanks, Peter. The reason I asked about compiling is that if there are any XS module, or c libraries in the module or in the dependencies then I probably can't run with it. My host is pretty good about installing the Perl modules that I request, but I'm not the only one who will be running the app, and other hosts might not be so oliging. Consequently, I'm looking for pure Perl modules. Thanks for your advice re posting. I'll be more careful in future. Dan -Original Message- From: Peter Masiar [mailto:[EMAIL PROTECTED] Sent: Thursday, 5 August 2004 7:58 a.m. To: [EMAIL PROTECTED] Subject: Re: FW: A couple of questions for a newbie Dan Horne wrote: 1. Will CGI::Application work in a shared hosting environment where I won't be able to compile it myself. I'm hoping that I can copy across my installation and set my use lib in my scripts? (I guess this also applies to CGI::Session too). I've had a quick browse through the files and it seems to be okay, but there may be dependencies that I'm not aware of... IMHO you do not have to think about compiling perl programs, unless you run them under mod_perl. What you need to be concerned, IMHO, is about your ability to install CPAN modules - you need root access to do that. Find which modules you need, and talk to your hosting company, or whoever is your root (administrator). Like: is CGI::Application installed? Which missing CPAN modules you can install for me? 2. I'm wondering how people split their application module. My shared host seems to perform okay, so I may be able to stick the whole app in one module, but I'm wondering if anyone has found that it's better to spread the load across a number of modules to reduce compilation time etc. Sadly, mod_perl isn't an option for me Look into email archives - many ways and approaches to split functionality into modules was discussed many times. http://www.mail-archive.com/[EMAIL PROTECTED]/ like here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01876.html Also, IMHO you are much better off asking one question per email thread, with meaningful, related message subject :-) -- Peter Masiar, - 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] - 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] Simple form example using both C-A and H-T?
Here's a really brain dead example:
#
sub report_dump {
my $self = shift;
my $out = Dumper $RCF{report_defs};
my $t = $self-load_tmpl('simpleText.tmpl',die_on_bad_params=0);
$t-param( output_text = $out,);
return $t-output;
}
simpleText.tmpl
html
head
titleUntitled Document/title
meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
/head
body bgcolor=#FF text=#00
pre
!-- tmpl_var output_text --
/pre
/body
/html
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Robert
Sent: Tuesday, August 03, 2004 12:49 PM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Simple form example using both C-A and H-T?
I see how it is done with using only C-A. But I am having a disconnect on
integrating H-T into the picture. Could someone post a simple example? If I
see an example I can run with the rest.
Robert
-
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]
-
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 - C::A::Plugin - abstract base class for plugins
-Original Message- From: Michael Peters [mailto:[EMAIL PROTECTED] Cees: As an example of how it works, I have put up new versions of the CGI::Application::Session and CGI::Application::TT modules on my website (http://cees.crtconsulting.ca/perl/modules/), as well as a tarball containing the actual CGI::Application::Plugin module. Just one more comment/question here. Other modules that use a plugin style architecture usually put them into a ::Plugin namespace (ie, Template::Plugin::DBI). Should we consider doing that here if we are serious about hording up a lot of plugins? Should CGI::Application::TT become CGI::Application::Plugin::TT? I concur, my vote is for: CGI::Application::Plugin::TT - 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]
[cgiapp] OT: top posting
I hope we don't get into a flame war on this. I understand the usenet convention is to NOT top post. In my company email (which I use for this list) the convention IS to top post when replying to emails. I don't care as long as quotes are attributed in some way. --Fred -Original Message- From: Ron Savage [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 5:15 PM To: Perl - CGI-Application Subject: Re: [cgiapp] RE: Caching HTML::Template output under CGI::App On Thu, 22 Jul 2004 00:43:14 +1000, Mike wrote: Hi Mike BTW, is 'top posting' frowned upon in this list server? I am new Some people (and I sure don't mean anyone on this list :-) are a bit fanatical in trying to stop top posting, while it's quite common - but not universal - on other lists (it doesn't matter which lists), so there's no pleasing everyone... Posts to the list should be about communication, not about manipulation. If someone says it's 'normal' or 'usual' or '[insert other emotional blackmail]' to press posters to not top post, they are of course deliberately avoiding the cases where it's the norm. There are bigger things to worry about. -- Ron Savage, [EMAIL PROTECTED] on 22/07/2004. Room EF 312 Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia Phone: +61-3-9251 7067, Fax: +61-3-9251 7604 http://www.deakin.edu.au/~rsav - 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] - 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] Measuring the time taken by the CGI...
Thanks to Cees and Thilo for their inputs.
Here's my JGE (just good enough) solution (see below).
I placed this in my super class that all my instances inherit from.
Note that this output only measures in seconds. The results are replaced into the
comment
!-- ScriptRunTime -- in the output. Any code after cgiapp_postrun isn't counted.
sub cgiapp_postrun {
my $self = shift;
my $output_ref = shift;
# $script_starttime = $^T
# times measured in seconds
my $script_duration = time() - $^T;
$$output_ref =~ s#!-- ScriptRunTime --#BRServer process time: $script_duration
secondsBR#;
} #end cgiapp_postrun
=
Fred Kleindenst [EMAIL PROTECTED]
Internet Platforms
310.302.3801
-Original Message-
From: Kleindenst, Fred
Sent: Tuesday, June 29, 2004 3:41 PM
Cc: [EMAIL PROTECTED]
Subject: [cgiapp] Measuring the time taken by the CGI...
Hello,
I'd like to measure the time taken to execute each particular hit to cgi::app and
display the result.
My thoughts on how to implement this are roughly:
* get the time $T1 in cgiprerun - store in $self
* get the time $T2 in cgipostrun and compute the difference
* output the result as a template param. (is my output out already?)
Anyone done this or something like it already? Thoughts?
-
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]
-
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]
[cgiapp] Measuring the time taken by the CGI...
Hello, I'd like to measure the time taken to execute each particular hit to cgi::app and display the result. My thoughts on how to implement this are roughly: * get the time $T1 in cgiprerun - store in $self * get the time $T2 in cgipostrun and compute the difference * output the result as a template param. (is my output out already?) Anyone done this or something like it already? Thoughts? - 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] load_tmpl() question.
My two cents on load_tmpl: In my work I found that its behavior was not to my taste/needs so ended up overriding it anyway. From the responses, it seems that others have too. Therefore, I concur with William McKee when we says: load_tmpl should be an abstract method that must be overridden in the subclassed module (just like setup) --Fred [ Why did I override load_tmpl? A: I didn't want my app to die when a template was not found, I wanted a more graceful failure mode (at least from the user's point of view) ] = Fred Kleindenst [EMAIL PROTECTED] Internet Platforms 310.302.3801 -Original Message- From: William McKee [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 10:54 AM To: Emanuele Zeppieri Cc: [EMAIL PROTECTED] Subject: Re: [cgiapp] load_tmpl() question. On Fri, Apr 09, 2004 at 05:04:54PM +0200, Emanuele Zeppieri wrote: But then your considerations should apply also to the *existing* load_tmpl() method, since it is a method conceived exactly as an interface to different contructors/methods of other commonly used modules, as you said. I don't think you'll get any argument about this issue from folks who don't use HTML::Template for their template engine. It's legacy code that constantly comes into discussions about how to integrate other template engines with C::A. My current opinion is that load_tmpl should be an abstract method that must be overridden in the subclassed module (just like setup). Plugin libraries could then be provided to handle the load_tmpl method or you can roll your own solution. Cheers, William -- Knowmad Services Inc. http://www.knowmad.com - 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] - 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]
[cgiapp] Question on header_props and meta refresh
Hello all, I'm am busy RTFM right now trying to get the syntax correct on the following: I want to set the header of an HTML page I am returning so that it contains a meta refresh going to another runmode. Why? I plan to display page 1 that contians an interstitial message explaining a long load time for page 2. Can anyone share their one line of code that does this, before I figure it out? --Fred = Fred Kleindenst [EMAIL PROTECTED] Internet Platforms 310.302.3801 -Original Message- From: David Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 4:27 PM To: [EMAIL PROTECTED] Subject: Re: [cgiapp] Questions about CGI Application vrs CGI-Builder Randall, First, I like what I have seen so far of CGI::Application, however, I have seen documentation on the web that indicates CGI::Application has been superseeded by CGI-Builder. Is this true? CGI::Application is designed to fit into many tool environments. It gives you object oriented control over your screens. I use CGI::FormBuilder and CGI.pm both in building application screens. Assuming it isn't, what is the best form generation and validation tool/module to use with CGI::Application given that I already use TT2? I find CGI::FormBuilder easy to use and it also fits right into two common template tools in Perl. I use it almost transparently with CGI::Application. When I need some custom work, I can always use CGI.pm for that part. For commands ... you have to decide how you want to manage it. In one application I parse a file of commands and then display results using CGI::FormBuilder. I use the upload feature to get the file from the PC connected to the server. Then I save the command stream in a common data area that is shared by all users who need to use that command stream. I use a separate object to manage parsing and disemination of the data. Sincerely, David Scott __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - 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] - 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] Question on header_props and meta refresh
Here's the complete runmode for an interstitial:
sub wait_screen {
my $self = shift;
my $t = $self-load_tmpl('wait.tmpl',die_on_bad_params=0);
# Create Link to Actual Run Mode
# This becomes a Meta refresh
my $URL = report.cgi?rm=report_tsv;
$self-header_props(-Refresh=1; URL=$URL);
# pass in some values
#
$t-param(
msg = 'Your Report is being generated. Please wait.',
);
return $t-output;
}
=
Fred Kleindenst [EMAIL PROTECTED]
Internet Platforms
310.302.3801
-Original Message-
From: Kleindenst, Fred
Sent: Thursday, April 01, 2004 11:37 AM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Question on header_props and meta refresh
Hello all,
I'm am busy RTFM right now trying to get the syntax correct on the following:
I want to set the header of an HTML page I am returning so that it contains a meta
refresh going to another runmode.
Why? I plan to display page 1 that contians an interstitial message explaining a long
load time for page 2.
Can anyone share their one line of code that does this, before I figure it out?
--Fred
=
Fred Kleindenst [EMAIL PROTECTED]
Internet Platforms
310.302.3801
-Original Message-
From: David Scott [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 4:27 PM
To: [EMAIL PROTECTED]
Subject: Re: [cgiapp] Questions about CGI Application vrs CGI-Builder
Randall,
First, I like what I have seen so far of
CGI::Application, however, I have seen documentation
on the web that indicates CGI::Application has been
superseeded by CGI-Builder. Is this true?
CGI::Application is designed to fit into many tool
environments. It gives you object oriented control
over your screens.
I use CGI::FormBuilder and CGI.pm both in building
application screens.
Assuming it isn't, what is the best form generation
and validation tool/module to use with
CGI::Application given that I already use TT2?
I find CGI::FormBuilder easy to use and it also fits
right into two common template tools in Perl. I use
it almost transparently with CGI::Application. When I
need some custom work, I can always use CGI.pm for
that part.
For commands ... you have to decide how you want to
manage it. In one application I parse a file of
commands and then display results using
CGI::FormBuilder. I use the upload feature to get the
file from the PC connected to the server. Then I save
the command stream in a common data area that is
shared by all users who need to use that command
stream.
I use a separate object to manage parsing and
disemination of the data.
Sincerely,
David Scott
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
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]
-
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]
-
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]
[cgiapp] Data::FormValidator question in context of CGI::App
All,
I am using Data::FormValidator to provide input checking/constraints/filters for my
CGI::Application.
Data::FV makes it easy to code constraints on $B and $C, or to require $B and $C if $A
exists by setting up rules contained in a hash structure. Like so...
# snip
dependencies =
{ # If A is N, make list of inputs required
A = {
N = [ qw/
admin_contact_fk
+
tech_contact_fk
billing_contact_fk
/ ],
}
},
constraints = { # check these inputs with these subs
dn_id = 'OK_int',
foo = 'OK_chars',
},
# snip
I would like to write a construct so that if Input $A = exists, then Input $B and $C
have to meet certain constraints. If $A isn't one of the inputs, then the $B anc $C
have no constraints
I don't see any way other way, using D::FV, than writing custom constraints that take
in $A, $B, and $C to solve my problem. Is this true?
=
Fred Kleindenst [EMAIL PROTECTED]
Internet Platforms
310.302.3801
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Mark Stosberg
Sent: Tuesday, March 16, 2004 7:37 PM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Re: prerun_mode warning
On 2004-03-16, Darin McBride [EMAIL PROTECTED] wrote:
On March 16, 2004 1:04 pm, Erik Milosevic wrote:
prerun_mode generates a warning whenever it is used to switch a mode in
the cgiapp_prerun hook. This came up before, in the following messages:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01018.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01019.html
The newest version (3.22) still generates this warning. Is there a reason
this behavior is still there? It doesn't seem useful to me, but I may be
missing something.
If it just hasn't been gotten around to, I could submit a quick patch.
As long as you're looking at patches, remove the other $^W use, too,
for autoloads, for exactly the same reason. It's a documented method
of doing something, it shouldn't generate warnings.
I don't like these either. I'll plan to patch CGI::App for these myself.
Documented functionality shouldn't produce warnings, IMO.
Mark
--
http://mark.stosberg.com/
-
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]
-
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] Untaiting in C::A::ValidateRM
After you run check_rm you'll want to use items from $res-valid to put
into the DB to get the untainted entries.
See perldoc Data::FormValidator for the correct syntax.
Cheers
=
Fred Kleindenst [EMAIL PROTECTED]
Internet Platforms
310.302.3801
-Original Message-
From: Wojciech Pietron [mailto:[EMAIL PROTECTED]
Sent: Friday, October 10, 2003 3:41 AM
To: [EMAIL PROTECTED]
Subject: [cgiapp] Untaiting in C::A::ValidateRM
Hi,
I have my script running in taint mode. I found
CGI::Application::ValidateRM module very useful and tried to take
advantage
of it and its untaiting capabilities.
Here is a simple example:
==
use CGI::Application::ValidateRM;
# [...]
$profile = {required = 'USER',
constraint = {
'USER' = 'login'
},
untaint_constraint_fields = [qw|USER|],
validator_packages = [qw|My::Constraints|] # with
match_login definition
};
my ($res, $err_page) = $self-check_rm('login', $profile);
# My match_login looks like:
sub match_login {
my $login = shift;
if ($login =~ /^([\d\w]{3,10})$/) {
return $1;
} else {
return undef;
}
}
==
Validation is successful. After that I try to execute DBI fetch
procedure
with binding variables:
$res = $dbh-selectall_arrayref($sth, {}, $self-query-param('USER'));
And script complains, that $self-query-param('USER') is tainted.
Why?
I will appreciate any help.
Best regards,
Wojciech Pietron
-
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]
-
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]
