RE: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)
Hey Randal -- Maybe because it competes with OpenInteract, which is far more established. I don't really think OI and CGI-App are in competition at all. OI attempts to be a uber-framework, a la Mason -- or maybe more like ColdFusion or WebObjects.CGI::Application just focuses on web application state management. CGI::Application doesn't try to bolt on anything else. The developer can choose their favorite modules for templating system, database interface, object persistence, session management, etc. CGI-App is specifically made to allow developers to choose from the best available CPAN libraries, rather than to pre-select for them. You could probably use CGI::Application to implement part of OpenInteract, but you wouldn't use one in lieu of the other. They're not really comparable at all. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)
I'm curious as to why the combination of CGI::Application and HTML::Template hasn't taken off ... CGI::Application seems to allow a software developer to create an entire CGI app that can be stored and distributed as a module on CPAN, but only a couple such app/modules have been so added. Especially since I think I read recently where the very popular Template::Toolkit can be used by CGI::Application in lieu of HTML::Template. --- Dave Baker
Re: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)
Dave == Dave Baker [EMAIL PROTECTED] writes: Dave I'm curious as to why the combination of CGI::Application and Dave HTML::Template hasn't taken off ... CGI::Application seems to allow a Dave software developer to create an entire CGI app that can be stored and Dave distributed as a module on CPAN, but only a couple such app/modules Dave have been so added. Maybe because it competes with OpenInteract, which is far more established. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Templating system opinions (CGI::Application in connection with either HTML::Template or Template::Toolkit)
Hi, That was really interesting to look at. OpenInteract is really impressive. I guess there is always a cost to having a big do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than what CGI::Application offers out of the box, but it may well end up being worthwhile to just extend rather than convert. I really appreciate the simple philosophy that HTML::Template and CGI::Application follow. One question, how do you judge that OpenInteract is more established? Is does look like it is actively developed, but I never heard of it before, and I couldn't find much indication of how popular it is. Thanks, Eric At 09:23 AM 2003-07-23, Randal L. Schwartz wrote: Dave == Dave Baker [EMAIL PROTECTED] writes: Dave I'm curious as to why the combination of CGI::Application and Dave HTML::Template hasn't taken off ... CGI::Application seems to allow a Dave software developer to create an entire CGI app that can be stored and Dave distributed as a module on CPAN, but only a couple such app/modules Dave have been so added. Maybe because it competes with OpenInteract, which is far more established. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! Lead Programmer D.M. Contact Management 250.383.0836
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
On Wed, 23 Jul 2003, Eric wrote: do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than There's a fine book about it. www.masonbook.com Just an unbiased opinion ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
Eric wrote: That was really interesting to look at. OpenInteract is really impressive. I guess there is always a cost to having a big do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than what CGI::Application offers out of the box, but it may well end up being worthwhile to just extend rather than convert. I really appreciate the simple philosophy that HTML::Template and CGI::Application follow. OpenInteract definitely does more for you. But it also has (IMO) a fairly sophisticated way to distribute standalone applications -- including data structures, initial data, security settings, templates and (oh yeah) the actual perl code -- and plug them into another OI server. OI 1.x ties you to the Template Toolkit, but 2.x (a big improvement now in beta) allows you to use whatever templating engine you like. You lose a ton of functionality, but HTML::Template folks seem to like it that way :-) One question, how do you judge that OpenInteract is more established? Is does look like it is actively developed, but I never heard of it before, and I couldn't find much indication of how popular it is. Randal's 'far more established' may be premature :-) Taking a strict time perspective: from Backpan it looks like CGI::Application was first released to CPAN in July 2000, while OI was first released in February 2001. (I'd thought it was October 2000, but it's funny the tricks your memory will play.) As to other definitions of 'established' I haven't followed CGI::Application development to say either way. There have been more articles published on CGI::Application and it seems to have a larger userbase, partly because it's easier to get started with and wrap your head around everything it does. Classic trade-off :-) Good luck! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
Dave Rolsky wrote: There's a fine book about it. www.masonbook.com Just an unbiased opinion ;) Hey, I'd be happy to write a book about OpenInteract ;-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
ANNOUNCE: CGI::Application 3.1
Version 3.1 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://search.cpan.org/dist/CGI-Application/ CHANGES SINCE VERSION 3.0: - Changed dump_html default run-mode to be referenced by name instead of sub-ref. This allows dump_html() to be overridden in sub-class. - Added current run-mode to output of dump() and dump_html(). (Thanks to Mark Stosberg for the suggestion.) - Added example of doing an HTTP redirect (suggested by Sam Tregar) - Fixed bug where non-CGI.pm query objects couldn't be set at initialization time via the new() method. (Thanks to Steve Hay for the catch.) - Added header_type(none) to suppress HTTP header output. (Thanks to Steve Comrie for the suggestion.) - Numerous typos corrected in POD. - Added cgiapp_postrun() hook. This hook allows run-mode output to be pipelined through optional filters, modifying the content and HTTP headers if so desired. Read the article Using CGI::Application on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
ANNOUNCE: CGI::Application::Generator 1.0
Version 1.0 of CGI::Application::Generator is now available via CPAN! Download site for CGI::Application::Generator: http://search.cpan.org/search?dist=CGI-Application-Generator CHANGES SINCE VERSION 0.01: - First release version of CGI::Application::Generator, a module intended to allow the creation of CGI::Application modules dynamically. - Implemented an Object-Oriented interface to specify the functionality of your intended CGI::Application, used to build the structure automatically using a (configurable) template file. CGI::Application::Generator provides a means by which a CGI::Application module can be created from code, as opposed to being written by hand. The goal of this module is two-fold: 1. To ease the creation of new CGI::Application modules. 2. To allow standardization of CGI::Application coding styles to be more uniformly applied. It is also the hope of this module that Computer Assisted Software Engineering (CASE) tools will eventually emerge which will allow the development process for web-based applications to be greatly improved. These CASE tools could more easily convert visual notation (such as UML state-transition diagrams) into method calls to this module, thereby creating actual code. What This Module Does Not Do CGI::Application::Generator is intended to create a shell of an application module based on the specification you provide. It will not output a completely functional application without additional coding. It will, however, handle the creation of all the structural parts of your application common to all CGI::Application-based modules. CGI::Application::Generator is not a system for HTML templates. If you're looking for a Perl module which will allow you to separate Perl from HTML then I recommend you download and install HTML::Template. SUPPORT MAILING LIST If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
ANNOUNCE: CGI::Application 3.0
Version 3.0 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.5: - Changed the run() method to use Perl's built-in dynamic method call for all run modes, whether by name or by code ref. This is intended to improve run-time performance somewhat. Thanks to Darin McBride for this patch. - Added new override-able method cgiapp_get_query(). This method is called when CGI::Application first needs access to the CGI query object. By default, this is a CGI.pm object. It is possible to override the cgiapp_get_query() method to return an object of some other module besides CGI.pm, providing that it is sufficiently compatible. Thanks to Eric Andreychek for the suggestion and his help troubleshooting the code. - Changed run_modes() method to allow list of run-modes to be designated via an array reference. This will automatically create a run-modes table which maps from a run-mode to a run-mode method of the same name. Bumped major revision number to reflect this significant change in functionality. - Clarified license for module (GPL or Artistic). Included licenses in distribution package. Read the recent Using CGI::Application article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED].
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. Thanks for your advice, I am thinking besides the general advice I have received, Apache::DB will be my next most helpfull item. Eric At 02:33 PM 10/14/02 -0400, William McKee wrote: On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I had to read that over a few times to get it. And now I see that I do indeed have that situation, there are a number of times when I call my $holdstatus = new Holds(); from within a module that also has a new method. What I don't understand is how does my code work at all? Thanks, Eric At 07:13 PM 10/14/02 +0200, Rafiq Ismail wrote: On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED] (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 15 Oct 2002 at 7:12, Eric Frazier wrote: I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. That sounds like trouble. The only problem I've had running httpd -X is when I compiled mod_ssl into my server. Apparently, it doesn't like to run in single processor mode (although I haven't confirmed this). Otherwise, the single processor mode should work just like multi-processor. I'd start looking into the code that checks that status. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? Is the data that you're passing to the template correct? Throw in some warn statements. Run it in the debugger if you need to. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
At 11:58 AM 10/14/02 -0400, Perrin Harkins wrote: Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? I have checked the above, and I have lots of warns spaced around so I can watch things in the error log. Is the data that you're passing to the template correct? That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Thanks again, Eric Throw in some warn statements. Run it in the debugger if you need to. - Perrin (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin,
I am starting to feel guilty about bugging you so much, but you are the only
person to have responded, and I watch the list enough to value your advice
quite a bit.
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do the connect
in the new() vs up top outside of a sub.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them
ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from
orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
I did this, I was a little scared about calling $dbh-finish() but I did
what you said, and yes life is good I don't notice a speed difference.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
I have no idea why I put off doing that for so long. But that is done now as
well.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: I wanted the DBH to be global since just about every sub in Holds does a query of some sort. Three options: 1) Pass it to every sub 2) Make a utility sub that returns a dbh and call it from each sub. (Sounds like you already made one of these.) 3) Stuff it in $r-pnotes(), where it will get cleaned up after each request. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's been discussed quite a bit in various places. It is now documented in the perlobj man page: http://perldoc.com/perl5.8.0/pod/perlobj.html#Indirect-Object-Syntax - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Apache::DBI and CGI::Application with lots of modules. (fwd)
On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
RE: Apache::DBI and CGI::Application with lots of modules.
Hey Eric --
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do
the connect
in the new() vs up top outside of a sub.
CGI::Application has a facility which is intended to solve exactly this type
of problem -- the param() method. The param() method allows you to stash a
property (such as a $dbh) in your CGI::Application-based object which can be
retrieved anywhere. I typically connect to the database in my setup()
method and stash my $dbh for use later:
package My::WebApp;
use strict;
use base qw/CGI::Application/;
sub setup {
my $self = shift;
$self-start_mode('start');
$self-run_modes(
'start' = 'run_mode_method'
);
my $dbh = $self-connect_to_database();
$self-param('DBH', $dbh);
}
sub run_mode_method {
my $self = shift;
# Get database handle
my $dbh = $self-param('DBH');
my $output = '';
# ...etc
return $output;
}
Furthermore, in order to disconnect, the teardown() method may be used:
sub teardown {
my $self = shift;
# Get database handle
my $dbh = $self-param('DBH');
$dbh-disconnect();
}
Refer to the CGI::Application POD for details on teardown() and param().
Regarding connecting to the database, I also urge you to encapsulate your
connection code. On my projects I always get things started by creating a
Perl module which I use whenever I need a database connection:
package My::DatabaseCreds;
use DBI;
sub new_dbh {
my $dbh = DBI-connect()
die (Can't connect: .$DBI::errstr) unless ($dbh);
return $dbh;
}
(This isn't exactly the code I use -- I actually have a module which I
sub-class, but you get the idea.)
The benefit of creating a module is that (1) all your Perl code can use this
module so that (2) should it ever have to change you can change it in one
place.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
My guess is that Perrin was referring to your use of the indirect
notation, as opposed to the arrow notation:
Indirect:
my $holdcheck = new Holds()
Arrow:
my $holdcheck = Holds-new()
Many people (myself included) prefer the arrow notation. In general, the
arrow notation tends to be less ambiguous, particularly when it comes to
combining method calls with arguments.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
Re: Apache::DBI and CGI::Application with lots of modules.
Hi,
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't true. It says that
if I have this situation, I will get a warning. I am not getting any
warnings, but I am getting this behaviour with my search queries getting stuck
The only thing I do is again, copied from the perltoot
package Searches;
use strict;
use Carp;
use vars qw($dbh);
use gentimeid; # generate time id based
use Calc_Price; # get totals
use warnings;
# use DBIx::XHTML_Table; # maybe later
use QueryPrint;
#use Data::Dumper;
# These searches are restricted to user level searches, there will be a
admin level search for
# managment reports
$dbh = db_connect();
# requires a $q query object to be init.
sub new {
my $self = {};
my $proto = shift;
my $class = ref($proto) || $proto;
$self-{queryobject} = undef;
$self-{isDomestic} = undef;
$self-{isInternational} = undef;
$self-{isShippingSame} = undef;
$self-{CustIsInserted} = undef;
$self-{OrderIsInserted} = undef;
$self-{CustNum} = undef;
$self-{OrderNum} = undef;
bless ($self, $class);
return $self;
}
sub queryobject {
my $self = shift;
if (_) { $self-{queryobject} = shift }
return $self-{queryobject};
}
Other stuff not used yet
sub LookupOrder {
my $self = shift;
my $q = $self-{queryobject};
my $output = '';
my $hasparameter = 0;
... Build a query from CGI.pm vars passed in though queryobject
...
$order_name_qu .= ORDER BY $orderby ; # the query string is here
if ($hasparameter == 1) { # if something was filled in the search form
my $sth = $dbh-prepare($order_name_qu) or confess(Main search
failed $order_name_qu);
$sth-execute() or confess(Main search failed $order_name_qu);
my $headers = $sth-{'NAME'};
my rows= $sth-fetchall_arrayref();
my $resulthtml = new QueryPrint(ResultSet = rows,
Action = 'customer',
ColumnList = $headers);
my $html = $resulthtml-SetAction(); # sets a template type in the
QueryPrint module
$output = $resulthtml-QueryPrint();
$sth-finish();
#warn QUERY - $order_name_qu;
undef rows;
undef $resulthtml;
undef $order_name_qu;
return $output;
} else {
return no query to do;
}
Then this is all called from my CGI::Application module
sub customer_display{
my $self = shift;
my $q = $self-query();
my $customersearch = new Searches();
$customersearch-queryobject($q); # set the query
my $header = parse_header($self);
return $header . $customersearch-LookupCustName();
}
So going nuts now, where is the problem? My QueryPrint module is pretty
much the same, so if this is ok, it should be as well.
Thanks,
Eric
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
I'm just going to point out a few problems. These are not all related
to your questions.
package Holds;
The case of Holds doesn't match the example sub you posted above. I'm
assuming that was a typo.
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd $status_hnd);
use gentimeid; # generate time id based
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
2. Every once in a while I get an out of memory error.
You can control process growth over time in a number of ways. They are
documented in the mod_perl guide.
3. My main search result page is getting cached, the closure type of
problem.
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
Apache::DBI and CGI::Application with lots of modules.
Hi,
I am glad to see the list traffic has been picking up lately. It makes me
have higher hope about posting this.
First some background info.
I have a fairly large CGI::Application module about 30 run modes that pretty
much follows the example mailform module. I am also using HTML::Template
within the module. I am running on, FreeBSD 4.6 1G mem mysql 4.02 with
Innodb tables.
A typical run mode looks like this.
sub doug_holds {
my $self = shift;
my $q = $self-query();
my $holdtype = $q-param('holdstate');
my $holdsearch = new holds();
$holdsearch-HoldType($holdtype); # set hold type for the query
my $header = parse_header($self);
return $header . $holdsearch-getAllHolds();
}
Of course many of other subs look like this
sub customer_name_search {
my $self = shift;
my $index_page = $self-param('CUSTOMER_NAME_SEARCH_TMPL');
my $output='';
my $tmpl_obj = $self-load_tmpl($index_page,
die_on_bad_params = 0,
cache = 1,
stack_debug =$debug
) or confess(could not create template);
$tmpl_obj-param(base = $self-param('base'));
$tmpl_obj-param(RUNMODE = 'customer_display');
$tmpl_obj-param(USER = $selected_user);
my $header = parse_header($self);
return $header . $tmpl_obj-output;
}
But that isn't relavent to my problem.
In the first sub, I create a new holds instance. Each of these modules like
holds work like this
package Holds;
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd $status_hnd);
use gentimeid; # generate time id based
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
#die $self-{OrdNum}, $self-{HoldReason};
return $self;
}
sub OrdNum {
my $self = shift;
if (_) { $self-{OrdNum} = shift }
return $self-{OrdNum};
}
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
$processed_hnd-execute($self-{OrdNum}) or confess (can't execute
processed);
my ($isprocessed) = $processed_hnd-fetchrow_array;
$processed_hnd-finish();
if ($isprocessed){
$self-{ProcessStatus} = 1;
return #4EEE94;
}else{
$self-{ProcessStatus} = 0;
return FF;
}
}
..
sub db_connect {
require DBI;
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
}
Most of the modules just have simple subs called db_connect that don't have
prepared statments sitting like this. I did this because I have to check the
status of a LOT of rows and return the display fast. This seemed to work
well at the time. It was defiantly faster that preparing the statement over
and over.
I am running under mod perl 1.x Apache 1.3x, and loading my CGI::App module
and other modules from a start.pl
I am using Apache::DBI and connect_on_init. So I have these problems, they
all seem to be related, but how??
1. Connections are getting lost. I get errors in the log about fetch without
an execute which indicate this. Either the user sees an internal server
error, or else I believe DBI will try to reconnect and the query will then
succeed. But that slows things down when it happens. All I have to do to
these kinds of errors is reload a page very quickly. click, click, click fast..
2. Every once in a while I get an out of memory error.
3. My main search result page is getting cached, the closure type of
problem. ***Sometimes*** All I have read says that because I am using oop
modules and use strict along with use vars that should not happen. I have
not gotten any this variable will not stay shared types of warnings.
for this I have tried specificly undefing the display scalars, the result
sets etc. I just can't seem to find out what var is causing the problem, and
I can't find any examples of closures.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin, I am going to read over this closely, thanks for all of the advice! What frustrats me about the search getting cached/closure thing is that I just don't have any global variables that have anything to do at all with the search results. I have read over and over examples with closures, recognize the example you included as one, but I still can't seem to find it in my own code. I guess I need to take a fresh look again. I did -X httpd and it is happening every time. I think part of what is getting me is I have used mod_perl for smaller things, but now it is a pretty big system. I don't seem to be able to get away with as much :) Also, I am really trying to bring my code level up a notch, but as you pointed out, there are some things I am doing that I don't really understand well enough yet. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
ANNOUNCE: CGI::Application 2.6
Version 2.6 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.5: - Changed the run() method to use Perl's built-in dynamic method call for all run modes, whether by name or by code ref. This is intended to improve run-time performance somewhat. Thanks to Darin McBride for this patch. - Added new override-able method cgiapp_get_query(). This method is called when CGI::Application first needs access to the CGI query object. By default, this is a CGI.pm object. It is possible to override the cgiapp_get_query() method to return an object of some other module besides CGI.pm, providing that it is sufficiently compatible. Thanks to Eric Andreychek for the suggestion and his help troubleshooting the code. Read the recent Using CGI::Application article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
CGI::Application
Hi, I am still working on building a framework, design plan for this busy site I am working on. It is a total revamp so I have the chance to do things right I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I have decided to make my modules class modules instead of traditional modules, and thanks to Perrin's great article, I have a lot more confidence in my basic plan. There are some differences between our site and etoyz. Our site is not nearly as loaded. Busy, but not giant. Still, I would like to build something that can get that big without another total rewrite, moving things around, new hardware sure, but not a whole change to the system. Right now things are small enough that the rewrite will only take a few weeks. So I am looking for gotchas, and other problems that could come esp from CGI::Application because it doesn't make much mention of working under mod_perl. I think the modes could be appealing to the PHP guys in my office. It could give them something to chear about, since I think right now they just look at mod_perl as being more work than PHP which is probably true. I am also sure that the HTML templates will make the boss very happy because he is always changing HTML in scripts and breaking the scripts, then calling and saying, hey the form isn't working anymore! :( The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
On Sun, 16 Jun 2002, Eric Frazier wrote: I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I do! Back when I worked for Jesse Erlbaum (the author of CGI::Application) most of our development was in CGIs designed to be run under Apache::Registry. CGI::Application uses CGI.pm for all its CGI services and CGI.pm works great under Apache::Registry. The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. That sounds like an excelent goal. Feel free to drop by the CGI::Application (and HTML::Template) mailing-list if you run into trouble. -sam
Re: CGI::Application
soapbox
Grr. Why can't people just write bloody applications with HTML in them
instead of spending so much energy tryuing to find a way to avoid writing
any HTML?
I mean, it's not that hard. Formulate what you want parts to do, make a sort
of vanilla, unformatted output here-doc ior template file for each part as
necessary, get the functionality going, then prety it up by copying each
here-doc or template file into Dreamweaver or something, formatting the HTML
to look nice, and then moving the formattted html back in.
Template. Mason. Yecch. I feel mildly nauseated every time I hear about
stuff like Mason and similar cop-outs. If people would spend half the time
learning to output their own HTML that they do trying to find ways around
doing so, they'd get a lot more programs written, and there would be less
ugly, clunky, messy, badly-interfacd, hard-to-use and ungodly slow web
applications out there.
I'm still distastefully amazed when I find people using CGI.pm to print a
content-type header on something that in no other way uses CGI.pm, has no
cookies, or anything else. Yes, I have actually seen someone use CGI to do
nothign more than dump their environment variables, when a simple;
print Content-type:
text/html\n\ndl\n,map(dt$_/dt\ndd$ENV{%_}/dd\n, sort keys
%ENV),/dl\n;
would do the job perfectly fine.
/soapbox
- Original Message -
From: Eric Frazier [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, June 16, 2002 10:02 AM
Subject: CGI::Application
Hi,
I am still working on building a framework, design plan for this busy site
I
am working on. It is a total revamp so I have the chance to do things
right
I have been looking into HTML::Template which is a lot simper than Embed
perl or the template tool kit. I am wondering if anyone has experence with
using both of these with Registry.pm I have decided to make my modules
class modules instead of traditional modules, and thanks to Perrin's great
article, I have a lot more confidence in my basic plan. There are some
differences between our site and etoyz. Our site is not nearly as loaded.
Busy, but not giant. Still, I would like to build something that can get
that big without another total rewrite, moving things around, new hardware
sure, but not a whole change to the system. Right now things are small
enough that the rewrite will only take a few weeks.
So I am looking for gotchas, and other problems that could come esp from
CGI::Application because it doesn't make much mention of working under
mod_perl. I think the modes could be appealing to the PHP guys in my
office. It could give them something to chear about, since I think right
now
they just look at mod_perl as being more work than PHP which is probably
true. I am also sure that the HTML templates will make the boss very happy
because he is always changing HTML in scripts and breaking the scripts,
then
calling and saying, hey the form isn't working anymore! :(
The big points I want to achieve right now, is to make everything I write
OOP, separate HTML from code as much as possible, and to not make it
impossible to deal with for the people I work with who don't know as much
perl as I do.
Thanks,
Eric
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
At 01:06 PM 6/16/02 -0400, Sam Tregar wrote: On Sun, 16 Jun 2002, Eric Frazier wrote: I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I do! Back when I worked for Jesse Erlbaum (the author of CGI::Application) most of our development was in CGIs designed to be run under Apache::Registry. CGI::Application uses CGI.pm for all its CGI services and CGI.pm works great under Apache::Registry. Well I was hoping for some 3rd parties :) That is great news! The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. That sounds like an excelent goal. Feel free to drop by the CGI::Application (and HTML::Template) mailing-list if you run into trouble. -sam Thanks Sam, It is pretty cool, the more serious work I have to do, the more I appreciate the mod_perl list. I am starting to think that in general mod_perl guys are nice guys :) Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
Hi,
I think mostly it is about having standards and in a business env making it
so that people who only know part of the picture can still work on the
project as a whole. Sounds like OOP huh? HTML in perl scripts just messes
that whole thing up, like I said before, our fearless leader can mess up
stuff now because HTML is in the scripts and he then edits the scripts,
messes *something* up and we have to fix it.(I an new btw just started 3
weeks ago and am cleaning up the mess). Well then, put the HTML in a
module, fine you can do that, but then why not make a system that makes
doing that basic idea easy? And even a system that once you choose to use it
will not get altered and played with by every programer on staff.
I do agree about the CGI pm stuff though. It is goofy to use print header
instead of print content type but still that is getting kind of anal. If it
really matters to your scripts then that would be kind of weird.
Thanks for your thoughts,
Eric
At 01:28 PM 6/16/02 -0400, Dodger wrote:
soapbox
Grr. Why can't people just write bloody applications with HTML in them
instead of spending so much energy tryuing to find a way to avoid writing
any HTML?
I mean, it's not that hard. Formulate what you want parts to do, make a sort
of vanilla, unformatted output here-doc ior template file for each part as
necessary, get the functionality going, then prety it up by copying each
here-doc or template file into Dreamweaver or something, formatting the HTML
to look nice, and then moving the formattted html back in.
Template. Mason. Yecch. I feel mildly nauseated every time I hear about
stuff like Mason and similar cop-outs. If people would spend half the time
learning to output their own HTML that they do trying to find ways around
doing so, they'd get a lot more programs written, and there would be less
ugly, clunky, messy, badly-interfacd, hard-to-use and ungodly slow web
applications out there.
I'm still distastefully amazed when I find people using CGI.pm to print a
content-type header on something that in no other way uses CGI.pm, has no
cookies, or anything else. Yes, I have actually seen someone use CGI to do
nothign more than dump their environment variables, when a simple;
print Content-type:
text/html\n\ndl\n,map(dt$_/dt\ndd$ENV{%_}/dd\n, sort keys
%ENV),/dl\n;
would do the job perfectly fine.
/soapbox
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: CGI::Application
Dodger opined on the soapbox: Grr. Why can't people just write bloody applications with HTML in them instead of spending so much energy tryuing to find a way to avoid writing any HTML? Because I don't want to have to go find a!@#$*^$ Perl programmer every time the marketing department or a customer wants their website re-themed. And being a Perl programmer, thank deity-of-choice Perl programmers cost more than HTML coders. Because I don't want to have to figure out what *your* code was doing when you wrote it two years ago and are now long, long since gone. *THAT* is why everyone is so interested in Mason, Template, XSLT and all of the other templating technologies. It's a simple business decision. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Re: CGI::Application
On Sunday, June 16, 2002, at 07:02 AM, Eric Frazier wrote: The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. One thing that has proven immensely beneficial on the project that I'm working on now, which is very similar to yours in that it's a complete redo intended to be 'right', is this: Write each page's functionality in a package that is 100% removed, interface-wise, from HTML, then 'glue' that module to HTML (via HTML::Template for output and CGI.pm for input) in a module name identical to, but preceded by Apache:: So, we have a page module like: Functionality in CompanyName::page1, and glue code in Companyname::Apache::page1 Modules NOT under the CompanyName:: namespace cannot be dependent IN ANY WAY on mod_perl, but must be mod_perl clean, of course. This makes the module functionality very easy to test WITHOUT firing up Apache. We have a complete white box test suite that tests at the Perl level, and complete black box test suite that tests at the HTTP level. This proved a good strategy when we decided to implement a SOAP interface to some of our functionality. We made some new glue code in CompanyName::SOAP::page1 that was based on SOAP::Lite and it was just as easy as it should be, with 100% code reuse. -- -- Tom Mornini -- InfoMania Printing and Prepress -- -- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini
ANNOUNCE -- CGI::Application 2.4
Version 2.4 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.1: - Added new module CGI::Application::Mailform as both an example of how to use CGI::Application and a useful (albeit simple) reusable web-based application. - CGI::Application::Mailform allows the contents of data submitted through HTML forms to be easily sent via email to a specified recipient. This application is intended to be very easy to reuse, yet secure and functional enough to replace some of the most onerous mailform scripts which have been floating around the Internet for ages. - Added cgiapp_prerun() hook, for adding global behaviors before the run-mode method is called. The cgiapp_prerun() gets the name of the run-mode as a parameter. This would allow the user to perform some action based on the current run-mode. - Fixed minor bug in build system for older Perl versions. - Modified tmpl_path() to propagate to HTML::Template's PATH parameter. This provides much more useful and intuitive behavior. Thanks to Sam Tregar for the patch! - Added prerun_mode() method to allow the run-mode to be dynamically changed inside the cgiapp_prerun() method. Thanks to Steve Comrie for the suggestion of using a method call for this function. Thanks to many other list members for further refining this idea. - Refactored some test cases, general code clean-up. - Refactored POD a bit to make it less intimidating for new users. Read the recent Using CGI::Application article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED].
ANNOUNCE: CGI::Application::MailPage 1.0
I've got a new module to introduce - CGI::Application::MailPage. It's a little CGI::Application module that allows users to send HTML documents to their friends via email. It's configurable in a number of useful directions and useful if you need this sort of thing. However, it's also a proof of concept - that CGI::Application can enable the distribution of small, configurable CGI apps via CPAN. So, without further ado, I give you a module created almost two years ago and aged to perfection in the moldy depths of my home directory: CGI::Application::MailPage - module to allow users to send HTML pages by email This module is a CGI::Application module that allows users to send HTML pages to their friends. This module provides the functionality behind a typical Mail This Page To A Friend link. AVAILABILITY This module is available on SourceForge. Download it at: http://sourceforge.net/project/showfiles.php?group_id=12636 The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ AUTHOR Copyright 2000-2002, Sam Tregar ([EMAIL PROTECTED]). Questions, bug reports and suggestions can be sent to the CGI::Application mailing list. You can subscribe by sending a blank message to [EMAIL PROTECTED] See you there! LICENSE This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
ANNOUNCE -- CGI::Application v2.1
Version 2.1 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.0: - The param() method has been extended to allow multiple parameters to be set at one time, via a hash (or hashref). - Fixed bug in run() method where a null-string run-mode would be considered valid. A zero-length run-mode will now result in the start_mode() being called. (Thanks to Mark Stosberg for the two preceding ideas!) - The run_mode() method now may be called a subsequent time to amend the list of run-modes. Read the recent Using CGI::Application article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Erlbaum ... CTO [EMAIL PROTECTED] . Vanguard Media v: 212.242.5317 x115 .. New York City +-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+
ANNOUNCE: CGI::Application 2.0
Version 2.0 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 1.31: - Added ability to set mode_param() to use a call-back instance method (specified by subref) instead of a CGI parameter. - HTML::Template is now only loaded if load_tmpl() is called. (Thanks to Stephen Howard for the two preceding ideas!) - Run-modes may now return scalar-refs in addition to scalars. - Added new run-mode of last resort: AUTOLOAD. See POD for usage. - Updated MAJOR REVISION number to 2 -- new functionality deserves it. Read the recent Using CGI::Application article on Perl.com for an overview of the module and its usage: http://www.perl.com/pub/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED]. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Erlbaum ... CTO [EMAIL PROTECTED] . Vanguard Media v: 212.242.5317 x115 .. New York City +-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+
Re: segmentation fault with CGI::Application
On Wed, 19 Jul 2000, Michael J Schout wrote:
I have been trying to get CGI::Application to work under mod_perl today. So
far with no success.
Finally I removed everything except CGI::Application from the config files, and
the server dumps core on startup.
I have a very stripped odwn httpd.conf that basically loads the bare minimum
apache modules, then does "PerlModule CGI::Appliation".
Starting httpd dumps core when it tries to start up.
Running it through the debugger produces this:
i think this is one of the bugs fixed by the Perl patch (which will be
in 5.6.1), see:
[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/dilkhumyox/[EMAIL PROTECTED]
the patch below to mod_perl might also fix it.
--- perl_util.c~Tue Jun 13 10:25:38 2000
+++ perl_util.c Tue Jun 13 11:16:45 2000
@@ -547,12 +547,14 @@
{
dTHR;
SV *sv = sv_newmortal();
+COP *old_cop = curcop;
dTHRCTX;
sv_setpvn(sv, "require ", 8);
MP_TRACE_d(fprintf(stderr, "loading perl module '%s'...", name));
sv_catpv(sv, name);
perl_eval_sv(sv, G_DISCARD);
+curcop = old_cop;
if(s) {
if(perl_eval_ok(s) != OK) {
MP_TRACE_d(fprintf(stderr, "not ok\n"));
ANNOUNCE: CGI::Application 1.2
Version 1.2 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ Changes: - Modified load_tmpl() to pass extra params to HTML::Template-new_file(). - Fixed up the docs a bit. - Minor code clean-up. CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of "Run-Modes." Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single "Application Module" which is a Perl module. In your web server's document space there is an "Instance Script" which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to "[EMAIL PROTECTED]". -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Erlbaum ... CTO [EMAIL PROTECTED] . Vanguard Media v: 212.242.5317 x115 .. New York City +-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+
segmentation fault with CGI::Application
I have been trying to get CGI::Application to work under mod_perl today. So far with no success. Finally I removed everything except CGI::Application from the config files, and the server dumps core on startup. I have a very stripped odwn httpd.conf that basically loads the bare minimum apache modules, then does "PerlModule CGI::Appliation". Starting httpd dumps core when it tries to start up. Running it through the debugger produces this: This GDB was configured as "i386-redhat-linux"... Core was generated by `httpd -f /nis.home/mschout/dev/gkgdrs/gkgnsi/conf/redirect/httpd.conf'. Program terminated with signal 11, Segmentation fault. #0 0x80ad4d2 in Perl_gv_init () (gdb) bt #0 0x80ad4d2 in Perl_gv_init () #1 0x80ae690 in Perl_gv_fetchpv () #2 0x806a0a5 in perl_section_hash_init () #3 0x806a375 in perl_section () #4 0x806a16d in perl_section_self_boot () #5 0x8068033 in perl_cmd_module () #6 0x8080519 in invoke_cmd () #7 0x808089c in ap_handle_command () #8 0x80808e8 in ap_srm_command_loop () #9 0x8080c57 in ap_process_resource_config () #10 0x80812e4 in ap_read_config () #11 0x8088bc5 in main () #12 0x400d79cb in __libc_start_main (main=0x80889e0 main, argc=3, argv=0xb904, init=0x8062c24 _init, fini=0x8123e1c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb8fc) at ../sysdeps/generic/libc-start.c:92 Taking out the "PerlModule CGI::Application" line causes the server to start up normally. Taking a quick glance through Application.pm, I dont see anything that should be causing the interpreter to freak out. I suspect the problem is outside of CGI::Application somewhere, but CGI::Application is demonstrating some bug here ;). Anyone have any ideas? I'm using: perl 5.6.0 mod_perl 1.24 Linux 2.2.x Has anyone else gotten CGI::Application to run in this environment? Anyone else seen this? Mike
Re: segmentation fault with CGI::Application [SOLVED]
Ok. Turns out that what the real problem here was that CGI::Application uses CGI::Carp, and I needed a newer version of CGI::Carp. So I seem to have sovled this :) Mike On Wed, 19 Jul 2000, Michael J Schout wrote: I have been trying to get CGI::Application to work under mod_perl today. So far with no success. Finally I removed everything except CGI::Application from the config files, and the server dumps core on startup. I have a very stripped odwn httpd.conf that basically loads the bare minimum apache modules, then does "PerlModule CGI::Appliation". Starting httpd dumps core when it tries to start up. Running it through the debugger produces this: This GDB was configured as "i386-redhat-linux"... Core was generated by `httpd -f /nis.home/mschout/dev/gkgdrs/gkgnsi/conf/redirect/httpd.conf'. Program terminated with signal 11, Segmentation fault. #0 0x80ad4d2 in Perl_gv_init () (gdb) bt #0 0x80ad4d2 in Perl_gv_init () #1 0x80ae690 in Perl_gv_fetchpv () #2 0x806a0a5 in perl_section_hash_init () #3 0x806a375 in perl_section () #4 0x806a16d in perl_section_self_boot () #5 0x8068033 in perl_cmd_module () #6 0x8080519 in invoke_cmd () #7 0x808089c in ap_handle_command () #8 0x80808e8 in ap_srm_command_loop () #9 0x8080c57 in ap_process_resource_config () #10 0x80812e4 in ap_read_config () #11 0x8088bc5 in main () #12 0x400d79cb in __libc_start_main (main=0x80889e0 main, argc=3, argv=0xb904, init=0x8062c24 _init, fini=0x8123e1c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb8fc) at ../sysdeps/generic/libc-start.c:92 Taking out the "PerlModule CGI::Application" line causes the server to start up normally. Taking a quick glance through Application.pm, I dont see anything that should be causing the interpreter to freak out. I suspect the problem is outside of CGI::Application somewhere, but CGI::Application is demonstrating some bug here ;). Anyone have any ideas? I'm using: perl 5.6.0 mod_perl 1.24 Linux 2.2.x Has anyone else gotten CGI::Application to run in this environment? Anyone else seen this? Mike
ANNOUNCE: CGI::Application 1.1
Release version 1.1 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ Changes: - Tweaked test.pl to avoid CGI.pm command line debugging interface which requires user to hit CTRL-D to continue - Added ANNOUNCE file. CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of "Run-Modes." Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single "Application Module" which is a Perl module. In your web server's document space there is an "Instance Script" which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to "[EMAIL PROTECTED]". -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Erlbaum ... CTO [EMAIL PROTECTED] . Vanguard Media v: 212.242.5317 x115 .. New York City +-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+
