Re: Propogating Errors / E-Toys
On Sun, 30 Jun 2002 12:58:08 -0400 Perrin Harkins <[EMAIL PROTECTED]> wrote: : Well, naturally the answer is "it depends." Most database errors can't : be gracefully recovered from, so we would let them propagate up. If it : was possible for a database error to be caused by user input (say, a : duplicate login name) that would need to be caught and handled. It : would also be caught if any special cleanup of non-database resources : was needed. Excellent message, thank you for sharing those experiences once again! I remember the article has a comment regarding a gotcha of the Error module that causes memory leaks, but you didn't go into details there. I took note of that and am using eval instead of the try/catch syntax since I do not understand what the problem is and cannot program avoiding it for sure... I would appreciate very much if you could give further details (maybe a pointer somewhere) on what origines the leak and which was your style writing try/catch blocks once aware of the problem. Thanks, and best regards from template Barcelona, -- fxn
[OT] what drives Amazon?
Does anybody know which is the technology behind Amazon? -- fxn
Re: separating C from V in MVC
On Fri, 14 Jun 2002 10:34:47 +0100 (BST) Mark Fowler <[EMAIL PROTECTED]> wrote: : On Fri, 14 Jun 2002, Nigel Hamilton wrote: : : > Generally I try to minimise the layers/tiers/abstraction between : > the front-end and the database - for me OO/SQL abstraction is something : > akin to 'GOTO considered harmful'. : : The advantage of this is that we get better reuse in out of our SQL when : we need the same function called from many places, and we can reuse the : same SQL on similar tables/databases for different runs. Another : advantage is that should we ever want to change the database all our SQL : is in a few modules and we can make sure that we change all our SQL. Another useful thing is that you can implement some cache mechanism there, in one place, and this is transparent to clients who just keep on calling, say, $category_factory->read_category_tree(), no matter whether the tree is actually fetched from the database or from shared memory. -- fxn
Re: MVC advice..?
On Wed, 29 May 2002 09:22:00 -0400 "Aaron Ross" <[EMAIL PROTECTED]> wrote: : > Is there a neat way of dynamically loading in the appropriate control : > subclass? Something proven and widely used. : : For what it's worth, I use the eval trick too. Although it may seem a : little clunky, I believe it is "proven and widely used". The DBI.pm : module uses code like this to load in the DBD drivers: : : my $driver_class = "DBD::$driver"; : eval "package DBI::_firesafe; require $driver_class"; I wonder, why do you program such a central module that dynamic? Why do you chose that approach instead of this one? package Dispatcher; use Controller1; # ... use ControllerN; sub handler { my $r = Apache::Request->new(shift); my $ctl = $r->param('ctl'); return Controller1::handler($r) if $ctl = 'login'; # ... return ControllerN::handler($r) if $ctl = 'show_cart'; return SERVER_ERROR; } -- fxn
Re: Monitoring the processes
On Mon, 20 May 2002 15:50:35 -0500 Gregory Matthews <[EMAIL PROTECTED]> wrote: : Thanks to everyone for the great input on Memory Leaks. Now that I have a : good starting point for tracking down the problem, when I TEST for leaks, : or simply check for a continued increase in server memory usage, how do I : go about monitoring the processes growth? I have not used it, but it seems Apache::Status can help, see the documentation about the option StatusTerseSizeMainSummary. -- fxn
Re: Memory Leaks
On Mon, 20 May 2002 16:23:40 -0500 Gregory Matthews <[EMAIL PROTECTED]> wrote: : Unfortunately, we only have one machine. If we did employ the cron job as : a clean-up utility once per day, wouldn't the potential impact of a site : being unavailable only be for a few seconds (until Apache restarted)? ... provided one is not using memory as unique storage for sessions or some other data maybe? -- fxn
Re: Memory Leaks
On Mon, 20 May 2002 10:15:02 +0100 (BST) Matt Sergeant <[EMAIL PROTECTED]> wrote: : > my $um = UserManager->new; : > # ... : > try { : > $um->write_user($user); : > $um->dbh->commit; : > } catch Exception::DB with { : > my $e = shift; : > debug "Exception: $e"; : > $um->dbh->rollback; : > }; : : No. $um is caught in a closure, which could potentially leak. Wow, thank you, I have that pattern repeated in the code many times. That is the way I would write that try/catch in Java, where you need to have $um in the scope of the try and the catch blocks, what is the right way to write that in Perl/Error.pm? -- fxn
Re: Memory Leaks
On Sun, 19 May 2002 23:34:24 -0400 "Perrin Harkins" <[EMAIL PROTECTED]> wrote: : Leaks are caused by circular references, the string form of eval (at : least it used to leak a little), nested closures (sometimes created : accidentally with the Error module) I am using the Error module in my current project, what kind of constructs should one avoid? Is this safe? my $um = UserManager->new; # ... try { $um->write_user($user); $um->dbh->commit; } catch Exception::DB with { my $e = shift; debug "Exception: $e"; $um->dbh->rollback; }; -- fxn
Re: [OT] Refs don't work, like I want
On Fri, 17 May 2002 17:10:53 +0300 (EEST) Viljo Marrandi <[EMAIL PROTECTED]> wrote: : $vars->{'key2'} = "value of second key"; The hash $vars points to has a key named "key2". : $vars = { : xxx => "AAA", : yyy => "BBB", : zzz => "CCC", : }; Now you change the reference stored in $var. It points to an entirely new hash, whose keys are "xxx", "yyy" and "zzz". : $vars->{'key1'} = "value of first key"; Here you add the key "key1" to the hash $vars points to. : Problem is, that value of key2 is lost after I set values to xxx, yyy and : zzz, but key1 is ok. $vars contains a reference to a hash that has nothing to do with the first one, you didn't create a key named "key2" in that hash. -- fxn
Re: Desperate for ePerl fix on 5.6.1
On Thu, 9 May 2002 04:29:43 +0100 "Nick Barton" <[EMAIL PROTECTED]> wrote: : I've installed ePerl on FreeBSD 4.5-Stable and have Perl 5.6.1 i386-freebsd. : Running ePerl standalone it reports 'Can't locate loadable object for module : Parse::ePerl' i.e. can't find the C extension. : : What I need to do to the Makefile for eperl to get it to run with perl 5.6.1 : (or 0) Have you installed the ePerl port? It's under /usr/ports/lang/eperl? -- fxn
convention on logging?
I am writing a web application that uses Apache modules and core classes in a MVC style. AFAICT using $r->log->debug() is the standard way to print debug messages in Apache modules, but which would be the right way to print debug messages in the core classes provided both types of modules are going to run together? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Mon, 06 May 2002 10:04:28 -0400 Fran Fabrizio <[EMAIL PROTECTED]> wrote: : >Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key : >file has to be set before the PerlModule directive, it is a bug in the : >documentation. : > : Except it doesn't really, because it works fine for me. =) : : I compiled mod_perl static, I tend to avoid DSO if possible. The Eagle book says (page 58): Apache processes the configuration directives on a first-come, first-serve basis, so in certain cases, the order in which directives appear is important. So Apache passes PerlModule and PerlSetVar to mod_perl as it finds it in its configuration file. If mod_perl loaded modules as they come by means of PerlModule that would explain why variables set with PerlSetVar after that directive are not seen by the very module at loading time. As that seems to be the behaviour in my static mod_perl and Jacob Davies said he had to change the documentation (and he knows more mod_perl than I for sure), I don't understand why the order does not matter in your machine. Do we have the same version of the module (v1.18)? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Fri, 3 May 2002 22:02:18 -0700 "Jim Helm" <[EMAIL PROTECTED]> wrote: : I was having the exact same problem 2 days ago... Could it be a : difference in static vs. dso? I'm running mod_perl as a dso - how about : you two? I compiled httpd. Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key file has to be set before the PerlModule directive, it is a bug in the documentation. -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Fri, 03 May 2002 09:09:08 -0400 Fran Fabrizio <[EMAIL PROTECTED]> wrote: : > : > : >Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile : >has solved the problem. I am doing something wrong or the example in the : >manual page would need to be modified? : > : That's odd, I load my module first before setting the secret key (or any : of the other variables) and it works fine for me. If the module was loaded when the server sees the "PerlModule" directive I think this code from Apache::AuthCookieDBI (version 1.18) implies that variable in particular needs to be set before: #=== # S E R V E R S T A R T I N I T I A L I Z A T I O N #=== BEGIN { my @keyfile_vars = grep { $_ =~ /DBI_SecretKeyFile$/ } keys %{ Apache->server->dir_config() }; foreach my $keyfile_var ( @keyfile_vars ) { my $keyfile = Apache->server->dir_config( $keyfile_var ); my $auth_name = $keyfile_var; $auth_name =~ s/DBI_SecretKeyFile$//; unless ( open( KEY, "<$keyfile" ) ) { Apache::log_error( "Could not open keyfile for $auth_name in file $keyfile" ); } else { Apache::warn("Adding key for realm $auth_name"); $SECRET_KEYS{ $auth_name } = ; close KEY; } } } Does the server load the module that way? -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Thu, 2 May 2002 20:10:15 +0200 F. Xavier Noria <[EMAIL PROTECTED]> wrote: : I am having problems configuring Apache::AuthCookieDBI and am a bit : lost, since it seems there is something wrong with the secret key : file I cannot see, I attach below the configuration in case it can : help. I have checked the permissions of the file (the server runs : in by box as "fxn"): The problem, it seems, was that I was setting the variables used by the module _after_ loading it, as in the example of its manual page: PerlModule Apache::AuthCookieDBI PerlSetVar BuscaWAPPath / PerlSetVar BuscaWAPLoginScript "/cgi/login.pl" # These must be set PerlSetVar BuscaWAPDBI_DSN "dbi:Oracle:BW_CATALOG" PerlSetVar BuscaWAPDBI_SecretKeyFile "/home/fxn/prj/bw/buscawap/etc/auth.key" Apache::AuthCookieDBI reads its config variables in a BEGIN block. I inserted a trace there and keys %{ Apache->server->dir_config() }; returned no variable set via PerlSetVar after that PerlModule directive. So the hash %SECRET_KEYS, initialized there, had no entries. Moreover, when I tried to access a protected URL as localhost/docs I was redirected to /cgi/login.pl as configured (as you see, after PerlModule as well), which confused me. I suppose this is so because the module sees the variable at runtime, where the config file has been already fully read. Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile has solved the problem. I am doing something wrong or the example in the manual page would need to be modified? -- fxn
Re: problems setting up Apache::AuthCookieDBI
On Thu, 02 May 2002 15:22:59 -0400 Fran Fabrizio <[EMAIL PROTECTED]> wrote: : Do you have this in httpd.conf (or mod_perl.conf) : : PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key : : ? I have all mod_perl-related things in mod_perl.conf, and httpd.conf ends with this line: Include /home/fxn/prj/bw/buscawap/etc/mod_perl.conf Could that matter? -- fxn
Re: problems setting up Apache::AuthCookieDBI
On Thu, 02 May 2002 20:24:10 +0200 Per Einar Ellefsen <[EMAIL PROTECTED]> wrote: : At 20:10 02.05.2002, F.Xavier Noria wrote: : >PerlModule Apache::AuthCookieDBI : > : >PerlSetVar BuscaWAPPath / : >PerlSetVar BuscaWAPLoginScript "/cgi/login.pl" : > : ># These must be set : >PerlSetVar BuscaWAPDBI_DSN "dbi:Oracle:BW_CATALOG" : >PerlSetVar BuscaWAPDBI_SecretKeyFile "/home/fxn/prj/bw/buscawap/etc/auth.key" : : Have you tried inserting these into the respective sections? I'm : not sure, but I think PerlSetVars aren't merged into location-specific : configuration, so they might not actually be caught by Apache::AuthCookieDBI I guess this is not the problem since /cgi/login.pl gets run by the module and is configured the same way. Thank you anyway! -- fxn
problems setting up Apache::AuthCookieDBI
I am having problems configuring Apache::AuthCookieDBI and am a bit lost, since it seems there is something wrong with the secret key file I cannot see, I attach below the configuration in case it can help. I have checked the permissions of the file (the server runs in by box as "fxn"): $ ls -la /home/fxn/prj/bw/buscawap/etc/auth.key -rw---1 fxn12 May 2 19:20 /home/fxn/prj/bw/buscawap/etc/auth.key If I request "/docs" these messages appear in error_log: [Thu May 2 20:07:19 2002] [error] access to /login failed for 127.0.0.1, reason: Apache::AuthCookieDBI: didn't have the secret key for auth realm Busc aWAP [Thu May 2 20:07:21 2002] [error] access to /docs failed for 127.0.0.1, reason: Apache::AuthCookieDBI: didn't the secret key from for auth realm Busca WAP Any hint on what could I be doing wrong? -- fxn PerlModule Apache::AuthCookieDBI PerlSetVar BuscaWAPPath / PerlSetVar BuscaWAPLoginScript "/cgi/login.pl" # These must be set PerlSetVar BuscaWAPDBI_DSN "dbi:Oracle:BW_CATALOG" PerlSetVar BuscaWAPDBI_SecretKeyFile "/home/fxn/prj/bw/buscawap/etc/auth.key" # These are optional, the module sets sensible defaults. PerlSetVar BuscaWAPDBI_User"wap" PerlSetVar BuscaWAPDBI_Password"X" PerlSetVar BuscaWAPDBI_UsersTable "view_active_users" PerlSetVar BuscaWAPDBI_UserField "login" PerlSetVar BuscaWAPDBI_PasswordField "password" PerlSetVar BuscaWAPDBI_CryptType "none" PerlSetVar BuscaWAPDBI_GroupsTable "view_active_users" PerlSetVar BuscaWAPDBI_GroupField "rol" PerlSetVar BuscaWAPDBI_GroupUserField "login" PerlSetVar BuscaWAPDBI_EncryptionType "none" PerlSetVar BuscaWAPDBI_SessionLifetime 00-24-00-00 AuthTypeApache::AuthCookieDBI AuthNameBuscaWAP SetHandler perl-script PerlHandler Apache::AuthCookieDBI->login Alias /cgi /home/fxn/prj/bw/buscawap/www/cgi/ PerlModule Apache::Registry SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI AuthType Apache::AuthCookieDBI AuthName BuscaWAP PerlAuthenHandler Apache::AuthCookieDBI->authenticate PerlAuthzHandler Apache::AuthCookieDBI->authorize require valid-user SetHandlerperl-script PerlHandler BuscaWAP::Apache::Docs
Re: Client capabilities
On Tue, 30 Apr 2002 16:26:00 +0400 "Mike V. Andreev" <[EMAIL PROTECTED]> wrote: : On Tue, 30 Apr 2002 13:00:33 +0100 : Simon Oliver <[EMAIL PROTECTED]> wrote: : : SO> The main problem is that a client can be modified from the "standard" : SO> install to prevent JavaScript, StyleSheets, Images, etc and there is no : SO> way to detect this server side. : : (and some text-based browsers can be configured to use external program : to show images on user request [links for example] ) w3m renders images indeed :-). -- fxn
Re: How to generate pre-filled forms? (fwd)
On 29 Apr 2002 09:16:42 +1000 simran <[EMAIL PROTECTED]> wrote: : Have a look at the HTML::FillInForm module as well... Yeah, thank you, I'll give it a try. I guess this is a natural candidate for an output chain, the HTML generated by two or three Apache modules will need that post-process, so I plan to use HTML::FillInForm with Apache::Filter, it will be the first application of my recent study of the Cookbook I couldn't have produced before I read it, magnific! -- fxn
Re: Basic usage of Apache::Session::Oracle
On Mon, 29 Apr 2002 01:11:59 +0200 "F.Xavier Noria" <[EMAIL PROTECTED]> wrote: : If I understand it correctly, Apache::Session::Oracle uses a table : called "sessions" with at least two columns, one called "id", of type : "varchar2(32)", and another called "a_session", of type "long". I am sorry this question has arrived several times, I didn't receive it for hours and I thought something went wrong with previous attempts. -- fxn
Basic usage of Apache::Session::Oracle
If I understand it correctly, Apache::Session::Oracle uses a table called "sessions" with at least two columns, one called "id", of type "varchar2(32)", and another called "a_session", of type "long". Say I want to store a pair of things in sessions: a reference to an object of type User (which includes a reference to an object of type UserManager) and a timestamp to know when we received the last request from that session. Apart from that reference in the user, both classes consist of primitive attributes, IDs, names, strings with SQL, and the like. 1. Is the reference to the user storable? (My doubt here is "what kind of things are not serializable" indeed, I have a vague idea of this, I think I cannot store a reference to a db handler, or a file handle, but I cannot respond accurately to that question in general.) 2. Do I need to create more columns in the table or everything goes to the "a_session" column? 3. Could one set up things in a way that allows the database to see the timestamps and program a trigger to delete old sessions? Or is there a standard idiom for doing this in a different way? Thank you very much, -- fxn
Basic usage of Apache::Session::Oracle
If I understand it correctly, Apache::Session::Oracle uses a table called "sessions" with at least two columns, one called "id", of type "varchar2(32)", and another called "a_session", of type "long". Say I want to store a pair of things in sessions: a reference to an object of type User (which includes a reference to an object of type UserManager) and a timestamp to know when we received the last request from that session. Apart from that reference in the user, both classes consist of primitive attributes, IDs, names, strings with SQL, and the like. 1. Is the reference to the user storable? (My doubt here is "what kind of things are not serializable" indeed, I have a vague idea of this, I think I cannot store a reference to a db handler, or a file handle, but I cannot respond accurately to that question in general.) 2. Do I need to create more columns in the table or everything goes to the "a_session" column? 3. Could one set up things in a way that allows the database to see the timestamps and program a trigger to delete old sessions? Or is there a standard idiom for doing this in a different way? Thank you very much, -- fxn
Basic usage of Apache::Session::Oracle
If I understand it correctly, Apache::Session::Oracle uses a table called "sessions" with at least two columns, one called "id", of type "varchar2(32)", and another called "a_session", of type "long". Say I want to store a pair of things in sessions: a reference to an object of type User (which includes a reference to an object of type UserManager) and a timestamp to know when we received the last request from that session. Apart from that reference in the user, both classes consist of primitive attributes, IDs, names, strings with SQL, and the like. 1. Is the reference to the user storable? (My doubt here is "what kind of things are not serializable" indeed, I have a vague idea of this, I think I cannot store a reference to a db handler, or a file handle, but I cannot respond accurately to that question in general.) 2. Do I need to create more columns in the table or everything goes to the "a_session" column? 3. Could one set up things in a way that allows the database to see the timestamps and program a trigger to delete old sessions? Or is there a standard idiom for doing this in a different way? Thank you very much, -- fxn
Re: How to generate pre-filled forms?
On Fri, 26 Apr 2002 16:15:52 +0200 F. Xavier Noria <[EMAIL PROTECTED]> wrote: : I am writing some modules that receive a form, process it, and return a : page that includes that very form. Is there a standard way to fill that : returned form so the user sees the same data he sent there, as CGI.pm : does? : PS: I am using Apache modules + HTML::Template if that matters. I summarize the approaches I've found: * Generating everything in the module as usual, maybe storing s or things that complicated in template plain variables instead of putting them in the very template. * One can pass an object reference to a template as long as it has a method called "param" that behaves as CGI::param(). The idea is that will be translated to $r->param('color'). * HTML::FillInForm parses an already constructed HTML page and fills its forms out of the box invoking a param() method on a passed reference, as above. I think is what I'll choose. I'd need to know now wheter Apache::Request's param() is OK here. Thank you! -- fxn
How to generate pre-filled forms?
I am writing some modules that receive a form, process it, and return a page that includes that very form. Is there a standard way to fill that returned form so the user sees the same data he sent there, as CGI.pm does? -- fxn PS: I am using Apache modules + HTML::Template if that matters.
[OT] Doubt on directories for development
I am working in my first mod_perl real-life project, I would like to ask you for a directory layout for development. The fact is that developers in my team have Apache under /usr/local in Linux machines, but we would prefer to develop as normal users, not as www or nobody, though that will be the user in production. What is the standard way to configure things for that? We have created somehow the Apache directory layout under the root of the project tree and call httpd -f project_root/conf/httpd.conf, where we customize the user and group (in my case fxn), full paths to log and pid files writable but that user, etc. but ServerRoot is /usr/local/apache and the original modules under /usr/local/apache are there, so we cannot use $r->server_root_relative to access, say, to application config files which seems to be standard (and quite natural) idiom. The httpd.conf in CVS is a template customized once per-machine with a script. I would appreciate any hint very much, we could begin right with a good layout next Monday. Thank you very much! -- fxn
Re: XML::RPC
On Sun, 21 Apr 2002 10:50:53 +0100 Matthew Byng-Maddick <[EMAIL PROTECTED]> wrote: : On Sun, Apr 21, 2002 at 03:16:53AM -0400, Sam Tregar wrote: : > SOAP::Lite module to be of excelent quality and the SOAP::Lite community : > to be very helpful. : : Apart from the obvious security bug, you mean? The one where it doesn't : actually restrict what remote code can be run at all? SOAP::Lite 0.55 was released some days ago, it addresses that issue according to http://www.soaplite.com/ -- fxn
[OT] Doubt on directories for development
I am working in my first mod_perl real-life project, I would like to ask you for a directory layout for development. The fact is that developers in my team have Apache under /usr/local in Linux machines, but we would prefer to develop as normal users, not as www or nobody, though that will be the user in production. What is the standard way to configure things for that? We have created somehow the Apache directory layout under the root of the project tree and call httpd -f project_root/conf/httpd.conf, where we customize the user and group (in my case fxn), full paths to log and pid files writable by that user, etc. but ServerRoot is /usr/local/apache and the original modules under /usr/local/apache are there, so we cannot use $r->server_root_relative to access, say, to application config files which seems to be standard (and quite natural) idiom. The httpd.conf in CVS is a template customized once per-machine with a script. I would appreciate any hint very much, we could begin right with a good layout next Monday. Thank you very much! -- fxn
doubt on how long the cookbook will apply
I have the Eagle book but have not buyed the Cookbook yet. I wonder whether the way Perl modules are written nowadays is going to be significantly altered by Apache 2.0. If it won't, I'll definitely buy it this weekend. -- fxn
how to identify an interrupted downloads?
I would like to know whether in the server side one can figure out if a user has completed the download of a known file. Would bytes_sent() give the actual number of bytes sent if the download gets interrumpted by the client? Would yo know a better approach if not? -- fxn
Re: how to pass data in internal redirects?
On Tue, 26 Feb 2002 08:32:37 -0500 "Henigan, Timothy" <[EMAIL PROTECTED]> wrote: : I don't know if this is the best design, but it works for this application. : If you made it this far into the email, you might be interested in some : sample code...let me know. If you have comments, please speak up. I'm the : only developer on the project, so if I've gone off the deep end, I might not : notice. Yeah, I am surely biased because in my company everything is done with Java where servlets act as controllers and forward requests to JSPs. Here people basicaly put data in the session object, for instance a User associated with the session. You have static data shared by everybody... it's a bit different as you probably know [*]. But I want to learn the multi-processes way of program with Apache and his related technologies. I believe, for instance, the Java people here at work do not completly realize they use the session object both to store state _and_ as a cache mechanism sometimes. You are not aware of what you are taking for granted until you play with other techniques. So, a controller could in principle perform a call to a template engine as yours does, conceptually there is no need to do that internal redirect. In fact, there is no need to have two different files if I take the pattern a bit further. For instance, I believe a page written in Embperl or PHP could begin with the controller code and once finished the view code could follow, that would be MVC too in my opinion. Well, just sharing thoughts. -- fxn [*] If needed, load balancing is done taking sessions into account.
how to pass data in internal redirects?
As an exercise studying mod_perl I am trying to see how could the MVC pattern be implemented. I've thought a possible approach would be to write the model using normal Perl classes, and controllers and views with Apache modules. I suppose that controllers would use internal redirects to call the views, is there a way to pass Perl data this way? For example, in the hangman game in O'Reilly's book a controller would load a session from the cookie, process user's guest, modify the state and redirect the request internally to the view. Ideally the view shouldn't read the data to display from the database again... could it be passed somehow by the first content handler? -- fxn
Re: cleanest way to have globals in a CGI
On Mon, 18 Feb 2002 15:04:16 +0100 Me myself <[EMAIL PROTECTED]> wrote: : Since there would be just one Perl interpreter I guess plain "use vars" : would add symbols to a in principle shared by more code main namespace, : do you know whether there is a standard, clean solution for this? I somehow was thinking packages are mainly used for writing modules or classes and that wouldn't be idiomatic to start a CGI with a package declaration. Silly me, packages introduce namespaces and that is precisely what was needed. Nevertheless, it turns out that Apache::Registry takes care of that problem wrapping CGIs in corresponding different packages he declares, so a valid answer to my question appears to be that a standard, clean solution is to do nothing special to protect globals. -- fxn
cleanest way to have globals in a CGI
Hello, I am the author of a CGI written in Perl (a single file) which is publicly available. Currently there are some file-scoped lexicals used in routines and I would like to change that in the next release in case anyone wanted to run it under Apache::Registry. Since there would be just one Perl interpreter I guess plain "use vars" would add symbols to a in principle shared by more code main namespace, do you know whether there is a standard, clean solution for this? -- fxn