Re: modperl 2
Hi! On Sun, Jun 09, 2002 at 12:42:15AM -0400, Jaberwocky wrote: Does any one know of any modperl 2 resources? mailing lists, stuff like that. mod_perl 2 issues are discussed here on the mod_perl mailing list Please read this before posting: http://perl.apache.org/release/maillist/email-etiquette.html You'll find lots of documentation here: http://perl.apache.org/release/docs/index.html -- D_OMM + http://domm.zsi.at -+ O_xyderkes | neu: Arbeitsplatz | M_echanen | http://domm.zsi.at/d/d162.html | M_asteuei ++
FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
apache 2 mod_perl 2 Apache::DBI
Hello, How can i install Apache::DBI module with mod_perl 2? -- Best regards, Yuri mailto:[EMAIL PROTECTED]
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
I came across the same problem while trying to install a bunch of XML modules via the CPAN module. It was pretty frustrating when the module installations kept dying when it got to expat, even after a installed the expat port time and time again. I think I solved the problem similarly to the way you did, either that or I just decided I didn't need the XML modules installed. Mike -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 10:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. The expat issue has been discussed quite a bit on this list, and is documented here: http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_X ML_Parser Sorry to hear you had trouble finding it. That section of the guide is the first place you should look when you're having segfault problems. - Perrin
2 New Books Needed (was MVC soup, separating C from V in MVC)
Two good books could be written on these subjects: * Mastering Design Patterns with Perl (I understand that Mastering Algorithms with Perl sells quite well) * Rapid Web Application Development with Perl The second one would describe the various application frameworks available, and related tools. Perhaps an expansion of what is at http://perl.apache.org/release/docs/tutorials. It would describe what is available in order to help people decide what to use, it would demonstrate principles of application development, with model code. And, it could help unify the efforts that are out there -- if two systems are extremely similar, why not combine them. It would be interesting to see what eternal principles have emerged from the experience of creating more than one way to do it. Is there a best way or two? Or 4 or 5? Laying out each system in a systematic way, eg in a chart of features, would be an interesting way to define each system. Or like the DBI book has a systematic, uniform format for each DBD driver to describe itself. It is hard to dip into each app framework to see how it ticks, but a book that does that for me would be extremely interesting. From an analysis of the systems, we might find some general principles or best practices, guiding the future evolution of the field. There are perl programs that read a database schema, then generate a complete application for viewing and administering the db. That is rapid app development! I'm not the person to write these books, but perhaps someone(s) here is. Ron At 12:35 AM 06/08/02 -0400, Perrin Harkins wrote: I wish I had more to offer to the discussion, but I echo Bill's sentiments that a write-up would be much appreciated There really are a lot of articles about MVC for web applications. It sounds like Jesse has a new one coming out soon. I covered the basics of it here: http://perl.apache.org/release/docs/tutorials/apps/scale_etoys/etoys.htm l#Code_Structure And the templating tools we've discussed are all covered in my templating tutorial. It's getting a little long in the tooth, but I think it does a good job of conveying the angle that each of the tools has taken. Rob and I talked about writing something, but honestly I have a hard time thinking of what more there is to say. The best thing to do is go and look at the many examples of MVC frameworks for Perl (bOP, OpenInteract, CGI::Application, etc.) and dive into their sample code. - Perrin
Re: [OT] MVC soup (was: separating C from V in MVC)
What I didn't like about this is I then had to adjust the so-called
controller code that decoded the user input for my request object to
include these new features. But really that data was of only interest
to
the model. So a change in the model forced a change in the
controller.
No, a change in the user interface forced a change in the controller,
which is fine. Your user interface now supports parameters of starting
page and page size, so the controller has to know how to handle those
parameters and translate them for the model. (Incidentally, it's not
such a good idea to make page size a query arg. Better to put it in
some config file on the server.)
For example, you might have controller code like this:
my $query = $apr-param('query');
my $page = $apr-param('page');
my $search = Model::Search-new(
query = $query,
page = $page,
);
The controller is tightly coupled to parsing and handling user input,
but knows nothing about what that model object will do with it. It is
basically translating HTTP requests into sets of method calls on model
objects.
So now I just have been passing in an object which has a param()
method
(which, lately I've been using a CGI object instead of an
Apache::Request)
so the model can have full access to all the user input. It bugs me a
bit
because it feels like the model now has intimate access to the user
input.
I agree, this is not good. The controller is supposed to be parsing
that stuff and abstracting it from the model. The model shouldn't care
if you decide to start encrypting some parameters, or getting them from
the user's session, or using different names for them on different
forms.
My second, reasonably unrelated question is this: I often need to make
links back to a page, such as a link for page next. I like to build
links in the view, keeping the HTML out of the model if possible. But
for
something like a page next link that might contain a bunch of
parameters
it would seem best to build href in the model that knows about all
those
parameters.
I don't think it makes a huge difference, but I would probably assemble
these either in the controller or in the view. The model would just
provide the data. If they are simple links (i.e. same params always, no
logic) you should be able to use any templating system to build them.
Template Toolkit has a URL plugin for convenience:
http://www.template-toolkit.org/docs/default/Modules/Template/Plugin/URL
.html
- Perrin
Re: Building high load mod_perl/Mason servers
We are going to be moving to mod_perl, but I am worried about how to keep from getting into the same kind of trap with mod_perl as with PHP. You may want to read my article about building a large site with mod_perl: http://perl.apache.org/release/docs/tutorials/apps/scale_etoys/etoys.htm l. So I am thinking whatever I do it should fit within an existing framework, something like Mason. But I am confused about what real advatage Mason provides, and how things like source code control would work if we are running lots of servers. Your best bet to avoid spaghetti code with Mason is to use OO perl modules for all of the real functionality in the application and then use Mason's components as templates for displaying the results. Mason is good at handling the plumbing aspects of web development and provides an environment for doing HTML templates with in-line perl. See this article for more on appropriate use of components and modules: http://masonhq.com/user/autarch/Comps_vs_modules There are many frameworks for mod_perl, so if Mason doesn't look like exactly what you want you can check out some others here: http://perl.apache.org/#appservers Do people use rsync to keep up to date? If you have a high-volume commercial site, you would be better off with a slightly more structured process. You can set up a script to make releases which will tag the CVS tree and build a release in some package format like RPM or .tar.gz. Then you can QA that release and later install the same release, all with development continuing in CVS for the next release. This allows you to easilly go back to a prior release if a disastrous bug is found in production. (Well, there are issues like config files and database changes which complicate things, but that's the basic idea.) - Perrin
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Yeh, it does apply on other BSD platforms--but I don't think it's specific to BSD(s). I use the same args on Net and Open on Apaches I've built on those platforms. I came across this issue with AxKit. There's tons of references on the web as well: http://www.google.com/search?hl=enie=UTF8oe=UTF8q=disable-rule%3Dexpat -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 7:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of expat, which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is --disable-rule=EXPAT. In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
can't make test for mod_perl 1.27
/usr/ports/www/apache13/work/apache_1.3.24/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c Syntax error on line 3 of /ad4/ENV/common/src/Perl/mod_perl-1.27/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration done Is this a buggy test or something I've missed/ make worked fine. I built and installed mod_perl into apache as a DSO. (please Cc: me directly as I subscribe to the digest form of this list) -- - Vicki Vicki Brown ZZZ Journeyman Sourceror: P.O. Box 1269 zz |\ _,,,---,,_Scripts Philtres San Bruno, CA zz /,`.-'`'-. ;-;;,_ Perl, Unix, MacOS 94066 USA |,4- ) )-,_. ,\ ( `'-' mailto:[EMAIL PROTECTED] '---''(_/--' `-'\_) http://www.cfcl.com/~vlb
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
On Sun, Jun 09, 2002 at 12:43:38PM -0400, Perrin Harkins wrote: I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. The expat issue has been discussed quite a bit on this list, and is documented here: http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_X ML_Parser Sorry to hear you had trouble finding it. That section of the guide is the first place you should look when you're having segfault problems. - Perrin Eeek! Thanks the for the pointer to the warnings and errors guide. I guess when I first tried to find out what was going on by STFW, I thought it was something OpenSRS specific. Later, when I'd found something that seemed to work, I didn't go back and search for expat or XML_Parse. It's reassuring to see that the fix that I'd guessed at is the right one to use, though. Thanks again, -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
