Re: How to get two perl namespaces in apache
Ernest Lergon wrote: > just throwing a glance I found: > > http://thingy.kcilink.com/modperlguide/modules/Apache_PerlVINC_Allows_Module.html Not a good idea for production use. It will slow things down. Handy for development with multiple projects using separate virtual hosts though. - Perrin
Re: AddModule mod_perl.c
Stas Bekman wrote: > Arh, I mean to use the hints how to get the core dump backtrace. Hang on, this guy is just trying to do an install. He shouldn't need to troubleshoot at that low a level. John, who built this server and why is it DSO? If you have control of this system, I would recommend that you simply start over and build Apache/mod_perl statically, following the instructions that come in the mod_perl package. It completely avoids all of the AddModule business that is getting you confused. I've always avoided DSO like the plague, but if you're really determined to use it your best bet is to let the mod_perl build script do the LoadModule/AddModule stuff for you, which it will do if you tell it to with the USE_DSO=1 flag. - Perrin
Re: AddModule mod_perl.c
Sorry you're having so much trouble with the install. It goes pretty smoothly for most people, but you are complicating things a bit by putting PHP and SSL in the mix on your first try. >Perrin, I have no idea if DSO is still involved Apache will not build DSO unless you tell it to. Your build routine looks fine to me. I do the same except I don't usually build in mod_ssl, and it works. >After I install the apache server I check the > httpd.conf. In it are 2 key lines: > > LoadModule perl_module libexec/libperl.so > AddModule mod_perl.c Get rid of your old conf file. You don't want any of that LoadModule/AddModule junk at all in a static server. That's DSO-only. (Anyone know if mod_ssl somehow forces you to use DSO?) > However, when I try to browse my hello.pl > file (from Apache Modules w/ Perl & C, pp 42-4) it > displays it as text rather than an html page. It's as > if the Options ExecCGI were not applied. That script should work under CGI as well. Does it? Did you remember to make it executable? I'm afraid I'm not that much help with install problems because I just haven't had any of my own to deal with. You can try using Apache Toolbox to do the build. It's supposed to make this stuff easier. If it seems hopeless, you could always check out SpeedyCGI, which gives a similar speedup for perl CGI scripts bu does not require apache to be recompiled. It doesn't give you access to the full range of mod_perl tools, but it may be all you need in this case. - Perrin
Re: Segmentation fault 11 (php/mod_perl)
Bob Pickles wrote: > I've been hacking at this a couple days. At first I really wanted to > get mod_perl working as a DSO. Got everything compiled, and added lines > to httpd.conf. Died on startup if I had AddModule mod_perl.c. > Following a tip on this list, I gave up on DSO and went static > compile. And then what happened? Did you start with a clean conf file? There should be no LoadModule/AddModule stuff in it for a static server. - Perrin
Re: startup vs. child initialization question
>> Also, I read about issues of database handlers becoming >>unstable across forks. So should I place this initialization >>information into a perl child init handler? See the connect_on_init() method in the Apache::DBI docs. >We use PerlSetVar's for this where I work. That's how I would do it too, for anything that might vary by virtual host. - Perrin
Re: Global Config Module
Christopher H. Laco wrote: > If I use the module in startup.pl, and have it load all of it's data at > startup, it that the instance all child processes will use? Yes, that's the best way to do it. > On a side note, I'm fairly comfortable with Perl/OOP at the > batch/command/cgi level, but the where's and whens of mod_perl still leave > me a bit unclear. It's mostly a question of understanding the lifecycle of the Apache server. You'll get it. - Perrin
Re: Global Config Module
> In my limited understanding then, in the startup.pl, one could do the > following: > > use strict; > use MyMod::Config(); > > MyMod::Config::load(); Yes. Then you can have a function for accessing the config variables, or put them in globals ($MyMod::Config::database_password), or various other things. > What about existing components the are normally created in scripts using > new.. > use strict; > use MyMod::Config(); > > my $config = MyMod::Config->new(); What about them? That's a lexical variable, and not a problem. > Since the use of globals is bad, should existing things be converted to > pure packages instead of oop classes. > > Is it prefered in the mod_perl world to create packages rather than classes? I think you're getting your terminology a little mixed up. In Perl, packages are classes. And I'm not sure what globals you're talking about. > What about statefull vs. stateless objects? Since users are not guaranteed to return to the same Apache process each time, you can't keep read/write data in memory between requests (at least not without some kind of expiration system). Read-only data, like your config info, is fine to keep in memory. If you want to keep some sort of global application state, use MLDBM::Sync or Cache::Cache. For user sessions, look at Apache::Session. - Perrin
Re: general timeout for mod_perl scripts?
> i would like to prevent any of my mod_perl scripts from running longer than > 5 seconds. is there an elegant way to make a general timeout that does not > require changing all my scripts? i run both Registry and Mason scripts in > my environment. You could try setting an alarm in a fixup handler. But if you're just trying to prevent runaway servers, I'd suggest Apache::Resource. - Perrin
Re: Proxy authentication against a mod_perl backend - how?
> My first thoughts were to use mod_proxy to forward requests for > /protected/login to the backend, where the authentication will be done. > Then, just redirect the request to another URL behind /protected. The > authentication information should be passed as part of the request, should > it not? Sure, but your proxy server won't be checking to see what it is. People could go to any of your proctected pages freely if they know the URL. Sounds like you're going to a lot of trouble to avoid using standard auth to me. There are a number of auth modules out there which don't need mod_perl, and you may find one that will play nicely with your backend programs. Modules that auth against MySQL or LDAP servers exist. If you're determined to do auth on the backend, I would just let the backend do the auth and serving of the static pages. It will dump them out fast and let the proxy servers do the slow work of dribbling the bytes out to clients. - Perrin
Re: Astronomical Information
> Maybe i have been searching for the wrong keywords or been looking in > the wrong places You have. Try this: http://search.cpan.org/search?mode=dist&query=astro - Perrin
Re: Apache::DBI or What ?
Eric Frazier wrote: > I also still don't see how a connection can be "reconnected" at such a high > level. It can't, unless your database specifically supports the command "reauthenticate". Oracle does, which is what he wrote this for, but I don't think it's a standard part of SQL syntax so it will probably not work with MySQL. Of course MySQL connects really quickly, so you can probably get perfectly good performance without using Apache::DBI at all. - Perrin
Re: PDF generation
Mike808 wrote: > Don't know if you can run a JServ+mod_perl or JPerl hybrid, though. You can, but it would be the biggest memory hog every created, since it would be running a JVM in addition to the Perl interpreters. - Perrin
Re: Problem with DBM concurrent access
Franck PORCHER wrote: > So my question narrows down to : > How to flush on disk the cache of a tied DBM (DB_File) structure > in a way that any concurrent process accessing it in *read only* mode > would automatically get the new values as soon as they > are published (synchronisation) You have to tie and untie on each request. There's some discussion of this in the Guide. As an alternative, you could look at using BerkeleyDB, or MLDBM::Sync (which does the tie/untie for you). - Perrin
Re: Problem with DBM concurrent access
> > Isn't that just as simple as > > > > tied(%dbm_array)->sync(); > > I believe that's not enough, because the reader may read data during the > write, resulting in corrupted data read. Not only that, there's also the issue with at least some dbm implementations that they cache part of the file in memory and will not pick up changed data unless you untie and re-tie. I remember a good discussion about this on the list a year or two back. - Perrin
Re: Thanks and GoodBye
John Kolvereid wrote: >Thanks for all your help, but I am NOT able to > install mod_perl. It's probably something that is not > installed on my particular server - I'll never know. I suspect you were just trying to do too much at once on your first try by throwing PHP and SSL in the mix. I suggest you look at SpeedyCGI (http://daemoninc.com/speedycgi/), which offers similar speedups for CGI scripts but does not require you to recompile Apache. It doesn't have the same feature set as mod_perl, but all you wanted to do was speed up your existing CGI scripts anyway. - Perrin
Re: mod_perl Cook Book
Rasoul Hajikhani wrote: > Has anyone purchased the mod_perl cook book from this list? If so, what > do you think of it? Is it a good buy? Yes. Go get it. - Perrin
Re: Pipelinning Output "APP" Framework
[EMAIL PROTECTED] wrote: > I know alot of you must do this. > > I want build a simple APP framework to chain the output of all my content > handlers, which would live in many different PM's for easy code management. > > for example: > APP::Header > APP::Footer > APP::Content > APP::Chemical_entry > APP::... > APP::Controller > - would push_handlers based on uri and/or app logic > - The result would be the entire html output in ( via print array ) > > WHY ( so that my content can: ) > > - pass named paired parameters to following handlers > - modify previous content ( eg update "html" header code with a msg from > main content handler ) This is not the best way to think about the problem, especially if you want it to be "FAST, FAST, FAST". Having one piece of code manipulate the HTML output from another piece is messy, slow, and will probably break every time your designers change the HTML. Instead, build a pipeline for working on the data to be displayed, which you can easilly pass through method arguments or $r->pnotes(), and then run a template (which may include many smaller templates) at the end to generate HTML. There are several templating tools you can use for this, and I've summarized the best ones at http://perl.apache.org/features/tmpl-cmp.html. - Perrin
Re: tt2 using mason tags
Mark Fowler wrote: > Sounds like you're getting confused between [% %] for template code > and [% PERL %] ... [% END %] for actual real perl code Agreed. Also, any significant Mason component is likely to use Mason's built-in object model, which is not part of TT. You will probably have to port some code before it will run. - Perrin
Re: Ordering in %INC for PerlRestart
Ged Haywood wrote: > Hi there, > > On Tue, 2 Apr 2002, [iso-8859-1] Sreeji K Das wrote: > > >>I use PerlFreshRestart on to reload my modules. > > [snip] > >>However, here my modules are getting loaded before the >>PerlRequire'd is loaded (since %INC is a hash). >> >>First, can some1 suggest a solution for this ? > > > I always stop (with SIGTERM) and start my servers rather than using > restart (SIGUSR1) as I find that there are fewer surprises. I think > that Perrin will agree. There are very few systems that can't cope > with a few seconds of downtime. It's certainly a lot safer, and it won't trash your shared memory the way PerlFreshRestart will. - Perrin
Re: mod_perl and open files limit
Ged Haywood wrote: > I'd suggest setting MaxRequestsPerChild to a low value (I generally > use something in the range of 50-100 but Perrin will tell you that's > *very* low... :) to avoid leak problems. A setting of 0 is fine, as long as you are using Apache::SizeLimit or Apache::GTopLimit. In fact, that's the best way to do it, since it gives your child processes the longest possible lifespan while preventing them from getting too big. As for the source of the original problem, it is probably a bug in the local code. You should check to make sure all of your filehandles are being closed. The other suspicious-sounding module is Apache::Lock::File. You can check it by replacing it with NullLocker and watching to see if the problem disappears. - Perrin
Re: tt2 using mason tags
Rafiq Ismail (ADMIN) wrote: > It's just the fact that in spite of my specifying that it should use > inline_perl, it didn't interpolate the inline code which uses custom > modules in mason tags. I've got it to try and interpolate now, however it > seems to warn that "$VARNAME's" are odd symbols. If you post an example of the troublesome templates on the TT list, someone will probably be able to help you. - Perrin
Re: Unsubscribe me please [KILL THIS THREAD]
Please kill this thread. Some people are not good at dealing with mailing lists. At least this guy was polite. - Perrin
Re: Ordering in %INC for PerlRestart
Sreeji K Das wrote: > Thanx for the reply (I hardly get replies for subjects > with restart :-( I guess I'm the only one using > PerlFreshRestart (sic !). Hopefully you are the only one! > My requirement is to do a neat kill of children and > then do a complete restart. I don't want any existing > connections to be terminated abruptly. I've done this in a load-balanced cluster by stopping all traffic to the machine I want to restart, allowing current requests to finish, and then restarting it. It would be nice to have a "graceful shutdown" option though. > Also I want a > complete restart (ie. any modified files should be > loaded - using Apache::Reload/StatINC does a lot of > stat()'s & further each children would get a separate > copy). I could be wrong, but I'm pretty sure PerlFreshRestart will not result in as much shared memory as an actual restart. How does your shared memory look after a clean restart vs. a PerlFreshRestart? > Restart was working perfectly until mod_perl-1.19. Maybe for you. For many people it resulted in unexplained segfaults and closure problems in CPAN modules. It's just not a very safe thing to do. > After that a lot has changed. Now I have fixed a lot > in mod_perl to get Restart fully working. You can send your patches to the dev list. However, most effort is focused on getting mod_perl 2 out right now. - Perrin
Re: Content management systems
Matthew Watson wrote: > I was wondering if there are any content management systems around for > modperl , i'm after a similar kind of thing > as postnuke for php. I'd much rather something 'out of the box' as I don't > have time to develop a system from scratch mysql. It looks Robin Berjon is going to give an overview of CMS for mod_perl at OSCON: http://conferences.oreillynet.com/cs/os2002/view/e_sess/2667 I know I'll be there. - Perrin
Re: alarms
mire wrote: > 1) what happens when you set an alarm for lets say 30 seconds and the request > finishes in 20 ? You are supposed to unset the alarm if the event you were timing finishes before it goes off. > 2) does apache child die when you issue die; from perl code (mod_perl > ofcourse) ? No, only when you call exit or child_terminate(). - Perrin
Re: [Fwd: Re: How to reload PERL module in all Apache children]
[EMAIL PROTECTED] wrote: > On Fri, 12 Apr 2002, Stas Bekman wrote: > > >>But if talk about futuristic Solar variables (perl globals shared >>between threads). what if a solar variable is a reference to CODE? Can >>this be shared? If so, will reloading this variable in one interpreter >>affect others? > > > even if that would work, it would kill performance due to required mutex > locking. and that locking would need to happen in the perl core, unlike > simple scalars, arrays and hashes. Does it look you'll be able to get the solar variables idea to work for those data types? - Perrin
Re: alarms
Damyan Ivanov wrote: > OK, but I am really curious. What really happens if I intentionally set > the alarm to ring after the request has finished? For example if I want > something to hapen if apache child is idle for more than 15 minutes. Try it. Most likely it will run the alarm, but will interrupt some other unrelated request from a different user to do it.
Re: Enforcing user logged in from only 1 browser?
Fran Fabrizio wrote: > Unfortunately, there's some terminology muddling...AuthCookie calls it a > session when it establishes that a user is a valid user and sets a > cookie on their browser. Apache::Session considers a session a series > of page hits from the same user. It assumes you've already done > whatever you need to do to assure that the user is valid. I think you may find that neither of these does everything you need without a bit of additional coding. The common way to do this sort of thing is to use Apache::Session to track sessions (as in a series of page hits from the same user), and if the user authenticates, you put his user ID into the session data. You would have to do the auth part yourself, as well as the actual cookie handling, or else hack AuthCookie to cooperate with Apache::Session. - Perrin
Re: "Kind-of" PerlSections, and location question
Daniel W. Burke wrote: > We have an application we're serving by using the same > set of source code, and setting up different > sections in the virtual host to set different variables > and path aliases based on who the customer is... ... > What I'd like to do (if even possible!), is have something > like this: > > Have a databae table that stores the information for each > setting, then load it dynamically as a request comes in... Off the top of my head, there are two simple ways to do this. The first is to generate your httpd.conf using a template and database. I've done this using Template Toolkit, and it worked great. This also works for servers that don't have mod_perl, like proxy servers. The other way would be to write a PerlTransHandler to look at all incoming requests and then decide how to handle them based on your database info. This is better if you need to be able to update it without restarting apache. - Perrin
Re: [OT] [ANNOUNCE] mod_log_sqlite
Tatsuhiko Miyagawa wrote: > Announcing new Apache module (written in C): > > mod_log_sqlite is an Apache logging module for sqlite database. It > allows you to log your HTTP stats into sqlite, then you can do queries > using sqlite's SQL feature (including subselects, views) to HTTP > statistics. The SQLite FAQ seems to suggest that SQLite isn't very good at parallel read/write situations: http://www.hwaci.com/sw/sqlite/faq.html#q6 Have you seen any problems so far? - Perrin
Re: [OT] [ANNOUNCE] mod_log_sqlite
Matt Sergeant wrote: > Is that any different to how it is with file logging? I would guess it's the same, but I don't know the details of how either system implements locking. I'm mostly interested because if SQLite works for this it might work for fast data sharing between processes as well (maybe as a Cache::Cache backend). - Perrin
Re: PerlRequire
Florence Dardenne wrote: > Does mod_perl 1.26 includes the 'PerlRequire' functionality or do I need > higher version ? All versions of mod_perl have that feature. You must not have mod_perl compiled into that server. See this entry in the guide: http://perl.apache.org/guide/install.html#How_can_I_tell_whether_mod_perl_ - Perrin
Re: PerlRequire -mod_perl-2 - Apache 2.0.35
[EMAIL PROTECTED] wrote: > I am a newbie and had developed a proof-of-concept application on Apache >1.3.23/Mod_Perl-1.26-dev. We are researching into moving away from ASP/IIS >Webapplications to Apache/Mod_Perl. I am stuck with the latest Apache 2.0.35 with the >following problems. Do you really need to use Apache 2 and mod_perl 2? Why not use the proven 1.x series? It's still pretty early to be using the new stuff. - Perrin
Re: Apache::DProf seg faulting
Sam Tregar wrote: > On Tue, 16 Apr 2002, Sam Tregar wrote: > > >>On 16 Apr 2002, Garth Winter Webb wrote: >> >> >>>Sam, try getting rid of the 'PerlModule Apache::DB' line. I've used >>>Apache::DProf w/o any problems by including only the one PerlModule >>>line. Since they both want to use perl debugging hooks, I'm guessing >>>that Apache::DProf is getting crashed up when it tries to use hooks >>>already grabbed by Apache::DB... >> >>Same result. Thanks though! > > > Aw nuts, that was the problem! I thought I'd tried that already, but I > guess not. I actually got those PerlModule lines from the "mod_perl > Developers Cookbook" - guess this is an errata! Strange, that works for me. I do it like this: use Apache::DProf; use Apache::DB; Apache::DB->init; Or at least I did last time. Maybe this has changed in more recent versions. At the time (June 2000), I discovered I needed to call Apache::DB->init or else the debugging symbols would not get put in for modules that I used in my startup.pl, and they would not get profiled. - Perrin
Re: Sharing Variable Across Apache Children
Benjamin Elbirt wrote: > Well, lets assume that I were to go with > the shared memory option anyway... what would the pitfalls be / concerns? As mentioned before, you'd probably be better off with MLDBM::Sync or Cache::Cache. You can try IPC::Shareable, but a lot of people seem to have trouble getting it to work. Note that this is not shared acorss all the machine in the cluster unless you used a shared filesystem like NFS. - Perrin
Re: Sharing Variable Across Apache Children
> Abstracting access to data is only half of the storythe more challenging > part is race conditions and lock management... All of the data sharing tools take the logistics of multi-process read/write situations into account, although they do it in different ways. Some use file locking, others use semaphores, and still others use tricks like atomic file renames. The ones I mentioned in this thead (MLDBM::Sync and Cache::Cache) are both written to provide safe multi-process access. - Perrin
Re: [OT] Encrypting Embedded URLs
Nigel Hamilton wrote: > I'm looking for a two-way cipher to obfuscate URL parameters > safely and succinctly (not too many extra characters). Try Crypt::CBC. - Perrin
Re: Apache::DProf seg faulting
Paul Lindner wrote: >>But while I have your attention, why are you using Apache::DB at all? The >>Apache::DProf docs just have: >> >> PerlModule Apache::DProf > > > Legacy knowledge :) > > I think it may have been required in the past, or perhaps I had some > problems with my INC paths long-long ago.. And well, it just kinda > stuck. I used to do it because if I didn't DProf would not know anything about modules I pull in from startup.pl (since the debugger was not initialized until after they were loaded). This may not be necessary anymore. - Perrin
Re: Throttling, once again
Hi Bill, > Wasn't there just a thread on throttling a few weeks ago? There have been many. Here's my answer to one of them: 004101c0f2cc$9d14a540$[EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/blexblolgang/004101c0f2cc$9d14a540$[EMAIL PROTECTED] > Anyway, I remember Randal's Stonehenge::Throttle discussed not too long > ago. What we did was take that module, replace the CPU monitoring stuff with simple hit counting, and make it just return an "Access Denied" when the limit is hit. We also did some slightly fancier stuff than just blocking by IP, since we were concerned about proxy servers getting blocked. You may not need to bother with that though. One nice thing about Randal's module is that it uses disk (not shared memory) and worked well across a cluster sharing the directory over NFS. > Also, does anyone have suggestions for testing once throttling is in place? > I don't want to start cutting off the good customers, but I do want to get > an idea how it acts under load. ab to the rescue, I suppose. That will work, as will http_load or httperf. - Perrin
Re: [OT] Doubt on directories for development
F. Xavier Noria wrote: > 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. It doesn't seem worth it to me to go to a lot of trouble to avoid starting apache as root in development, especially if that's how you'll do it in production. I've always just put my modules in /usr/local/apache/lib/perl where they get picked up automatically (with no use lib or @INC changes). I make that directory writeable by my standard login (a security hole, but it's just my personal machine and not visible on the Internet), and keep a root shell open for restarting the server. That works fine unless you have mutiple users developing on the same box. - Perrin
Re: Q & A: $r->custom_response
Issac Goldstand wrote: > Reposting a question (and the answer) that geoff and I discussed in the > IRC room, as I think it's worthwhile to mention... > > I had the following line of code (actually many of the sort): > $r->custom_response(FORBIDDEN=>"File size exceeds quota."); > > And kept getting errors like: > [Tue Apr 23 19:46:14 2002] null: Argument "FORBIDDEN" isn't numeric in > subroutine entry at /usr/local/httpd/lib/perl/Mine/Pic/Application.pm > line 1343. > > The answer to the problem is that by using '=>' instead of ',', I was > making 'FORBIDDEN' become '"FORBIDDEN"' (string instead of numeric 403). > > Moral of the story: don't use => with Apache::Constants! In fact, don't use constants at all. At least not the kind created by the "use constants" pragma and similar tricks. They have all kinds of problems like this. Use package variables instead ($FORBIDDEN). Maybe some day Perl will have real constants, but I'm perfectly happy with package variables in the meantime. - Perrin
Re: Q & A: $r->custom_response
Per Einar Ellefsen wrote:
> Well, this one is exported by Apache::Constants, so if you don't want to do
> $FORBIDDEN = FORBIDDEN;
> somewhere at the top of your code, you're bound to continue using
> constants, right?
That's still safer. I used the constants pragma on a big project and I
saw people get bitten by $hash{CONSTANT} and "string interp CONSTANT" as
well as the aforementioned CONSTANT => value problem. It's just asking
for trouble, in my opinion.
Can anyone tell us if the Apache::Constants all just standard HTTP
response codes, or are some of them actually Apache-specific?
- Perrin
Re: Q & A: $r->custom_response
Per Einar Ellefsen wrote: > I suppose Apache::Constants could have been extended to return globals > if requested... But is there really any gain in that? Only in that people will not get tripped up by the possible bugs that using subroutines as constants causes. I guess Apache::Constants is difficult to replace, so everyone will just have to keep an eye out for this sort of problem. - Perrin
Re: [Q maybe OT] forward
Martin Haase-Thomas wrote: > forwarding is a term that i borrowed from the JSP concept - which i'm > currently trying to implement in perl. JSP forward is directly equivalent to an internal redirect. It's just an include that doesn't return. In short, it's a GOTO statement. Thank you Sun. - Perrin
Re: Apache2/mod_perl2 an order of magnitude more powerful?
Nigel Hamilton wrote: > I would love to run 250 Apache children on my linux server but I > just don't have enough memory (50 children max). thread still needs its own perl interpreter.Then you probably won't have enough memory with Apache 2 either. There is some additional memory savings from sharing the opcode tree, but each Expect it to be better, but you don't get something (unlimited parallelism) for nothing (limited RAM). - Perrin
Re: full-featured online database apps
Peter Bi wrote: > Well, I changed it back to "HTML::Template". No template flame wars, please. HTML::Template is not unique (it has much in common with Template Toolkit and dozens of other less famous modules from CPAN), and Embperl::Object is really pretty cool. Your original point about separating presentation out into templates helping with code reusability is a good one, so let's just leave it at that. - Perrin
Re: Apache::OK error
Lihn, Steve wrote: > [Thu Apr 25 15:32:15 2002] [error] Bareword "Apache::OK" not allowed while > "strict subs" in use at C:\Apache2/blib/lib/Apache2/Apache/Echo.pm line 25. > Compilation failed in require at (eval 2) line 3. > > What do I miss? Try Apache::OK() instead. Damn these faux constants!
Re: Apache::OK error
Oops, that's right, it's in the Apache::Constants package. Changing
your code to say Apache::Constants::OK should do it. No need to import
all of that stuff unless you want to.
Jon Robison wrote:
> maybe a "use Apache::Constants qw/ :common /;"
>
> --Jon Robison
>
> "Lihn, Steve" wrote:
>
>>Hi,
>>I am testing the Apache::Echo connection handler for Apache2 and mod_perl 2.
>>But encounter the following error:
>>
>>[Thu Apr 25 15:32:15 2002] [error] failed to resolve handler `Apache::Echo'
>>[Thu Apr 25 15:32:15 2002] [error] Bareword "Apache::OK" not allowed while
>>"strict subs" in use at C:\Apache2/blib/lib/Apache2/Apache/Echo.pm line 25.
>>Compilation failed in require at (eval 2) line 3.
>>
>>What do I miss?
>>
>>--Steve
>>
>>--
>>package Apache::Echo;
>>
>> use strict;
>> use Apache::Connection ();
>> use APR::Socket ();
>>
>> use constant BUFF_LEN => 1024;
>>
>> sub handler {
>> my Apache::Connection $c = shift;
>> my APR::Socket $socket = $c->client_socket;
>>
>> my $buff;
>>
>> for (;;) {
>> my($rlen, $wlen);
>> my $rlen = BUFF_LEN;
>> $socket->recv($buff, $rlen);
>> last if $rlen <= 0;
>> $wlen = $rlen;
>> $socket->send($buff, $wlen);
>> last if $wlen != $rlen;
>> }
>>
>> return Apache::OK;
>> }
>>
>> 1;
>> __END__
>>
>> Steve Lihn
>> FIS Database Support, Merck & Co., Inc.
>> Tel: (908) 423 - 4441
>>
>>--
>>Notice: This e-mail message, together with any attachments, contains information of
>Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential,
>proprietary copyrighted and/or legally privileged, and is intended solely for the use
>of the individual or entity named in this message. If you are not the intended
>recipient, and have received this message in error, please immediately return this by
>e-mail and then delete it.
>>
>>==
>
>
Re: Basic usage of Apache::Session::Oracle
> 1. Is the reference to the user storable? Yes, but it will store the complete user object in the database, not just a reference. > 2. Do I need to create more columns in the table or everything goes >to the "a_session" column? The latter. > 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? Yes. You will have to hack the Apache::Session code to do it, but it's not very hard. Just make it store a timestamp in a different table. Or put a trigger in the database to update a timestamp column when the a_session column gets updated. However, this implies that every time a user accesses a page you will be updating his session. That's not true for most sites. If you really need an accurate time for when the user last accessed a page, you will have to make sure to update his session every time. See the information on forcing an update in the Apache::Session docs. - Perrin
Re: Memory explodes loading CSV into hash
> $foo->{$i} = [ @record ];
You're creating 14000 arrays, and references to them (refs take up space
too!). That's where the memory is going.
See if you can use a more efficient data structure. For example, it
takes less space to make 4 arrays with 14000 entries in each than to
make 14000 arrays with 4 entries each. There is some discussion of this
in the Advanced Perl Programming book, and probably some CPAN modules
that can help.
- Perrin
Re: Memory explodes loading CSV into hash
Ernest Lergon wrote: > So I turned it around: > > $col holds now 18 arrays with 14000 entries each and prints the correct > results: ... > and gives: > > SIZE RSS SHARE > 12364 12M 1044 > > Wow, 2 MB saved ;-)) That's pretty good, but obviously not what you were after. I tried using the pre-size array syntax ($#array = 14000), but it didn't help any. Incidentally, that map statement in your script isn't doing anything that I can see. > I think, a reference is a pointer of 8 Bytes, so: > > 14.000 * 8 = approx. 112 KBytes - right? Probably more. Perl data types are complex. They hold a lot of meta data (is the ref blessed, for example). > This doesn't explain the difference of 7 MB calculated and 14 MB > measured. The explanation of this is that perl uses a lot of memory. For one thing, it allocates RAM in buckets. When you hit the limit of the allocated memory, it grabs more, and I believe it grabs an amount in proportion to what you've already used. That means that as your structures get bigger, it grabs bigger chunks. The whole 12MB may not be in use, although perl has reserved it for possible use. (Grabbing memory byte by byte would be less wasteful, but much too slow.) The stuff in perldebguts is the best reference on this, and you've already looked at that. I think your original calculation failed to account for the fact that the minimum numbers given there for scalars are minimums (i.e. scalars with something in them won't be that small) and that you are accessing many of these in more than one way (i.e. as string, float, and integer), which increases their size. You can try playing with compile options (your choice of malloc affects this a little), but at this point it's probably not worth it. There's nothing wrong with 12MB of shared memory, as long as it stays shared. If that doesn't work for you, your only choice will be to trade some speed for reduced memory useage, by using a disk-based structure. At any rate, mod_perl doesn't seem to be at fault here. It's just a general perl issue. - Perrin
Re: schedule server possible?
Lihn, Steve wrote: > How do you use cron to do scheduling, yet "calls" Apache/mod_perl to > do the processing? Your cron script just uses LWP to call a module running in mod_perl. > Consider cron does not exist in Win32, maybe an all-Apache solution > will be simpler and more elegant!? Cron does exist on Win32. It's called "Scheduled Tasks". I use it all the time to kick off perl scripts. - Perrin
Re: PerlRun problem: can't find method "uri"?
Ricky wrote: > When running under apache::perlrun, the script sometimes crash. I agree with Stas that if you fix the problems with your script running under "strict" this will most likely go away. > In mod_perl manual said that the script usually run in apache::perlrun > widthout change but not in my script. One thing that often causes problems is old Perl4-style library files. If you have functions that you load from some .pl files which have no package name and are pulled into the main namespace, you should change them into real Perl5-style modules. There are lots of reasons you should fix this; mod_perl is just one of them. > And I can't add "use strict" because it will crash the script immediatelly. > In error_log show : > "Variable "%in" is not imported at /home/httpd/html/scdf/scdf.plx line 174." > "Global symbol "$sth" requires explicit package name at > /home/httpd/html/scdf/scdf.plx line 171." If you've read the documentation and you still need help understanding how to program with the "strict" pragma, I suggest looking on http://perlmonks.org/. > Is it a good decision try to move to mod_perl because the implementation time > is slow. > Is there any other tech that easier/more faster than mod_perl? > How about PHP or JSP? It will be much faster to fix your CGI scripts so they run under mod_perl than to re-write them in PHP or JSP. - Perrin
Re: Cheap and unique
David Jacobs wrote: > I'm converting a few CGI scripts that used the PID as a cyclical unique > number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). > > Our goal is to find a replacement function that is extremely cheap > (cheaper than say, random(100)) and will never repeat. Any ideas? Yes, mod_unique_id will do that, as will Sys::UniqueID and Data::UUID on CPAN. Of course that random function is probably very lightweight, but it's not actually unique. - Perrin
Re: Cheap and unique
OCNS Consulting wrote: > Check your "Programming in PERL" book. Specifically, the "srand" function. 'random' ne 'unique' A random function could return the same number 10 times in a row. It's very unlikely, but it could happen. That's the definition of random. - Perrin
Re: SOAP and web services
Richard Clarke wrote: > I use mod_perl/apache/soap::lite to create an internal "application server" > so that I can distribute processing load from the public webserver. That would be a lot more efficient if you just used vanilla HTTP. Less wasted overhead. This is the same principal at work when you use mod_proxy in your web server and a backend system with mod_perl on it. - Perrin
Re: Using a 404 ErrorDocument to serve content
Ken Williams wrote: > The idea is that I'd put a bunch of JPEGs on the > server at locations like foo/123.jpg , and then if a request came for > foo/123-medium.jpg , I'd catch that with a 404 ErrorDocument and > generate the resized image using Imager. If I wanted to, I could also > create the resized image on disk, so it wouldn't need to be generated > next time. Incidentally, that's how Vignette StoryServer works. You could also do this kind of thing with a transhandler (or mod_rewrite) that checks for the existence of a static file and rewrites the URL if it can't find one. That might be more "correct", but trapping 404 is the best possible performance, since there is no additional code in the response chain if the static file is there. - Perrin
Re: Cheap and unique
Ken Williams wrote: > If you have the additional requirement that the unique values shouldn't > be easily *guessable*, that becomes a very hard problem, precisely > because "random" and "unique" are such poor friends. Usually people > just cheat by generating a large random ID such that the probability of > it being already-used is low, and then they check all the previous IDs > to make sure. The requirement to prevent guessing is usually aimed at security and preventing "session hijacking" and similar attacks (and believe me, this kind of attack is very common). Another way to do this is to use a MAC like MD5 or SHA1, as described in the Eagle book and O'Reilly's CGI book. This makes it very difficult for an attacker to generate a valid ID, even if the sequence of IDs is predictable. - Perrin
Re: Cheap and unique
[EMAIL PROTECTED] wrote: > I've been following this conversation and I'd like to clarify whether my > idea (since I and others want to do this as well) would be use an > incrementing counter for uniqueness. Then also store a bit of secret > randomness, concatenate both values together and create a digest hash. > That hash would be sent along with the sequence as well. This would allow > uniqueness and prevent guessing since the digest would have to match as > well. Depending on my paranoia I could either get fresh random bits each > time (and have a good hardware source for this then) or keep it around for > a bit and throw it away after a period. > > Does that sound right? Yes, except for the random part. There is no randomness involved here. You should use a secret key stored on your server. There's an example of this technique here: http://www.oreilly.com/catalog/cgi2/chapter/ch08.html - Perrin
Re: convention on logging?
F.Xavier Noria wrote: > 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? You can use Apache->server->log(). If you want your modules to work outside of mod_perl, you can write a wrapper class that uses the server log when it sees you are in mod_perl and uses something else when you're not. There are several fancy logging modules on CPAN. - Perrin
Re: Apache::Session
Stathy G. Touloumis wrote: >>You need to do some more debugging. Problems with Apache::Session are >>usually due to scoping, so put in some debug statements to see that the >>session objects for the IDs having trouble are getting properly cleaned >>up (i.e. DESTROY is getting called). It is possible to have problems >>with DB_File if it doesn't get untied after each request. > > > Wouldn't the issue above (untie) be alleviated by restarting apache? Probably. There are some strange situations you can get into with DB_File if you don't untie (due to caching and lost updates), but you're right that the file locks would probably make the system hang if the session wasn't getting cleaned up. I don't know what else could be causing your problem, but I would still suggest trying Apache::Session::File as a potential fix. - Perrin
Re: Load Balancing, mod_proxy, rewrite problem
mire wrote:
> I have code like this:
>
> RewriteEngine On
>
> RewriteLog "/var/site/rewrite.log"
> RewriteMaplb prg:/tmp/lb
>
> RewriteRule ^/trta$ http://${lb:prvi|drugi} [proxy,last]
>
> and a perl script (a copy from mod_proxy manual) but it doesn't work, it seems
> like perl script is waiting indeffinetly for input.
Sorry, this is not a mod_perl problem. You should try the general
Apache user mailing lists, or see if there's a list or newsgroup for
mod_rewrite.
- Perrin
Re: mod_perl and mod_cgi
Konstantin Yotov wrote:
> On my
> development machine everything was ok, but when I move
> to productional server the mod_perl version works
> twice slower than mod_cgi.
Start by making sure you really have mod_perl installed and your scripts
are running under it, and not mod_cgi. You can verify this using the
instructions in the guide. One quick way is to check the value of
$ENV{'MOD_PERL'}.
Also, which platform are you on and what are your settings for
MaxClients and MaxRequestsPerChild form httpd.conf?
- Perrin
Re: '&' in regex
Rizwan Majeed wrote: > I was trying this out : $SomeVar =~ /&/ ;$SomeVar =~ /'&'/ ;$SomeVar > =~ /\&/ ;none of these works. > > Need help This list is for mod_perl questions. For beginner Perl questions, you should try one of the mailing lists at http://lists.perl.org/ or post your question on http://perlmonks.org/. - Perrin
Re: mod_perl and mod_cgi
Konstantin Yotov wrote: > MaxClients 150 > MaxRequestsPerChild 0 You're probably running out of memory and going into swap, which will give terrible performance. MaxClients 150 is really high, and you should only set MaxRequestsPerChild to 0 if you're using Apache::SizeLimit or Apache::GTopLimit. There's a lot of information about these settings in the guide at http://perl.apache.org/guide/. - Perrin
Re: Apache::DBI
Gregory Matthews wrote: > Does this mean if each user has to use a unique username/password to > OPEN the database? Yes, eaxctly. > My prog will use the same database:username:password > for all connection requests opened with a > "db_connect($database,$user,$password)" call, however, each user will > have his/her own unique file/table within this database which requires a > unique username/password to access. So that security is handled by your program, not by the database? No problem for Apache::DBI logins then. - Perrin
Re: Apache::DBI
Gregory Matthews wrote: > Yes, my prog checks for valid username/password requests and issues the > proper response. So it sounds like Apache::DBI is a good solution then > since all users will be working under the same handle? Yes, that's correct.
Re: Memory Leaks
> I have a couple of questions regarding leaking memory in mod_perl: > > 1. What are the main culprits, in order of severity, of memory leaks, i.e.: > > a. global variables (NOT lexically scoped via my) > b. ... > c. ... > > 2. When writing code from scratch (a new application), what is the best > way to avoid creating leaks to begin with, i.e., use strict;, PerlWarn On, > etc.. ? There are actually not very many ways you can leak memory in Perl (and thus mod_perl). Most people confuse memory growth with memory leakage. If you want to know how to avoid memory growth, look at the performance tuning stuff in the Guide, like passing references, avoiding slurping of large files, controlling the buffering of DBI result sets, etc. 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), and one or two obscure syntax problems. I think one of them involved code like "my $x = 7 if $y;". Matt Sergeant got bitten by this in the early stages of AxKit development, and the details are in the mailing list archive. Global variables by themselves are not a source of leaks or growth. If you slurp a large file into a global, your process will grow, but the same is true for a lexical. - Perrin
Re: Memory Leaks
> So am I being overly paranoid concerning the "leak" potential of mod_perl > programming? No, memory management is very important with mod_perl. > If I start with "strict" code to begin with and try my best to stay away > from the problems you mentioned, then any potential memory leak/drain > issues will be avoided? Using strict is an absolute must for many reasons. It won't prevent you from using up tons of memory though. You have to become tuned in to the things that use up memory so that you can avoid them. Start with the Guide. - Perrin
Re: sending CGI ouput through a handler
> My::Handler takes the requested file and adds some markup to it with the > Template Toolkit if the MIMEtype of the file is text/html. I want to be > able to use the same handler to also add markup to the output of executed > CGI. What is the best way to do this? You can't feed the output of mod_cgi to mod_perl, at least not in Apache 1.x. The best thing to do (at least for performance) would be to rewrite the CGI so that you call it as a module from your handler. Another approach would be to use Apache::Filter to grab the output from PerlRun or Regsistry. You could also sublass PerlRun or Registry and add your handler code to it. - Perrin
Re: Memory Leaks
Gregory Matthews wrote: > I too thought of setting a cron job to restart the server once per day > in order to keep the memory "fresh". > > In a production environment, are there any downsides to doing this, > i.e., server inaccessibility, etc..? There have been some discussion on the list about this in the past. The ideal situation is to have a cluster that you can do a rolling restart on without making the service totally unavailable. - Perrin
Re: Memory Leaks
Per Einar Ellefsen wrote: > And if something goes wrong? You'd be having a server offline with noone > knowing about it. You can easilly set up mon (http://www.kernel.org/software/mon/) to page you if the server doesn't come back up within a certain amount of time. - Perrin
Re: Memory Leaks
Jason wrote: > If you don't want to restart the server then don't do this instead, it should >help prevent small leaks from being a problem. > http://httpd.apache.org/docs-2.0/mod/mpm_common.html#maxrequestsperchild Apache::SizeLimit or Apache::GTopLimit is a better way to do it, since it results in fewer unnecessary restarts. However, it's still a good idea to restart periodically, because some of the shared memory seems to become unshared over time no matter what you do, and restarting fixes that. - Perrin
Re: Monitoring the processes
Gregory Matthews wrote: > For example, is there a command line tool to use that will allow me to > see the process growth upon request reload? I know that I should run > the server with httpd -X, but I don't know how to actually see the > memory being used/increased/decreased when the prog is being executed. > As I understand it, this is a good indication that there might be a > problem. You can steal some code from Apache::SizeLimit or Apache::GTopLimit to print the current size in the error log. Otherwise, just use top. Keep in mind that sometimes a leaky piece of code will have to be run several times before you see the leak, because of the way that Perl allocates memory in chunks. - Perrin
Re: Apache::GTopLimit
> Does using the Apache::GTopLimit module have the same net effect as > restarting the server itself by simply killing off the actual processes > which are growing beyond the set threshold, and thereby causing new > processes to be born? It does kill off processes that are getting too big, and you definitely should use either GtopLimit or SizeLimit to get the most out of your server. However, it's not quite the same thing as a restart. Over time, some of the shared memory from the parent process appears to become unshared, and new processes that are spawned start out with less shared memory because of this. Restarting now and then takes care of this problem. - Perrin
Re: Apache::GTopLimit
> So to modify my previous question, other than the loss of some shared > memory over time, GTopLimit will have the same effect as restarting the > server? Yes. That shared memory is important though. > On a side note, how are you tracking/discovering the this minimal loss over > time? Apache::SizeLimit prints statistics to the error log when it kills a process. Also, you can just look at top. - Perrin
Re: Apache::GTopLimit
Stas Bekman wrote: > Hmm, when a new process starts it shares *everything* with the parent. > Why do you say that it's not? It doesn't share everything with the parent. As soon as it forks there is unshared memory, and after the first request it handles there is usually more. Over time, the average amount of shared memory among child processes seems to gradually decrease. Restarting fixes this. - Perrin
Re: Apache::GTopLimit
Stas Bekman wrote: > What you are saying is that when the server is started afresh, the newly > started child processes share more memory with the parent, than newly > started child processes some time later. Am I correct? Yes, exactly.
Re: Apache::GTopLimit
Stas Bekman wrote: > Perrin Harkins wrote: > >> Stas Bekman wrote: >> >>> What you are saying is that when the server is started afresh, the >>> newly started child processes share more memory with the parent, than >>> newly started child processes some time later. Am I correct? >> >> >> Yes, exactly. > > > Any ideas why? Not really. I thought maybe it was because of something changing in the parent process, but that doesn't seem possible. There was a long thread a little while back about turning swap off and on again to solve this. I've never tried that. I think restarting every 24 hours is a good idea anyway, because I've seen strange things happen now and then when a server is up for a long time. - Perrin
Re: GTop
If you're not able to resolve your difficulties with GTop, try Apache::SizeLimit instead. It fully supports FreeBSD. You just need to install the BSD::Resource module, which is useful to have anyway. - Perrin
Re: Image::Size, TT, and mod_perl Question
> my %vars = {TOO_WIDE => 1};
That isn't doing what you think it's doing. Try this:
my $vars = { 'TOO_WIDE' => 1 };
Re: Apache::DBI connection cache
Ask Bjoern Hansen wrote:
> Apache::DBI is turning the argument hashref into the "cache key"
> with the following code,
>
> my ($key, $val);
> while (($key,$val) = each %{$args[3]}) {
>$Idx .= "$;$key=$val";
> }
>
> can anyone think of a good reason not to change that to something
> like
>
> map { $Idx .= "$;$_=$args[3]->{$_}" } sort keys %{$args[3]};
Good find. That's a bug. Fix it.
- Perrin
Re: MVC advice..?
Rafiq Ismail (ADMIN) wrote: > Now my problem is that I have to assign which > Subclass I want to instantiate, based on the script and params. So, you're asking how to map URLs to perl modules? Is there some reason you aren't simply using httpd.conf or Apache::Dispatch? In my last MVC design, we had all of our controllers inherit from one base controller that held all of the common code. Then we could just map from URLs to the specific controllers that handled them: SetHandler perl-script PerlHandler My::Controller > I my last > effort I went for a Shared datastructure holding (script, control module > pairs) which then allowed one to be dynamically "eval 'use..'"'ed in the > main content handler. I found that clunky. There's no good reason to do an eval 'use'. Use require instead, and import if you need to (but most people don't). > I'm building from scratch > again and am thinking of just firing up a template and allowing the > control to be loaded INTO the view as a template toolkit plugin. What I > hate about this is that I'm surrendering my View layer. I agree, that's a bad idea and certainly not MVC. - Perrin
Re: separating C from V in MVC
Ray Zimmerman wrote: > If I understand correctly, the Mason component that generates the page > the user sees would be considered the View. But where is the Controller? I wrote a little about this in my templating guide, and there has been discussion on the Mason list. A common approach is to use Mason's autohandlers as controllers, but you could really use any component. Just have it do some work in perl, gather some data, and then pass it off to a view component that generates the HTML. > This is code I > would normally have put in the <%init> section of the display component > (with a possible redirect to another component based on application > logic). This sounds like C and V are not separated as they should be. That's a standard way to do it in Mason, but not an MVC way. To make it more MVC, you need to have separate components for C and V, with V just receiving data and displaying it in HTML. - Perrin
Re: MVC advice..?
Dave Rolsky wrote: > On Wed, 29 May 2002, Perrin Harkins wrote: > > >>There's no good reason to do an eval 'use'. Use require instead, and >>import if you need to (but most people don't). > > > Actually, there is. This code: > > my $module = 'Foo::Bar'; > require $module; > > is not the same as this: > > require Foo::Bar; > > If require is given a string, it looks for a filename _matching_ that > string. If it's given a bareword, it converts '::' to filesystem path > separators first. Then do an eval 'require Foo::Bar', but eval 'use Foo::Bar' doesn't make sense. - Perrin
Re: MVC advice..?
Rafiq Ismail (ADMIN) wrote: > I'm not so keen on loading all the inheriting classes into memory > beforehand You really should do that, because it will save overall memory by increasing the amount of memory that's shared. All modules should be loaded during startup in the parent process. > It's a > fairly large site and my main concern was to do with how I should store > the correspondence from uri to object. The httpd.conf format seems about as simple as you can get to me. It's pretty unusual for a site to have dozens of controllers, and it usually indicates a design problem. Apache::Dispatch is fine too. > How does StatINC behave with 'required' packages? Require and use are very similar and both add the loaded module to %INC. Read 'perldoc -f use' for the exact differences. - Perrin
Re: Persistent Net::Telnet Objects
French, Shawn wrote: > Although this is working right now, I don't know enough [ anything? :) ] > about Apache or mod_perl to be sure that this will work in the future. I can't see how it could be working now, unless it is actually creating a new Telnet object on every request. Your %sessionHash is not shared between processes and you have no control over which process will handle any request. You're probably opening new telnet connections from each apache process. > What > I am really concerned about is that the telnetObj will only be accessible > from scripts run by the same child process as that which created and saved > it. That won't work, since you can't control which process will handle requests from the client. > Is there a better way to do this? You could write a web server in Perl, which would run a separate persistent process for each client on a different port. Randal wrote a column about that: http://www.stonehenge.com/merlyn/WebTechniques/col23.html You could also use this technique to make a sort of telnet server, and hide that server behind Apache/mod_perl, i.e. clients talk to mod_perl which talks to the telnet server. Of course the simplest approach would be to just let each Apache process open telnet sessions as needed. - Perrin
Re: Persistent Net::Telnet Objects
French, Shawn wrote: > Recall that I am using: Apache/1.3.20 (Win32) mod_perl/1.25_01-dev > mod_ssl/2.8.4 OpenSSL/0.9.6a on Windows 2000 with PHP 4.21 > > Would this be why my scripts are working? Mystery solved! Yes, that's why. You are running mod_perl in single process mode because you're on Windows, so only one request is handled at a time. That means that every user will always return to the same Apache process, since there is only one of them! > Does this mean that as long as I > stay with windows I will be alright? For certan definitions of alright, yes. It won't be speedy if you start getting many concurrent requests. - Perrin
Re: Persistant references [was] Persistent Net::Telnet Objects
First, there is no way to effectively pass compiled code between
processes at this time. It isn't likely to happen with Perl 5 because
attempts at loading compiled bytecode from disk have usually had poor
performance and other issues.
Second, what you're proposing is probably not a good idea unless this is
for a small in-house project.
> What I mean is, if a request comes in for a certain form I would like to be
> able to do something like this:
>
> my $form = &load_form($r);
> $c{$session_id}->{handler} = $form->{handler}; # <-- this being a code
> ref...
> $r->send_http_header;
> print $form;
>
> Then when the user completes the form and resubmits:
>
> my $handler = $c{$session_id}->{handler};
> $r->send_http_header;
> print $handler->($r);
What if the same user has multiple browser windows open and starts on a
new form before finishing the existing form? Remember, sessions are
global to all browser windows.
The right thing to do here is pass the form data the old-hasioned way,
in URLs or form fields. Those are distinct for each browser window.
> I would like to be able to dynamically create anonymous
> subroutine handlers based on input and have them be active until the form is
> submitted, at which time they are used to process the form then discarded.
But why go to all that trouble, generating subroutines on the fly? It
just doesn't seem necessary for processing form input.
- Perrin
Re: separating C from V in MVC
Jeff AA wrote: > do you use any standards for the data being > returned to the Controller? eg do you use a struct [ie hash/array Perl > primitive] or do you return an object? eg a table object etc? HTML::Template requires you to pass a perl data structure. Template Toolkit can handle objects as well (i.e. automatically call their accessor methods to fetch properties). Passing perl structs is faster, while passing objects allows for some additional tricks, like lazy-loading data in Class::DBI objects. (Class::DBI is a module for modelling database data as objects.) For more background on templating tools, see my article here: http://perl.apache.org/features/tmpl-cmp.html > does the Model returned data contain lots of > style hints? Or do you leave this completely to the View layer? Ideally you should have no style information at all in the model. > How does > the view layer know for example to render an Error cell as RED in HTML > but blue in Excel due to Excel palette limitations? You have different views for different targets. Make an HTML view and an Excel view and have the controller know which one to use. >>Optimally, the View avoids *ALL* application logic. > > - so the Model has to say RED rather than ERROR? Just the opposite: the model provides the list of errors, and the view knows how to display them. > Sounds like Controller only interacts with one Model? The model might be made up of dozens of different classes, but it's still referred to as "the model" as in "the application's data model." > What controls the overall layout? The view. > e.g. what is the equivalent of the > 'Grid Bag' layout manager - is this done in the Controller? and then > passed to the View with all the data from a set of Models? Or do you > make the Controller minimalist and have a meta-Model that assembles > all the sub-Models into a layout. I don't know what a Grid Bag is, but the idea is pretty simple: - Controller looks at input and decides which model objects to call. - Controller calls some methods on model objects. - Controller picks a view and passes data from model objects to it. I wrote about this in my article on the eToys system: http://www.perl.com/pub/a/2001/10/17/etoys.html - Perrin
Re: 'Apache::Session' using REMOTE_USER as key
Brian Parker wrote:
> I'm trying to use Apache::Session::MySQL. Since I'm generating my own
> session key outside of Apache::Session (using $ENV{REMOTE_USER}), what
> method(s) do I have to override to prevent Apache::Session from trying
> to create a session key for me? Since I'm not using Apache::Session's
> key generation capability, is there another implementation that would be
> more appropriate for my application?
Just write a replacement for Apache::Session::Generate::MD5. You can
look at Apache::Session::Generate::ModUsertrack, which is probably very
close to what you want to do.
- Perrin
Re: separating C from V in MVC
Hi Jesse, > It's the "addition tricks" which bug me out. With those two words you > establish the mother of all slippery slopes to architecture oblivion. When > you have objects passing freely between your "Controller" and "View" (which > are quoted here, 'cuz I don't think they are separate in this case), how do > you decide where to put a particular bit of code? The answer is, it is > completely arbitrary. First of all, I don't do it that way. I pass simple Perl data structures to Template Toolkit, because I know what data I want to send and it's faster that way. However, I don't really understand your objection. The view doesn't get to do anything but call accessor methods on the object. They look just like simple structures: NAME: [% person.name %] The template coder doesn't know that "person" is an object and TT called a method to get that instead of just doing a hash lookup. The reason people usually do this is so they can do lazy-loading. With something like Class::DBI you can set it so that if no one ever uses person.name in a template it will never be loaded from the database. It's a performance optimization. People who like that approach have objected to my approach of passing data because it requires the controller to know exactly what data the template will need, or else pass data that may not be needed and possible waste effort. Personally, I don't mind having the controller know what data is needed, as long as it doesn't make any decisions about how the data is shown. > In the architecture you describe it is inevitable that given enough time and > different programmers your "Controller" and "View" will coalesce into a > undifferentiated mash of code and HTML, separated only by the fact that they > are in two different files. I don't see where you're getting this from. The objects return data, not HTML, and they have no side effects. They are read-only. The view (template) does all of the formatting. > IMHO, any system built on Template Toolkit (unless it is small and always > managed by the same programmer) will ultimately devolve in just the same way > as a Server Page system. Well, you're not right about that. We built a very large system at eToys using TT and it never had any of these problems you're describing. The separation was clear, and the templates did nothing but display data. > HTML::Template isn't just faster than just about > everything else out there -- it also is pretty much the only templating > system which has an actual clear vision when it comes to how it fits into > the larger architecture. I don't agree with that either. Template Toolkit and AxKit (or any other XSLT-based system) can both enforce a clear separation of responsibilities. Template Toolkit allows people to do it other ways if they want to, through the use of plugins or by passing objects that do more than just return data, but the documentation and most of the mailing list discussion centers around the same approach as HTML::Template. The speed differences aren't really significant at this point. All of these tools are blazing fast. They all have C code under the hood now (with the new HTML::Template compiler). The bottleneck on performance of web applications is still what it always was: data access. - Perrin
Re: [Mason] Re: separating C from V in MVC
Dave Rolsky wrote: > Alzabo could handle a _lot_ of this for you. Class::DBI could handle some > of it (though less). SPOPS is also a good choice for this. All of them are on CPAN, just waiting for you. - Perrin
Re: separating C from V in MVC
Jeff AA wrote:
> For example to render a date in Excel some jiggery pokey is required,
> and I would also expect a HTML V to print pretty dates rather than
> 20020531172534 (or something other than the raw stringification)
Yes. That's why you need to use a good templating system. There is a
plugin for date formatting in Template Toolkit and HTML::Template can do
it by using the HTML::Template::Expr module. Maybe some AxKit expert
could explain how to handle it there.
> We also deal with lots of numerics - some are quantities, and others
> are values or interest rates - they need zero, 2 or 4dps when being
> presented.
Same deal: TT has a formatting plugin, and HTML::Template::Expr gives
you access to sprintf or an arbitrary formatting function of your own.
> So for
> example if your savings balance has gone negative, the value should
> be rendered as an error balance rather than a normal balance. In
> HTML you might choose to display the cell with a RED background,
> but this does not work in Excel, where a RED background prints as
> black, so you can't just tell the view RED - you need to tell it
> the reason and let Excel choose one of its limited bg colours.
A simple approach for this would be to have a data model that includes a
boolean flag for whether or not this balance is overdrawn. For example:
my $balance = {
value => -7,
overdrawn => 1
};
Note that the model object is making the decision about whether the
balance is overdrawn and no logic about that is going into the template.
Then in your template you say something like this:
[% IF balance.overdrawn %]
bgcolor="red"
[% END %]
Or whatever makes sense for your target output.
> Ok - so results from a collection of models are assembled and
> passed to the view.
One model, made up of many data objects.
> - not sure if I like this. I thought the whole point of the View
> was to contain all the logic about things like HTML tags or Excel binary
> representation etc, and as little as possible about other things.
That's right.
> Exactly where in the MVC world, would I decide that column 3 which
> contains a description should expand to fill 70% of the available
> space and that column 5 which contains a possibly long name should
> use the remaining available space, whilst column 1 which contains
> a name should not be wrapped?
In the view. I'm not sure where your confusion lies here.
> I guess I have talked myself round to thinking that the Controller
> is actually the layout manager, in that it marshals results from
> a set of models, decides how this collection should interact, and
> then asks an appropriate View to render the result in a specific
> interface flavour.
That's exactly what I'm saying, except that I don't see what your
"layout manager" is for. You should just pass some data to a template
(or maybe to something fancier for certain types of output like Excel)
and then the template makes all the decisions about how to show that data.
> Have I talked myself out of HTML:Template route? Not sure, I guess
> it depends on whether HTML::Template can be smartened up to
> understand that I want Dates rendered in a pretty format, quantities
> should be commified, cash values must have commas and 2dps, interest
> rates should have 4dps and cells with an error attribute should have
> a red background.
No problem, as I explained above.
- Perrin
Re: separating C from V in MVC
Rob Nagler wrote:
> Layout managers accept a declaration ('this cell is northwest', 'this
> other one expands across the bottom', etc.). They interpret the decl
> at run-time. It's like HTML, but more declarative. Some attributes
> of our Grid manager are:
>
> cell_nowrap - don't wrap the text in the cell
> cell_align - gens valign and align from a single compass direction
> cell_expand - this cell eats up the rest of the columns in the row
> row_control - a conditional value to control whether row is displayed
> cell_width - contains the HTML width= value (may be dynamic)
Can't all of that be expressed in an HTML template? It seems like the
template should know enough about what kind of data it's displaying to
know how to arrange the tables. After all, it's not a template for a
generic table; it's a template for a table that displays specific data
with a structure that is pre-determined.
Usually when I see people doing this kind of thing it's because they
haven't expressed all the necessary information in their model. For
example, if you have a rule that says people's names don't get wrapped,
then you need to know which pieces of data are names. If that isn't
obvious from your data structure (i.e. person.name is always a name)
then you add some flag to your data structure like is_name, so that the
model can tell the view that this is a name. Then the view gets to
decide what special treatment to give that data.
Maybe there's a certain class of problems where the sort of layout hints
you're talking about are needed and I've just never had to deal with it.
- Perrin
Re: separating C from V in MVC
Rob Nagler wrote: > Let's say, though, that you want the same template to render > in a WAP, Opera, Konqueror, IE, NS, etc. The implementation of Grid > handles this for you. For example, our code automatically renders > style sheets for IE5+, but no other browsers. (This isn't in Grid, > but you get what I mean, I hope.) The same template? How does the layout manager help with that? Does it modify the template? It would make more sense to me if this were a sort of abstraction to factor out common layout ideas from multiple templates. > However, sometimes you have dense tables where you allow wrapping and > other sparse tables where you don't. We have a really wide table for > admins which allows them to see all EC info at a glance. It has to > wrap all cells or it wouldn't fit on some screens. When the customer > sees the payment reason, on their subscription page, it doesn't wrap. > Two views of the same data. That doesn't require a layout manager though. Simple templating is fine for that, i.e. two different templates (views). - Perrin
Re: separating C from V in MVC
> > It seems problematic to me to require the programmers to do work when a > > designer wants to change the number of decimals in a page, for example. > > HTML::Template::Expr may present a solution to this particular desire, > although it isn't one I've come across. How often are HTML designers > fiddling with numeric formats? Are they really HTML designers if they can > deal with, say, a printf-style format string? Yes, they are, and printf isn't so much harder than JavaScript, style sheets, and templating tags. One place where this comes up is date formatting and internationalization. Making the model objects understand locale and act appropriately is not always a good approach, and supplying a date format in the template - which is all about appearance anyway - seems appropriate. This can also be useful when the same date needs to be displayed in multiple ways, like an abbreviated format on one page and a fixed length format in an e-mail template. You could make the controller do this sort of formatting before passing data off to the view, but I think it's an awkward fit and increases the coupling between components unnecessarilly. Obviously there are lots of ways to solve these problems, but what I like about doing it in the template is that it puts these concerns in the hands of the people who control the rest of the look-and-feel issues in the application, and gets them out of the perl programmers' way. - Perrin
Re: separating C from V in MVC
> It is interesting to try and fit our approach into the MVC+template > pattern Just to clarify, it's not MVC+template; it's just MVC. The templates are one way of implementing views. You could mix and match this where appropriate, so that your Excel view is a perl module with a set of formatting guidelines stored in a sort of style sheet, while your HTML view is simply a template executed by a templating module. > I see the Controller as also responsible for deciding what to do with > the results of rendering the DOM in Excel or HTML formats - Views > don't decide how their results should be distributed. This is typically something you would put into the controller, since the view shouldn't have to worry about details like HTTP headers. - Perrin
Re: separating C from V in MVC
> A String widget/template allows you to control the rendering of all
> fonts dynamically. If the String widget/template sees the incoming
> request is from IE5+, it doesn't render the font if the font is the
> same as the default font. The Style widget/template renders the
> default font in a style if the browser is IE5+. This avoids the
> stylesheet bugs in all other browsers and gives 90% of your users who
> are running IE5+ a much lighter weight page.
>
> It's cumbersome to do wrap all text in string templates, because the
> calling mechanism is verbose. Most template languages I've looked at
> only support named parameters.
>
> Widgets can have named parameters, e.g.
>
> String({
> value => ['User.first_name'],
> string_font => 'my_first_name_font',
> });
>
> but it is much more convenient to use positional notation:
>
> String(['User.first_name'], 'my_first_name_font');
You can actually do that pretty comfortably with Template Toolkit. You
could use a filter for example, which might look like this:
[% FILTER font('my_first_name_font') %]
... some text, possibly with other template directives in it...
[% END %]
The filter is a module which would get to post-process the output of the
contained block.
I believe the taglibs in AxKit could be used in a similar way.
- Perrin
Re: separating C from V in MVC
Rob Nagler wrote:
> Perrin Harkins writes:
>
>>You can actually do that pretty comfortably with Template Toolkit. You
>>could use a filter for example, which might look like this:
>>
>>[% FILTER font('my_first_name_font') %]
>>... some text, possibly with other template directives in it...
>>[% END %]
>
>
> One of the reasons Perl is popular is its idioms. Having to say
> something in three lines is not as idiomatic as one line. It takes a
> lot of discipline to use it everywhere. In other words, I don't think
> the above is more comfortable than:
>
> String(['User.first_name'], 'my_first_name_font');
The advantage is that my example can contain other templating code:
[% FILTER font('basic_info_font') %]
Hello [% User.first_name %]!
[% IF User.accounts %]
You have these accounts:
[% FOREACH User.accounts %]
[% name %]: [% balance %]
[% END %]
[% END %]
[% END %]
Unless I'm missing something about your example, the FILTER concept
seems more powerful. It is perfectly possible to simply add a plugin to
TT to make it look like yor example though:
[% String(User.first_name, 'my_first_name_font') %]
> Note also the accessor for User.first_name in Template Toolkit is
> probably nontrivial.
Assuming it's just $User->first_name() and you passed in $User as part
of your data to the view, there's no additional work.
- Perrin
