Re: HTML::Template
Pierre Vaudrey wrote: > I'm trying to run the following HTML::Template simple example : [...] > Could anybody help me to fix it ? Pierre, you are asking an HTML::Template question at the wrong forum, seems that this is the place where you want to ask this instead: http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.5/Template.pm#FREQUENTLY_ASKED_QUESTIONS __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
HTML::Template
I'm trying to run the following HTML::Template simple example : use HTML::Template; # open the html template my $template = HTML::Template->new(filename => "treeTest.tmpl"); # fill in some parameters $template->param(Title => "Pierre",IMAGE_SRC => "vignette.gif"); # send the obligatory Content-Type print "Content-Type: text/html\n\n"; # print the template print $template->output; with this template : with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF Could anybody help me to fix it ? Pierre Vaudrey email [EMAIL PROTECTED]
Re: Apache/2.0.40 (Win32) mod_perl/1.99_05-dev Perl/v5.6.1
> The only problem left is "perl-status". It still does not work. > My relevant entry in the config is: > > > SetHandler perl-script > PerlHandler Apache::Status > Order deny,allow > Deny from all > Allow from 127.0.0.1 > > The error log says: > [Sun Aug 18 21:02:08 2002] [error] failed to resolve handler > `Apache::Status' It's not supposed to work, yet. It wasn't ported to 2.0. If you have mod_perl 1.0 installed, the 1.0 version is almost fully working under mod_perl 2.0 (The 'Compiled Registry Scripts' menu entry needs some tweaks). To make it working you need the following: PerlModule Apache2 PerlModule Apache::compat PerlModule Apache::Status SetHandler perl-script PerlHandler Apache::Status Order deny,allow Deny from all Allow from 127.0.0.1 __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: NTLM module
Thanks for your advice Gerald. I have found a compromise buy having the directive of Authtype Basic but the perl code has been changed to run the NTLM check as well as SMB (regardlesss of the config file) and if both authentications fail, the standard mod_auth code will then be run. Thanks once again. Adam -Original Message- From: Gerald Richter [mailto:[EMAIL PROTECTED]] Sent: Friday, 16 August 2002 3:19 PM To: Kaye-Smith Adam; Peter Bi; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: NTLM module >when i have Authtype ntlm,basic in httpd.conf and I attempt to use a >username/password that is in htpasswd file I will not be able to be >authenticated & I receive the following error message in >/var/log/http/error.log > >[Thu Aug 15 15:28:53 2002] [crit] [client 131.242.91.200] configuration >error: couldn't check user. No user file?: / > >However when I use Authtype basic in httpd.conf & follow same process I >do not get the above error message in log & I can get authenticated & >bring up the web page. That's because Apache's basic auth handler checks for "AuthType Basic". If AuthType is anythingelse then basic, it doesn't do anything. This could be fixed for basic authentication by letting Apache::AuthenNTLM use another configuration directive instead of AuthType, so you can set AuthType to Basic, but it won't not work for NTLM authentication, because of what I wrote in my previous mails, that there is no password available on the server side to compare against. If it doesn't work with NTLM auth, there is no need to fix it, because you are using Apache::AuthNTLM to get NTLM authentication. If you really only want basic auth and verify your passwords against different backends, like a windows server, you really should use Peters module. If you want NTLM auth and what not only to verify the passwords against a windows server, you have to extent APache::AutheNTLM to handle this, like I wrote in my previous emails. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
Re: guide pdf documentation
Thanks. I didn't see the [pdf] button! >>I tried cvs'ing the data and doing the build deal referenced on >>perl.apache.org, but I'm missing something as I get an error from >>DocSet/Util.pm. It's trying to load Template.pm on line 13, but I don't >>have a Template.pm on my system anywhere. > >Because you miss the prerequisites. Template Toolkit is one of them. You >need to install DocSet which will tell you what the prerequisites are. >I'll release it on CPAN shortly. Meanwhile you can grab it from here: >http://apache.org/~stas/DocSet-0.14.tar.gz Umm, I did install DocSet. Otherwise, how could I have gotten an error from DocSet/Util.pm? It was late for me, perhaps I missed seeing some error message? I'll try it again when I have more time. Thanks. Regards, Rich
Re: Mod_perl Application Development
Chris Winters <[EMAIL PROTECTED]> wrote: >On Sat, 2002-08-17 at 19:31, Jonathan Lonsdale wrote: >> I'm curious to know how people approach application development with >> mod_perl in situations where there could be dozens of distinct >> screens/interfaces. I'm currently using the HTML::Template system. >> >> Here's a few approaches I thought of: >> >> 1. Single monolithic content handler. Could be hard to maintain. >> 2. Distinct content handlers each with their own Location directive. Could >> be a pain to maintain the server config. >> 3. Take a small performance hit and use an Apache::Registry script for each >> screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: >> modules and don't bother being backwardly compatible with CGI. > >There's a separate one that's used in OpenInteract: create a single >content handler that uses some sort of lookup table to map requests to >handlers. This lookup table can be maintained separately from the apache >configuration and can generally be more flexible, allowing for >application-level security settings, etc. Yet another of the many ways : This is similar to what I am doing with the Uttu/Gestinanna projects. Gestinanna is designed around the MVC paradigm. I have Uttu provide my database/cache creation, application configuartion, and uri<->handler mapping which in this case (for web applications with a lot of screens) maps to a Mason dhandler. The dhandler makes sure the proper state machine description is in memory and then continues the state machine execution based on the information sent from the client. The state machine tells the dhandler which view to send back to the client. I have several tricks up my sleeves to allow multiple state machines to be active simultaneously in a session and for even different parts of a state machine to be active simultaneously. I am using Template Toolkit to produce the views (since the people responsible for the views don't like code) and AxKit to generate the end result for the client (so we can support screen, tv, handheld, etc., media types as well as themes [we've had customers request this]). I haven't finished it all yet nor have I done any profiling, so YMMV. You can see the current code at http://sourceforge.net/projects/gestinanna/ (the PerlKB project will be worked in to handle documentation -- most of the current stuff in the Gestinanna project handles dynamic content instead of static content). Btw - I am looking at some of the various CMSs for `inspiration', including OpenInteract and Bricolage. I would recommend looking at how they do things if you are wanting to do content management. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Apache/2.0.40 (Win32) mod_perl/1.99_05-dev Perl/v5.6.1
Hi Mr. Kobes, After including the startup-script my cgi-scripts are now working ok with mod_perl-2. The problem was the missing "use Apache2 ();". My fault. Sorry about that. I owe you some six-packs. The only problem left is "perl-status". It still does not work. My relevant entry in the config is: SetHandler perl-script PerlHandler Apache::Status Order deny,allow Deny from all Allow from 127.0.0.1 The error log says:[Sun Aug 18 21:02:08 2002] [error] failed to resolve handler `Apache::Status' Thanks a lot again. Best regards, Walter
Re: Mod_perl Application Development
On Sat, 2002-08-17 at 19:31, Jonathan Lonsdale wrote: > I'm curious to know how people approach application development with > mod_perl in situations where there could be dozens of distinct > screens/interfaces. I'm currently using the HTML::Template system. > > Here's a few approaches I thought of: > > 1. Single monolithic content handler. Could be hard to maintain. > 2. Distinct content handlers each with their own Location directive. Could > be a pain to maintain the server config. > 3. Take a small performance hit and use an Apache::Registry script for each > screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: > modules and don't bother being backwardly compatible with CGI. There's a separate one that's used in OpenInteract: create a single content handler that uses some sort of lookup table to map requests to handlers. This lookup table can be maintained separately from the apache configuration and can generally be more flexible, allowing for application-level security settings, etc. Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Apache/2.0.40 (Win32) mod_perl/1.99_05-dev Perl/v5.6.1
On Sun, 18 Aug 2002, Walter Stingl wrote: > Hi to all, > > first thanks to Mr. Bekman for his quick answer. But i am still > having problems to track it down, where the script hangs. > "perl-status" delivers a blank window in the browser. > > One more question. Should Apache be started as a service or in > console-mode, when mod_perl is integrated ? It shouldn't really matter - whichever is more convenient. > When i start apache as a service and and try to run a > CGI-script with ModPerl::Registry, the browser hangs forever. > No entry in the Apache error log. I just uploaded a new mod_perl-2 ppm package to http://theoryx5.uwinnipeg.ca/ppmpackages/ compiled against apache-2.0.40 and ActivePerl 633 which you may want to try. You might have to uninstall the old mod_perl-2 package before installing this one, as the version hasn't changed. > When i start apache from console and try to run a CGI-Script > with ModPerl::Registry the following entry is displayed in the > Apache error log: > > [Sun Aug 18 17:21:46 2002] [error] Can't locate loadable object > for module Apache::RequestRec in @INC (@INC contains: > C:/Perl/lib C:/Perl/site/lib .) at > C:/Perl/site/lib/Apache/XSLoader.pm line 16 Compilation failed [ ... ] This looks like it's not picking up the Apache2/ subdirectory of the mod_perl-2 ppm package (where the C stuff is). Do you have a 'use Apache2 ();' in a startup file? See the section on mod_perl 2.0 Server Configuration at http://perl.apache.org/. If you still have problems with things hanging, try freeing up as much memory as possible (eg, close unnecessary windows). I've had problems occasionally with mod_perl-2 and perl-5.6.1 running low on virtual memory. -- best regards, randy kobes
Re: win32 apache2.0.40 mod_perl-2
On Fri, 16 Aug 2002, Paul Simon wrote: > They do work as ordinary CGI scripts (thank goodness!). The > same scripts worked under ModPerl::Registry before I upgraded > everything. There are no messages in the error logs. If I > call the cgi page under ModPerl::Registry via a browser, it > just hangs seemingly forever... I can try installing a simple > hello world handler, skipping ModPerl::Registry, and see if > that works... Hi Paul, I just uploaded a new mod_perl-2 ppm package to http://theoryx5.uwinnipeg.ca/ppmpackages/ which you may want to try - this was still compiled against apache-2.0.40, but constains a few changes to mod_perl-2 since the earlier ppm package (you may have to uninstall the old mod_perl-2 package before installing this one, as the version hasn't changed). This was compiled with ActivePerl 633. All the tests still pass with this version, but occasionally I get errors about Windows running low on virtual memory (this doesn't arise with perl-5.8). If you still have problems with this version about things hanging, try closing as many apps as possible to free up some memory. -- best regards, randy
Re: Mod_perl Application Development
On Sun, 18 Aug 2002, Jonathan Lonsdale wrote: > Date: Sun, 18 Aug 2002 00:31:03 +0100 > From: Jonathan Lonsdale <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Mod_perl Application Development > > I'm curious to know how people approach application development with > mod_perl in situations where there could be dozens of distinct > screens/interfaces. I'm currently using the HTML::Template system. > > Here's a few approaches I thought of: > > 1. Single monolithic content handler. Could be hard to maintain. > 2. Distinct content handlers each with their own Location directive. Could > be a pain to maintain the server config. I've usually done #2, and it is a pain. When you're developing and making up just one at a time, it's not so bad, but when you go to distribute the application and you see that someone will have to set up 10 or so or them, then it looks a little hacky. I've considered going to #1 and using CGI arguments (e.g., "page=foo") or path_info (e.g., "/my_handler/foo") to dispatch to the correct module. I certainly wouldn't advise that the logic for all these s be in one module. > 3. Take a small performance hit and use an Apache::Registry script for each > screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: > modules and don't bother being backwardly compatible with CGI. There's nothing wrong with this or just about any other way you can think as long as it works properly for you. I'm currently looking at the new Apache::TT2 module (http://apache-tt2.sourceforge.net/) as a way of getting rid of all directives. The templates are called in the same manner as HTML pages (i.e., by specifying a URL) and Apache::TT2 processes the pages as it normally would, allowing you to call out to objects and libraries and such. The exhaustive list of how other people are doing this would be difficult to compile and voluminous. I'd recommend you also look into all the other very fine application frameworks, like HTML::Mason, CGI::Application, Apache::PageKit and others. ky
Apache/2.0.40 (Win32) mod_perl/1.99_05-dev Perl/v5.6.1
Hi to all, first thanks to Mr. Bekman for his quick answer. But i am still having problems to track it down, where the script hangs. "perl-status" delivers a blank window in the browser. One more question. Should Apache be started as a service or in console-mode, when mod_perl is integrated ? When i start apache as a service and and try to run a CGI-script with ModPerl::Registry, the browser hangs forever. No entry in the Apache error log. When i start apache from console and try to run a CGI-Script with ModPerl::Registry the following entry is displayed in the Apache error log: [Sun Aug 18 17:21:46 2002] [error] Can't locate loadable object for module Apache::RequestRec in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .) at C:/Perl/site/lib/Apache/XSLoader.pm line 16Compilation failed in require at C:/Perl/site/lib/Apache/compat.pm line 22.BEGIN failed--compilation aborted at C:/Perl/site/lib/Apache/compat.pm line 22.Compilation failed in require at C:/Perl/site/lib/ModPerl/RegistryCooker.pm line 18.BEGIN failed--compilation aborted at C:/Perl/site/lib/ModPerl/RegistryCooker.pm line 18.Compilation failed in require at (eval 3) line 3. ...propagated at C:/Perl/lib/base.pm line 62.BEGIN failed--compilation aborted at C:/Perl/site/lib/ModPerl/Registry.pm line 11.Compilation failed in require at (eval 2) line 3. [Sun Aug 18 17:21:46 2002] [error] failed to resolve handler `ModPerl::Registry'[Sun Aug 18 17:21:46 2002] [error] [client 127.0.0.1] Can't locate loadable object for module Apache::RequestRec in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .) at C:/Perl/site/lib/Apache/XSLoader.pm line 16Compilation failed in require at C:/Perl/site/lib/Apache/compat.pm line 22.BEGIN failed--compilation aborted at C:/Perl/site/lib/Apache/compat.pm line 22.Compilation failed in require at C:/Perl/site/lib/ModPerl/RegistryCooker.pm line 18.BEGIN failed--compilation aborted at C:/Perl/site/lib/ModPerl/RegistryCooker.pm line 18.Compilation failed in require at (eval 3) line 3. ...propagated at C:/Perl/lib/base.pm line 62.BEGIN failed--compilation aborted at C:/Perl/site/lib/ModPerl/Registry.pm line 11.Compilation failed in require at (eval 2) line 3., referer: http://127.0.0.1/abfert_frame.html Best regards, Walter
RE : Mod_perl Application Development
Check CGI::Application from CPAN, Very useful. It uses differents "Run Mode" for Application. Originally, it uses HTML::Template, but can be easily subclassed to use another Template System. We use it with Text::Template. Fred -Message d'origine- De : Jonathan Lonsdale [mailto:[EMAIL PROTECTED]] Envoyé : dimanche 18 août 2002 01:31 À : [EMAIL PROTECTED] Objet : Mod_perl Application Development I'm curious to know how people approach application development with mod_perl in situations where there could be dozens of distinct screens/interfaces. I'm currently using the HTML::Template system. Here's a few approaches I thought of: 1. Single monolithic content handler. Could be hard to maintain. 2. Distinct content handlers each with their own Location directive. Could be a pain to maintain the server config. 3. Take a small performance hit and use an Apache::Registry script for each screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache:: modules and don't bother being backwardly compatible with CGI. Thanks, Jonathan
Re: guide pdf documentation
Quoting Rich Duzenbury <[EMAIL PROTECTED]>: > Hello list, > > Does anyone have a working link to a pdf version (mod_perl 1.27) of the > guide? Found one in the archives that no longer works... i found this one perl.apache.org->documentation->mod_perl 1.0 Documentation->User Guide->PDF LINK [http://perl.apache.org/docs/1.0/guide/guide.pdf] ./allan
