Re: templating system opinions
Jesse Erlbaum wrote: Dave Rolsky writes: Sure, amazon.com among them. Amazon.com uses Mason? Why have I not heard of this before? I personally have not seen an "official" announcement, but if you look at all their postings on jobs.perl.org you'll notice that nearly every one of them mentions Mason. I'm sure Dave will have more to say on the subject... :-) -- ----- Drew Taylor * Web app development & consulting [EMAIL PROTECTED] * Site implementation & hosting www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres -
Re: okay, I give, I'm stumped
There are well written instructions in The Guide that show step by step how to roll a static mod_perl/php/ssl binary. And I've done it personally without much trouble, so it's easier than you might think. ;-) Here's the direct link: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_php Drew At 07:59 PM 7/28/2002 -0700, Greg Rumple wrote: >Yup, this is it. If I build it without DSO support, it appears to work. >Of course I build this with mod_php, mod_ssl, mod_perl, and a couple of >custom modules. So running without DSO support isn't to easy. I guess >I can attempt to build mod_perl in, but keep DSO support and dynamic >load the rest of the modules. Will try that. ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Netflix: Unlimited DVD rentals with NO LATE FEES for $19.95/mo. http://service.bfast.com/bfast/click?bfmid=27276611&siteid=39734327&bfpage=special ==
Re: separating C from V in MVC
Fran, I think the key here is taking care of the 80% easily. This has been mentioned in this thread several times, and in previous threads. No, I don't think there will ever be an (efficient) wrapper that can handle ALL the cases and ALL the possible SQL queries. But if you can handle the majority of them easily with a wrapper, and that wrapper also provides a way to get at the SQL directly (I heard SPOPS as being good for this), then that is a lot of work saved. Work saved = money & time saved = you look better to your boss. Both approaches have merit, so the trick is to determine which one is best for your situation. At my day job, the tables are relatively denormalized, ie. very wide, so a wrapper can easily work. At a previous job I was working to encapsulate all the SQL calls into a single module. The ability to find the approach that works best for you is the difference between a grunt and a good software engineer. :-) Drew At 01:30 AM 6/14/02 -0400, Fran Fabrizio wrote: >I don't typically find apps that just mirror some subset of one of the db >tables to be all that interesting. After all, it's the relationships >between the data that make the data interesting, and by necessity this >means your queries will be complex. And looking over the stuff outlined >at poop.sourceforge.net, there's not too many models/frameworks out there >that can accurately abstract ALL of SQL, and if it only does a subset, I >feel like that's shooting myself in the foot. ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
[OT] WebObjects [Was: Re: separating C from V in MVC]
At 10:59 AM 6/14/02 -0400, kyle dawkins wrote: >As for people claiming never to have seen an OR system that works, I >suggest you check out EOF from NeXT/Apple. For those of you (like me) who didn't know what EOF is, it stands for Enterprise Object Framework and is part of Apple's WebObjects app server. Which has moved on to Java, and thus is OT. :-) But I've heard many good things about WebObjects, so it's on my wish list of technologies to investigate. Drew ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: mod_perl/passing session information (MVC related, maybe...)
At 07:32 AM 6/13/02 -0700, Vuillemot, Ward W wrote: >I log into your web-site as memberA. You kindly leave me a delicious cookie >with my username stored in it. Maybe even my password (I hope not!). Now, >I know that another member, memberB, has special rights to your site. What >is stopping me from editting the cookie to memberB's username and hijacking >their account? >(Plus, the checksum ensures that one is tampering with the >cookie.) You touched this subject in the next paragraph. You should always include a hash or checksum as part of your cookie value. And then validate this info on each request. This prevents the situation you described where you just change the cookie. Even if the cookie value is just a session id, it is nice to have the hash to make sure they just don't go changing their cookie, but not necessary if your session IDs are random. Drew ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Internet Explorer sending nothing in subsequent posts
My first guess is that it's caching the results. We just had fun debugging a problem w/ an aggressive proxy doing exactly this sort of thing. Try holding shift & click reload/refresh and see if the browser actually hits the server then. Go to Tools | Internet Options | General Tab | Temporary Internet Files - Settings and select "every visit to the page" to effectively disable caching. Drew At 10:28 AM 6/12/02 -0400, Harnish, Joe wrote: >When Internet Explorer hits a mod_perl page that uses the post method in >the form it will run the first time but all the subsequent posts will not >get anything sent. > >Does anyone know why this happens? Is there a workaround for mod_perl or >in the Web browser? ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: Porting to OS X
At 11:27 AM 6/4/02 -0700, Michael Robinton wrote: >I'd be very interested in how this progresses. I recently helped a >collegue to get a cgi program running under apache using standard perl on >OSX -- I found that the perl distribution that comes with OSX is the >original 5.6 rather than more up to date versions IIRC, the latest OS update upgrades perl to 5.6.1. ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: Porting to OS X
This is going OT, but the case insensitivity problem is only for the Mac filesystems. I've that all you need to do is switch the filesystem to ufs (the bsd version) and the problem is solved. Of course, if you can't switch fs types I don't know of a workaround. :-) Drew At 10:54 AM 6/4/02 -0700, Vuillemot, Ward W wrote: > >I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >filesystem is NOT case-sensitive. Which can cause problems with certain >applications. . .and we hope (Apple, you listening?) that they will fix >this gross over-sight. ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: What causes memory leaks during graceful restarts?
At 02:15 PM 5/21/02 -0400, Dan Wilga wrote: >I am using Perl 5.6.1, modperl 1.25, and yes it's a DSO. It's compiled with: > > USE_APACI=1 SSL_BASE="/usr/local/ssl" DO_HTTPD=1 > >So I guess the solution is to go to 1.26 or newer; I'll try that later in >the week. Or to just compile mod_perl statically. Unless you need the ability to dynamically add in mod_perl, static is better. I'm sure the guide has all kinds of info about the tradeoffs of DSO vs. static. ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
New mod_perl website [Was Re: Modifying @INC via startup.pl]
This is a little OT, but I really love the new look of the website you mention below. Major kudos to all those who helped put together the new look-n-feel & content. Drew >At 11:53 PM 5/19/2002 +0200, you wrote: >>Thank you very much Gregory, I have patches the online docs. >> >>By the way, the release-ready (almost) site is now at >>http://perl.apache.org/release/ ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Reloading Library Files
Have you tried moving the PerlInitHandler & PerlSetVar up and out of the directive, making it global for the server? I'm not sure that would fix it, but it's worth a try. Drew At 02:37 PM 5/17/02 -0400, Ted Prah wrote: >I have tried Apache::Reload as well, but I get the same results. > >Ted > >Drew Taylor wrote: > > > Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible, > > but StatINC has been around a little longer. Both have worked well for me. > > But be sure that you don't use these modules on a production server. :-) > > > > httpd.conf > > == > > PerlInitHandler Apache::Reload > > > > Drew > > > > At 01:38 PM 5/17/02 -0400, Ted Prah wrote: > > >Hi, > > > > > >I am new to mod_perl and am having problems seeing the > > >changes made to library files. Must I restart the server every > > >time I change a library file in order to see my changes? My > > >test code and environment is below. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Reloading Library Files
Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible, but StatINC has been around a little longer. Both have worked well for me. But be sure that you don't use these modules on a production server. :-) httpd.conf == PerlInitHandler Apache::Reload Drew At 01:38 PM 5/17/02 -0400, Ted Prah wrote: >Hi, > >I am new to mod_perl and am having problems seeing the >changes made to library files. Must I restart the server every >time I change a library file in order to see my changes? My >test code and environment is below. ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: How to disable mod_perl in a subdir (apache)
At 08:58 AM 5/14/02 -0700, Erchinger, Ethan wrote: > > Try > > > > SetHandler default-handler > > > >I tried that as well. Do you think it could be the startup.pl (handler.pl), >shouldn't that only get run when the handler is perl-script? If you have a "PerlRequire startup.pl" statement in your httpd.conf, startup.pl will always be run as Apache is starting up. It has nothing to do with the Set/AddHandler directives. I'm sure there is a section in the guide (http://perl.apache.org/guide/) which has more info, but I don't have a link handy. Drew ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: filtering mod_proxy output
At 04:25 PM 5/14/02 +0200, Charles Bueche wrote: >Hi all, > >I want to implement a transparent reverse proxy, to export an intranet web >server to the Internet. > >I know about the ProxyPass friends, but with such a mapping : > > ProxyPass /toto http://intra.company.com > >the returned HTML page contains links that must be filtered (IMG SRC, >etc). Read up on the ProxyPassReverse directive of mod_proxy. This will do exactly what you are looking for. Drew ====== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Content management systems
At 10:17 AM 4/9/02 -0400, Aaron Ross wrote: >Anybody know of something in mod_perl with this out of the box >functionality in addition to content management? Metadot bills itself as a portal product. I've even installed it briefly in the past, and it seemed relatively easy to setup & customize. http://www.metadot.com/ The developer site is at http://www.metadot.net/. Drew ====== Drew Taylor JA[P|m_p]H http://www.drewtaylor.com/ Just Another Perl|mod_perl Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Content management systems
At 08:08 AM 4/9/02 +0100, Matt Sergeant wrote: >On Tuesday 09 April 2002 7:53 am, Matthew Watson wrote: > > Heya. > > > > 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. > >For community sites, use Slash - the engine behind slashdot >(http://www.slashcode.com) - there's even a book about it. You should also check out scoop (http://scoop.kuro5hin.org/), the engine that runs Kuro5hin.org. It's also written for modperl, and IMHO has some extra community features that makes it better than slash for more "democratic" sites where there are no "editors" like on /. who decide what stories get posted. Oh, and it does have diaries. ;-) Drew
Re: PDF generation
I can highly recommend PDFLib. It's not quite free in that you have to buy a license if you make a product out of it, but it's still cheap. Matt Sergeant has recently added an OO interface over the PDFLib functions with PDFLib. http://search.cpan.org/search?dist=PDFLib There are others that will convert HTML into PDF, but I prefer the precise options available with PDFLib. Drew At 03:43 PM 4/3/02 -0500, Bill McCabe wrote: >Hi All > >I have a large number of mod_perl modules that connect to various >databases and >generate workflow performance reports for my organization. I give the users 3 >output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output >I've been using PDF::Create, which has been at version .01 since 1999. It has >worked flawlessly for my purposes for a couple of years, but is very >limited. In >fine form-follows-function fashion, the end users would now like the PDF >output >gussied up with graphics, etc. Does anyone have any strong (positive or >negative) recommendations for which module(s) I should migrate to? > > >TIA, >Bill
Re: Java???
Think April 1... ;-) At 10:51 AM 4/1/02 -0500, John Von Essen wrote: >Why does CPAN.org say "Comprehensive Java Archive Network" > >-jve
Re: How to get two perl namespaces in apache
Thomas, You can run seperate environments if your coding doesn't reference any hard coded paths. I just setup a dev server at my new job and do exactly what you want. All you have to do is add a "use lib qw(/path/to/modules);" in your startup.pl or make sure the PERL5LIB environment var is set. This can be done w/ "PerlSetVar /your/path/here" or setting it for the user apache is running as. HTH. Drew At 11:16 AM 3/26/02 -0800, Thomas K. Burkholder wrote: >Hi there- > >Apologies if this gets sent twice - I sent a message yesterday, but it >seems to have vanished into the ether. > >I'd like to run the production server of my mod_perl project >(http://www.areaj.org/areaj) on the same machine as my development >server. Clearly they have the same module names so I have to somehow run >them in two different environments - I don't think running them on two >different virtual servers is going to do it, right? Doesn't apache just >start one perl "runtime"? Please tell me if I'm mistaken about that.
Re: Non-web use for Apache/mod_perl
Have you tried Postgresql? It's a free, fast, ACID compliant database. I
have it compiled & running within a few hours, not knowing much of anything
about it before hand. From what I've read the speed is comparable w/ mysql
for most applications.
Drew
At 12:40 AM 3/21/2002 +0100, Bas A.Schulte wrote:
>To handle a large number of concurrent transactions in a transaction-safe
>environment without me having to worry too much about concurrency issues
>and referential integrity I will slowly move to Oracle. $dbh->do('LOCK
>TABLE USER, INSTANCE, APP_DATA') just plain sucks unless you want to
>create a very large distributed *single-user* system running on multiple
>machines.
======
Drew Taylor JA[P|m_p]H
http://www.drewtaylor.com/ Just Another Perl|mod_perl Hacker
mailto:[EMAIL PROTECTED] *** God bless America! ***
--
Speakeasy.net: A DSL provider with a clue. Sign up today.
http://www.speakeasy.net/refer/29655
==
Re: [OT] eToys Jingle (was: Where was that success story?)
Thanks to Gnutella, I'm getting chills all over again. I just love that song. eToys might not have survived, but their marketing sure did. :-) At 02:45 PM 3/6/2002 -0800, Tom Servo wrote: > > What I really want to know is: what ever happened to that eToys jingle > > that was on the commercials? It was almost as good as the site. My > > children were all under 7 when the site folded, so those commercials and > > that jingle REALLY pulled the heart strings. > > > >Heh, used to work there. Song was: > >"Somewhere Over the Rainbow/What a Wonderful World" >by Israel Kamakawiwo'ole >on the album "Facing Future" > >Enjoy. > >Brian Nilsen == Drew Taylor JA[P|m_p]H http://www.drewtaylor.com/ Just Another Perl|mod_perl Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: [OT-ish] Session refresh philosophy
I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data structure. I prefer the simplicity of just worrying about a structure, and not having to worry about converting it to a string. That said, I like the approach that the two modules use. One just goes an extra step to guarantee data security. While looking for full-time employment, I've been doing some freelance work, which basically is small CGI apps. C:EF looks like it would make my life much easier by ensuring consistent state w/ small effort on my part, and take care of any security precautions as well. Combine that w/ CGI::Application (after I add TT2 support :-) ), and my life as a freelance CGI guy just got a whole lot easier. Thank you to everyone who contributed to this thread. I've gotten all kinds of neat ideas I'll use in future projects! Drew At 10:19 AM 2/20/2002 -0500, Perrin Harkins wrote: > > When I used CGI::SecureState it gave the client a non-versioning (more on > > that later) key and stored the state information in the filesystem. > >Okay, I only looked at it briefly and thought it stored the data on the >client. Your module is actually more like CGI::EncryptForm I think, but >yours may make things a bit more transparent. Maybe you should polish it up >for CPAN. > >I'm well aware of the page-state vs. browser-state problem. I was recently >bitten by it again when some consultants built a web app for my company that >puts the search results in a session keyed on a cookie. As soon as the user >opens two windows, it's absolute mayhem. > >- Perrin Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT-ish] Session refresh philosophy
At 05:55 PM 2/19/2002 -0500, Perrin Harkins wrote: >Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned >a few days ago about storing state entirely inside a cookie with a message >digest. The only difference is that by sticking it in a form element you're >attaching it to a specific page. True. I was very intrigued by his approach, and might use something like that to increase the security of my app by verifying the hidden form field contents. I suppose I could follow his approach, but the amount of data I need to store could possibly overwhelm the 4KB cookie limit. In this case, simple was better - simple application, simple session. And I know I can count on every browser implementing forms. :-) Drew Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT-ish] Session refresh philosophy
And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form fields. It's primitive, but was actually a bit of a challenge to make sure a (unused) hidden field and a visible form element don't appear in the same . Not my first choice, but it definitely works. Drew At 11:42 AM 2/19/2002 +, Ged Haywood wrote: >Hi there, > >On Mon, 18 Feb 2002, Milo Hyson wrote: > > > maybe I'm just approaching the problem incorrectly. If one is doing a > > shopping-cart-style application (whereby someone selects/configures > multiple > > items before they're ultimately committed to a database) how else would > you > > do it? There has to be some semi-persistent (i.e. inter-request) data > where > > selections are stored before they're confirmed. > >You can for example send a hidden object back and forth between >your Client and the app. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: choice of mod_perl technology for news site
You should take a look at Bricolage (http://bricolage.thepirtgroup.com/). It's a relatively new, but comprehensive, CMS that is based on Mason & mod_perl. I think it supports most of the things you mentioned below, but you should ask the developers to be sure. If you talk w/ Matt, he'll be sure to hawk AxKit. But then that's Matt. And AxKit really is cool stuff. :-) Drew At 05:06 PM 2/6/2002 -0800, Nate Campi wrote: >Lets pretend I work for Wired News, and I really really hate Vignette's >content management system. I mean *really* hate it. I'm the Ops guy >supporting it and I have nightmares about the next unexplained CMS >crash. > >Ok, we all know mod_perl is the right choice to replace their system, >but what is the right way to go when you have a full news staff with >many stories going out six days a week, and about a million hits a day? > >You need all the workflow tools for the news staff, versioning, stories >going live at defined times and dates, etc, etc. I don't have the exact >requirements, as I'm just trying to collect my thoughts right now, to >bring my ideas to the software guys in a couple days. I can get the >exact requirements if needed. > >I like Mason's way of doing things, and it works for salon.com (similar >needs), but now that we have AxKit, is that the right way to go? Seems >better to force the separation of content and display, and using XML >allows the stories to be easily shared for display on affiliated sites. > >Thoughts? I'm thinking of even donating my mediocre coding skills if >they take my advice on this - die Vignette!! I'll do my part to slay the >evil beast. > >Oh, I mean if this wasn't all hypothetical - I wouldn't discuss internal >issues like this with the general public ;) >-- >Nate > >"Usenet isn't a right. It's a right, a left, and a swift uppercut to the >jaw." -Computer Museum (Boston) Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [OT] email attachments - Win32 email reader to replace OE
At 01:27 AM 2/3/2002 -0200, Jorge Godoy wrote: >"Rod Butcher" <[EMAIL PROTECTED]> writes: > > > Guys, in light of recent messages, can you suggest a secure full-function > > Win32 email reader (including optional HTML) with a brain that I can > migrate > > all my Outlook Express stuff to and so escape the Virus nightmare and deal > > with PGP, GPG etc and hence use electronic communication the way it's meant > > to be used ? > >I'm not a Windows user (thanks God!), but a friend of mine loves a >program named 'The Bat!'. There's also 'Eudora' (I've used Eudore 6 >years ago...). I've been a Eudora guy for more than a few years now. I think I started with version 3, but I could be wrong. It's a great mailer, and now it really is free if you want to watch their advertising. I don't have any problem with it, but AdAware will tell you you're infected w/ spyware. The best thing about Eudora is that it uses good old mbox format, so you could later move to mutt once you're on unix. Oh, and it's stable and immune to the Outlook viruses too. :-) Drew Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: Any good WebMail programs?
I can recommend SquirrelMail (http://www.squirrelmail.org/) It's also written in PHP, but seems pretty well laid out. It also works well w/ shared hosting. :-) At 10:44 PM 12/12/2001 -0800, Medi Montaseri wrote: >I can use a primer on researching WebMail programs with the following >criterian: > >- Linux based >- Free >- Preferably in Perl >- Modularized Authentication subsystem (ie could hook up adapters to > check with LDAP or RDBMS, though Linux can do that also) >- Apache support >- IMAP support >- Multi-lingual (can be a phase II) >- As feature-rich as possible (can be a phase II) Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [OT] pdf creation
At 04:01 PM 10/28/2001 -0600, Lon Koenig wrote: >I apologize for the OT post, but the members of this list seem to be >authoritive resource for all web/perl solutions. > >I'm currently bidding a project, and the client's all in favor of a >mod_perl solution. Phase 2 of the project requires on-the-fly pdf creation. > >Does anyone have success/horror stories generating pdf files under mod_perl? >Recommendations? I've used PDFLib for several projects, and it works wonderfully. The core is written in ANSI C with interfaces for every popular language. It's not free, but it does a lot and works very well. http://www.pdflib.com/ Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [OT] excellent modperl/etoys article by Perrin revisited
At 12:26 PM 10/25/2001 +0800, Gunther Birznieks wrote: >I saw an article in today's ComputerWorld that indicates the technology et >al for eToys was bought by another toy firm (KB) and they plan to put it >up to sell toys for this holiday season again. > >http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html > >Perrin or others involved in the old eToys (or anyone in the new >eToys) -- does anyone know if this is the same mod_perl technology you >guys wrote? Well, I'm just talking off the top of my head, but my interpretation is that "the Web site relies on eToys software purchased at the bankruptcy auction and on KB Toys' existing IT infrastructure" means that it's the software Perrin et al. wrote, running on KB's hardware. I can't imagine that to mean that they rewrote the software. If so, that just validates the decisions the eToys design team made. Even more kudos Perrin! :-) Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: Excellent article on Apache/mod_perl at eToys
At 10:11 AM 10/23/01 -0600, Nathan Torkington wrote: >Leon Brocard writes: > > > Perhaps a port of JMS is in order. > > > > Interestingly, I've been thinking along the same lines. Spread > > (http://www.spread.org/) can be used for the publish/subscribe > > messaging domain but queueing seems to be important too. Straying a > > bit offtopic perhaps, but I wonder what would be involved... > >I like the idea of P2EE. If the goal is to provide the same features >as Java, why not just implement the Java messaging, transactions, >etc. APIs in Perl? That is, endeavour to have the same classes and >methods as Java, to the greatest extent possible. That'll also make >it possible for Java programmers to become Perl programmers, bwahaha. The servlet API has been mostly(?) translated into perl by Brian Moseley. The homepage is http://libservlet.sourceforge.net/ and it's available on CPAN. The docs look a little parse at the moment, but kudos to Brian for the work done so far! Now if only I could figure out a good test application to try it with... Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [Templates] Re: Excellent article on Apache/mod_perl at eToys
What I found most interesting was the detail of the extensive caching which was implemented to survive the seasonal rush. I look forward to working on a project one day that is big enough to warrant such a system. All in all, a most excellent and informative read. Thanks again for everything you've personally done for the community! I look forward to seeing those graphics. :-) At 09:49 AM 10/19/01 -0400, Perrin Harkins wrote: >Thanks to all for the kind words. This article actually went up a little >bit before it was supposed to, and there should be a revision going up soon >with some grammatical fixes and a set of graphics to illustrate parts of it. >I'll post a follow-up when that happens in case anyone wants to go and look >at the pretty pictures. > >While we're on the subject, thanks to everyone who contributed to the many >open source projects that we used. We couldn't have done it without you. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [OT] Overridding a module's use of a function
It's funny you should ask, because I just finished reading that section
today! :-) On pg 306-7 of the Camel (3rd edition):
*CORE::GLOBAL::glob = sub {
my $pat = shift;
my @got;
# do whatever
return @got;
}
will override a built-in function everywhere, regardless of namespaces. The
method you use (namely overriding CORE::function) restricts the overriding
of the function "to the package that requests the import."
At 05:15 PM 10/11/01 -0500, George Sanderson wrote:
>I discovered that File::NCopy uses the function "glob" to expand file
>names. My problem is that I need to pass file names that have spaces in
>them and "glob" does not process them. So I did the following override (I
>do not need to expand the file names):
>
>package Apache::AAM;
>. . .
>package File::NCopy;
>use subs qw(glob);
>sub glob {@_};
>package Apache::AAM;
>. . .
>
>Is there a better way to do this?
Drew Taylor JA[P|m_p|SQL]H
http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker
mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [Knowledge Base] First coherent release
At 11:45 AM 10/11/01 -0500, Jim Smith wrote: >On Thu, Oct 11, 2001 at 11:25:43AM -0400, Drew Taylor wrote: > > I assume that the reason I get the "Can't locate the render_format method" > > is because you're not actually storing any objects yet? > > Not sure. It should be able to see it. Can you give me the line number > or any other context for it? Is it version 0.03 (the changes I mentioned > in the previous e-mail)? Yes, I did add the changes you mentioned in the previous email althought I did not DL the new tarball. Let me try that... Interesting... I DL the newest taball. Now I get a bunch of code scrolling by (stupid DOS prompt...) which I guess is the sample.doc. But I still get the error: "Can't locate object method "render_format" via package "PerlKB::Document::pod" ( perhaps you forgot to load "PerlKB::Document::pod"?) at test.pl line 40." > Do you have Config::Pod located somewhere? It's needed for the > PerlKB::Configuration::Pod module to work (and no, I don't have that > documented that I know of, yet - sorry). Yup, I found out about that one the hard way. :-) > Btw, thanks for trying it out -- especially since I don't have access to > Microsoft sysems :) Glad to help. BTW, Win32 is just my home system. All my real programming is done on *nix. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [Knowledge Base] First coherent release
I feel a little stupid now that I actually read up on tying hashes. Had I
read Ch 14 of the Camel #3, I might have phrased my question in a better
way so as to not illuminate my inexperience with tying variables. :-)
I assume that the reason I get the "Can't locate the render_format method"
is because you're not actually storing any objects yet?
One final question, by using "our" you're restricting these modules to perl
5.6.x. Is there any particular reason for this? From the looks of it, the
usage of our could easily be changed. Do you have plans to take advantage
of other 5.6 specific features? Either way it would be nice if you included
a "require 5.6.0;" in PerlKB.pm so that it would be immediately obvious to
the new user.
At 03:06 AM 10/11/01 -0500, Jim Smith wrote:
>On Thu, Oct 11, 2001 at 02:53:09AM -0400, Drew Taylor wrote:
> > I've run into a WEIRD problem that I think is ActivePerl related. I've
> > installed the PerlKB modules and added some debugging code to
> > PerlKB::Store.pm. The short story is that I have to shift TWICE to get rid
> > of the "PerlKB::Store"! This is with the latest ActivePerl which I just
> > installed tonight. And to top it off, once the config href is populated I
> > get an "illegal operation" error and no result. :-( My system is Win98 SE.
> >
> > Any ideas? This is just weird...
>
>*doh* yes. I should have caught it. The following change has been made to
>cvs (< == old, > == new). Change the URL from -0.02.tar.gz to -0.03.tar.gz.
>
>% cvs diff Store.pm
>Index: Store.pm
>===
>RCS file: /cvsroot/perlkb/perlkb/lib/PerlKB/Store.pm,v
>retrieving revision 1.4
>diff -r1.4 Store.pm
>18c18
>< croak "No configuration" unless $self -> {config} -> {configuration}
>-> isa("PerlKB::Configuration");
>---
> > croak "No configuration" unless $self -> {config} ->
> {configuration} && $self -> {config} -> {configuration} ->
>isa("PerlKB::Configuration");
>33c33
>< sub TIEHASH { return $_[0] -> new(@_); }
>---
> > sub TIEHASH { return shift -> new(@_); }
Drew Taylor JA[P|m_p|SQL]H
http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker
mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: [Knowledge Base] First coherent release
I've run into a WEIRD problem that I think is ActivePerl related. I've
installed the PerlKB modules and added some debugging code to
PerlKB::Store.pm. The short story is that I have to shift TWICE to get rid
of the "PerlKB::Store"! This is with the latest ActivePerl which I just
installed tonight. And to top it off, once the config href is populated I
get an "illegal operation" error and no result. :-( My system is Win98 SE.
Any ideas? This is just weird...
C:\install\PerlKB-0.02\example>perl -v
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2001, Larry Wall
Binary build 629 provided by ActiveState Tool Corp. http://www.ActiveState.com
Built 12:27:04 Aug 20 2001
PerlKB::Store.pm
sub new {
my $class = shift;
$class = ref $class || $class;
my $self = { };
#shift;
carp("new called w/ @_");
print Dumper($self->{config});
}
C:\install\PerlKB-0.02\example>perl test.pl
new called w/ PerlKB::Store type File configuration
PerlKB::Configuration=HASH(0
x176f0d8) document_root ../lib at test.pl line 10
$VAR1 = {
'PerlKB::Configuration=HASH(0x176f0d8)' => 'document_root',
'PerlKB::Store' => 'type',
'../lib' => undef,
'File' => 'configuration'
};
Can't call method "isa" on an undefined value at
E:/Perl/site/lib/PerlKB/Store.p
m line 29.
At 12:09 AM 10/11/01 -0500, James G Smith wrote:
>I've put together a tarball of the PerlKB modules:
>
>http://prdownloads.sourceforge.net/perlkb/PerlKB-0.02.tar.gz
>
>The example/ directory has a little script that shows how the store objects
>work. The scripts/ directory has a perl script that starts up the
>PerlKB::Shell monitor (modeled in a small way after the CPAN shell).
>
>Otherwise, it doesn't do a whole lot, but it's starting to come together.
>
>Project page: http://sourceforge.net/projects/perlkb/
>+--
>James Smith - [EMAIL PROTECTED] | http://www.jamesmith.com/
> [EMAIL PROTECTED] |
> http://cis.tamu.edu/systems/opensystems/
>+--
Drew Taylor JA[P|m_p|SQL]H
http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker
mailto:[EMAIL PROTECTED] *** God bless America! ***
Re: brochureware perl.apache.org?!
At 04:41 PM 4/28/01 -0400, Philip Mak wrote: >On Sat, 28 Apr 2001, Drew Taylor wrote: > > > I agree 100%. If I might throw my $.02 in, IMHO a part of this marketing > > should be a more "brochureware" perl.apache.org. > >If you guys do redesign perl.apache.org, please, PLEASE take usability >into account. http://www.useit.com/ is a great resource about how to make >a usable website. Agreed! I assumed usability would be taken into account in any new design. :-) Two jobs ago I worked for a web development shop whose primary focus was on user-centered design, so I know all about keeping the end user in mind. Drew Taylor mailto:[EMAIL PROTECTED] http://www.drewtaylor.com/
Re: an unusual [job request] + taking mod_perl to the commercial world
At 10:41 PM 4/27/01 -0400, barries wrote: >On Fri, Apr 27, 2001 at 11:44:49PM +0800, Stas Bekman wrote: > > > > Since mod_perl is an open source, it's a tough quest. Basically what I > > want is get some company that will benefit from me working on open source > > project full time and pay me a salary. Of course it's probably hard to get > > a full time open source position, so probably some compromising offer, > > where we do some 50-75% of the time mod_perl development and the rest > > doing something else, if it makes the company more happy. > >As you and others have mentioned here now and in the past, mod_perl >needs PR and working apps (which are both good PR and good reasons for >others to start using it as a means to an end: like the new Slash code, >for instance). I agree 100%. If I might throw my $.02 in, IMHO a part of this marketing should be a more "brochureware" perl.apache.org. The content there is top notch and I can't say enough good things about it. The amount of documentation is simply amazing and there are many commercial products that aren't as well documented. However, the current site looks like it was designed by a programmer. And I mean no offense, because that is also how my personal site currently looks. :-) I think that perl.apache.org should present a more "professional" face to corporate people who are looking at using perl/mod_perl. For an example, look at the various java.apache.org sites. They have navigation and are split into multiple sections and pages. Someone took the time to section off the various topics and put together graphics and navigation. I'm sure the amount of data/documentation is the same between say Tomcat and mod_perl, but I prefer the packaging of the java sites. If we are to get more corporate interest in mod_perl, the community should work to present the information about mod_perl in such a way that the managers/business people who make the decisions can reason that mod_perl is a technology they should use. We already know mod_perl is great, we just have to make the rest of the world realize it. Marketing is as much about appearance as capabilities. Just look at the marketing depts that dotcoms put together to hype a product that didn't yet exist! I remember seeing some proofs done by Robin Berjon (I'm sure I'm not spelling it right!) long ago that I really liked. But they were never used AFAIK. I also registered modperlnews.(org|com) a while back with the intention of doing something useful with them, but I have not yet done anything. I also have some time on my hands while I'm searching for a new job, so I am volunteering my time if it's needed or wanted. I'll bet that Template Toolkit (thanks Andy!) would work wonderfully for putting a new face on the site. If the powers that be are interested, I am available to help. And if I'm off track, then tell me and I'll go back to lurking. :-) >Such an organization could do (aside from the feature development listed >above): > >- general advocacy: press releases, reference cards, publish > articles and sell a qr/this (article|research) funded by > (ActiveState|VMWare|Covalent|IBM S/390 Marketing Division|.*)/ credit Drew Taylor mailto:[EMAIL PROTECTED] http://www.drewtaylor.com/
[Job Seeker] Looking for a job
Hi all, I've recently been laid off from my dot-com and am looking for a new full-time job. I have several years of perl, as well as mod_perl, programming experience. My resume and more information can be had at http://www.drewtaylor.com/ Thanks. Drew Taylor mailto:[EMAIL PROTECTED] http://www.drewtaylor.com/
Re: [OT] ApacheCon BOF
I second that suggestion. I have one from last year (I found the BOF because Stas laid the T-shirts out in a path to the room - good one Stas! :-), but I won't be there this year. Speaking of which, will the mod_perl classes have the handouts available over the web? John Saylor wrote: > > Hi > > ( 01.03.19 13:35 -0500 ) Geoffrey Young: > > In the spirit of things free and fun, I again have a sponsor for mod_perl > > T-Shirts for this year's ApacheCon BOF. > > Any thought of making a extra and selling them off the list for people > who can't get to ApacheCon and yet want to proclaim their mod_perl ness? -- Drew Taylor Software Engineer OpenAir.com http://www.openair.com/
Re: Passing data among handlers
I have a slightly different twist on this question. We run Registry scripts on our site for debugging purposes. I would love to have a module for saving variables/data structures on a per-request basis (like the current Apache notes), but internally using pnotes under mod_perl, and some other mechanism (package vars like I'm using now?) under everything else. The purpose of this being so that I could have a nice interface for per-request data that I could pass between different (non-OO) modules. This sounds vaguely familiar to what you did Barry. Can you elaborate a little? Barry Hoggard wrote: > > We created our own "request" object that gets passed to components that > might need it. We were concerned about pnotes becoming a big, > hard-to-debug global area. > > = > Barry Hoggard > http://www.hoggard.org -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! http://www.openair.com/
Re: [OT] Re: Mod_perl tutorials
Robin Berjon wrote: > > At 23:31 13/12/2000 +0100, Stas Bekman wrote: > >> A quick check of nsiregistry.com shows that modperlnews.(com|org|net) > are all > >> available. > > > >Too bad for you/us. You can be sure that when you will go to register any > >of the above they will be all taken by a reseller. I've mentioned a few > >times on this list that one should do atomic buys (tm). If you check and > >don't buy in the same assembly opcode, someone else snoops on your search > >and will do it for you. The only way to get a domain nowadays is to > >check-buy atomically. I have enough examples of people who were > >burned. I've lost stas.com 2.5 years ago, because it took me 1 day to > >decide that I want to spend $$ on it, well it was taken the next day... > > That's all too true. For certain Network Solutions have a service that > warns some people that have paid (a lot) when someone checks an address > that doesn't exist yet. They offered it to one of the companies I worked > for once so I know for sure. Why does this not surprise me? Was it before or after Verisign bought them? > This doesn't mean that modperlnew will be > taken within hours but one should be very careful when using registrars' > whois/dns check tools. If you could want it, buy it immediately. Maybe some > registrars are not that kind of bandits, but it's hard to know. When the > revolution comes, we should probably hang most of those nic people ;) Well, I have registered (through an OpenSRS reseller I might add) modperlnews.com and .org. If anyone is interested in using them, let me know and I can get the DNS taken care of. Matt, are you interested? If not, maybe I'll start my own advocacy site. :-P -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com
Re: Mod_perl tutorials
Dave Kaufman wrote: > > i have to say i really like the look and feel of Matt's take23.org. (and by > the way, for those, like me, who can't seem to keep up with reading *every* > message on this list... it's take23.ORG. I went looking for "take23" and i > can attest that the cryptic but nicely designed take23.COM, has nothing at > all to do with mod_perl on it :-)) I vaguely remember seeing mockups similar to take23.org as a proposed facelift for perl.apache.org. I really liked the design and always wondered why it never got used (apart from the manhours to implement the change :-) > i for one would like to see take23.org become "the place" for people > deciding if mod_perl is for them, getting started with it, and keeping up > with the latest and greatest. i did turn my nose up at the banners at > first, but on second thought, i'm even more *thoroughly* sick of open-source > resource sites that are plain (unintesting, visually) and whose content is > stale due to a lackluster (volunteer) maintenance. so, if some ad-income > keeps take23 fresh and useful, i think i could be bothered to remember the > URL :-) A quick check of nsiregistry.com shows that modperlnews.(com|org|net) are all available. Those domains are definately a little easier to remember than take23. What are some other alternatives to take23.org that would be easier on the grey matter? -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com
Re: XML::ValidWriter -> \$scaler [Was: mod_perl advocacy project resurrection]
barries wrote: > > On Tue, Dec 05, 2000 at 05:31:49PM -0500, Drew Taylor wrote: > > > > I've used XML::Checker::Parser with no big issues. Good to hear. Unfortunately, we are using an older version of XML::Parser (2.22), while XML::Checker requires 2.23 (according to make test). I'm not going to even try to get this upgraded on the production site knowing how finicky XML::Parser can be. But I'll definately keep it in mind should we upgrade in the future. I see our API becoming much more important in the near future, and this might help get things upgraded sooner. > > My biggest problem with XML::Writer (and hence XML::ValidWriter) is that > > I can't write to a string, unless there is some hackish workaround. > > XML::ValidWriter writes to a string if you pass in a \$scalar as the > destination: > >new > $writer = XML::ValidWriter->new( DTD => $dtd, OUTPUT => \*FH ) ; > >Creates an XML::ValidWriter. > >The value passed for OUTPUT may be: > >a SCALAR ref >if you want to direct output to append to a >scalar. This scalar is truncated whenever the >XML::ValidWriter object is reset() or DESTROY()ed I stand corrected. :-) I'll play around with XML::ValidWriter and see what happens. Of course, I also happen to like the way we generate XML now. It's just a big array of arrays of arrays... reference that is walked to make the XML. Pretty neat, and the implementation is actually very simple. -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl vs Java (XML Modules)
Matt Sergeant wrote: > > On Tue, 5 Dec 2000, Drew Taylor wrote: > > > I know this goes a little off topic, so I apologize in advance. > > I changed the topic for you :-) But now it seems like flame bait ;-) > > One big sticking point with Perl I'm just starting to run into is XML. > > Yes, Perl has great XML modules, and many more promising ones. But where > > is the _validating_ XML parser? I'm doing some XML work where a > > validating parser would be very nice, speed hit or not. I can work > > around it easily (this is perl :-), but it would save me some work. > > XML::Checker. > Also see www.perl.com which links to Kip Hampton's XML.com article about > validating using XPath. I'll look more into XML::Checker. Apart from being alpha, it seems like it will work nicely. I guess I could help with the alpha status if I choose. :-) > > The XML & Java combination has a LOT more corporate resources (read $$$) > > focused on it than Perl & XML. How many Java-based XML software > > announcements have you seen lately? Now compare that to Perl-based XML > > modules. The numbers don't compare very well. What can we do about this? > > Very little, except produce our own XML modules that can do our work. And > you can help by praising those that do produce good XML modules and by > using the modules that work rather than those that don't (hint: XML::XPath > vs XML::DOM with XML::XQL). Apart from validation, what are you missing? True. As for praise, XML::Parser does the job for me. In this specific case, I'll be looking for something like failure in the response to an XML request I send. I'd like to pull out just the section that failed and be able to create another request from that XML chunk. It's a little down the road, but I'm trying to plan today. > > I can't help write a validating parser, but I would be happy to help > > test it out. IMHO, more XML support would help sell perl into more > > corporate settings. Java is big into buzzwords, and XML is one of the > > biggest there is at the moment. And as we know PHBs like buzzwords, so > > that is one more point in Java's favor. > > Actually XML is one area where mod_perl kicks Java's butt in some ways. > AxKit is *faster* than Cocoon. Please test and see for yourself if you > don't believe me. And building XML based web sites with AxKit is *really* > easy. I built modperl.sergeant.org in 10 days of spare time, including a > content management system for the news articles (note that half of the CMS > code is just a plain mod_perl handler). I'll stick an article online > shortly about how the site is constructed. When AxKit first came out, I was very excited about it but never had a chance to play with it. And it gives me (and you I'm sure) great pride that perl's XML app server is faster than the equivalent Java version. ;-) I hope to have a play server at home soon so that I can begin playing with cool new toys like AxKit and A0. My experience with XML is limited at the moment, but I'm learning quickly. -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
barries wrote: > > On Tue, Dec 05, 2000 at 04:10:01PM -0500, Drew Taylor wrote: > > I know this goes a little off topic, so I apologize in advance. > > > > One big sticking point with Perl I'm just starting to run into is XML. > > Yes, Perl has great XML modules, and many more promising ones. But where > > is the _validating_ XML parser? > > Will XML::Checker::Parser do? Hmmm, looks interesting. I'll check into it. Any experience (good or bad) with it? I see that it relies on XML::Parser. How well does XML::Parser handle the newly available external DTD feature? > > I'm doing some XML work where a > > validating parser would be very nice, speed hit or not. I can work > > around it easily (this is perl :-), but it would save me some work. > > And, if you want to validate while writing, XML::ValidWriter > might help. My biggest problem with XML::Writer (and hence XML::ValidWriter) is that I can't write to a string, unless there is some hackish workaround. I remember someone talking about an IO::String sort of module, but it sounds like using a sledhammer to drive a nail. ;-) I did actually check out XML::Writer, and even went to far as to replace the IO handle stuff with a plain old string. But then decided to use something else. While I love the idea of validating as I write XML, it doesn't help on the other end. :-( -- Drew Taylor Software Engineer Phone: 617.351.0245 Fax 617.350.3496 OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Stas Bekman wrote: > > On Tue, 5 Dec 2000, brian moseley wrote: > > > > > people won't use the software if you don't give them a > > compelling reason. mod_perl and the higher layer systems > > that use it are not as easy to configure or program as php, > > and they have a lot less support from external software > > vendors or relevance inside engineering shops than java. we > > are being squeezed from both ends. > > > > i had lunch with doug and jon swartz not too long ago, > > talking about the possibility of starting a web application > > infrastructure company based on mod_perl and mason. when we > > got down to it, the fundamental question was: why not just > > use java? and we couldn't find any answer other than "i like > > perl better". and that's not a reasonable business > > justification. > > > > at some point we're going to run out of hobbyists and others > > who /can/ justify using mod_perl-based technologies because > > they like perl better. > > You forget about satisfaction. Do you feel happier to program in Java than > Perl? You want your employees to enjoy they work. We spend too much time > working, I want to enjoy most of my working hours. You want me for my > design and architecture skills, you have to give me something in return. > For me salary is much less important factor than satisfaction. > > Therefore if the same job can be done with Perl and Java, why not to have > your staff happy? That's the main point I think. > > Of course if the bussiness suffers because Perl is not good enough, that's > a different point. Given that at least the same could be done with Perl > and Java, Perl and PHP, Perl and whatever, I want to code in Perl. I know this goes a little off topic, so I apologize in advance. One big sticking point with Perl I'm just starting to run into is XML. Yes, Perl has great XML modules, and many more promising ones. But where is the _validating_ XML parser? I'm doing some XML work where a validating parser would be very nice, speed hit or not. I can work around it easily (this is perl :-), but it would save me some work. The XML & Java combination has a LOT more corporate resources (read $$$) focused on it than Perl & XML. How many Java-based XML software announcements have you seen lately? Now compare that to Perl-based XML modules. The numbers don't compare very well. What can we do about this? I can't help write a validating parser, but I would be happy to help test it out. IMHO, more XML support would help sell perl into more corporate settings. Java is big into buzzwords, and XML is one of the biggest there is at the moment. And as we know PHBs like buzzwords, so that is one more point in Java's favor. I'm quite happy being a perl programmer, although I do plan on learning other languages in the future. I love perl. As such, I'm definately all for keeping my future job market as large as possible. If getting perl more into the corporate eye helps that goal, then what do I need to do as a "little guy"? -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] ApacheCon USA 2001: Call For Papers
Matt Sergeant wrote: > > > > > If any one is interested I could do something on Session Manager - which > > I've been looking at rewriting in C - but I have to learn C at the same > > time so its very slow > > > > Inline.pm! That is a most cool module! Has anyone used it in a production environment yet? -- Drew Taylor Software Engineer Phone: 617.351.0245 Fax 617.350.3496 OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com
Re: redirecting large POSTs
Kip Cranford wrote: > > I did this because in my system, I routinely need to allow file uploads > of 100MB or more. This is too unwieldy, IMO, to upload, store, > retrieve, etc. So far, this has worked like a charm. Dare I ask what that 100MB consists of? That's a lot of uploaded data... :-) -- Drew Taylor Software Engineer Phone: 617.351.0245 Fax 617.350.3496 OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com
Re: $r->header_only question (feeling a newbie!)
martin langhoff wrote: > > ... it made no difference ... :( > > Drew Taylor wrote: > > I believe all you need to add is "return OK;" after your print > > statement. Without that, Apache doesn't know what the status of the > > request should be. Doh. I missed what Tim caught. I believe Apache will assume an "OK" if you don't explicitly return a status code. Thus your code _should_ work after changing "unless" to "if". Can anyone check what Apache defaults to if no status code is returned? I'm guessing it's "OK". However, I'd still add a return OK after the print. :-) -- Drew Taylor Software Engineer Phone: 617.351.0245 Fax 617.350.3496 OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com
Re: $r->header_only question (feeling a newbie!)
martin langhoff wrote:
>
> hi,
>
> I've been developing with mod_perl for a while, but, thanks to
> Richter's Embperl module and the excellent backwards compatibility
> (regarding CGI.pm) I had never got anywhere near Apache::Request -- for
> production, that is.
>
> Now I have this very silly question, that I've boiled down to this
> little snippet of code (which carries a remakable resemblance to the
> example found in page 146 of the Eagle Book):
> --
> #!/usr/bin/perl -w
> use strict;
> use Apache::Constants qw(:common);
>
> my $r = Apache->request;
> $r->content_type('text/html');
> $r->send_http_header;
>
> return OK unless $r->header_only; # THIS is the line I'm wondering about
>
> $r->print(< Hello !
> martin
> END
> 1;
>
>
>
> The issue is that I don't understand clearly what is this line supposed
> to do. As it is, it'll make my script return an empty body ('document
> contains no data!' said Navigator). Commented out, the proper contents
> are sent. Reading the Eagle and `man Apache::Request` led me to thing
> that the line is there to stop processing if all the client wants are
> the headers (maybe because of a 'If-Modified-Since' parameter?).
I believe all you need to add is "return OK;" after your print
statement. Without that, Apache doesn't know what the status of the
request should be.
--
Drew Taylor
Software Engineer
Phone: 617.351.0245
Fax 617.350.3496
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com
Re: SELECT cacheing
Roger Espel Llima wrote:
>
> I've written a very small module to cache SELECT results from DBI
> requests. The interface looks like:
>
> use SelectCache;
>
> my $db = whatever::get_a_handle();
> my $st = qq{ select this, that ... };
> my $rows = SelectCache::select($db, $st, 180);
>
> this returns an arrayref of rows (like the selectall_arrayref function),
> and caches the result in a file, which gets reused for 180 seconds
> instead of asking the db again.
>
> The names of the cache files are the md5's of the select statement,
> using the last hex digit as a subdirectory name. There's no file
> cleanup function; you can always do that from cron with find.
>
> This is all very simple, but it's pretty useful in combination with
> mod_perl, to speed up things like showing the "latest 10 posts", on
> frequently accessed webpages.
>
> The question now is: is there any interest in releasing this? I could
> write some minimal docs and give it a 'proper' module name, if there's
> interest.
I'm certainly interested. One question though - in the module do you
blindly use the cache? I ask because in my instance I display the
contents of a shopping cart on every page. And while only a few pages
change the cart contents, the cart listing does need to be current. How
do you handle this situation?
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: [OT?] Cross domain cookie/ticket access
Aaron Johnson wrote: > > I am trying to implement a method of allowing access to three separate > servers on three separate domains. > > The goal is to only have to login once and having free movement across > the three protected access domains. > > A cookie can't work due to the limit of a single domain. > > Has anyone out there had to handle this situation? Yes. In the end I decided users would just have to login into each domain seperately as I'm using cookies for authentication/tracking. You just can't do it. :-( Of course, if someone has another idea I'm listening... The only other way around it is at time of login to do what you described - round-robin redirect to each domain. It's ugly, time consuming (for the user), and it generally sucks. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
"G.W. Haywood" wrote: > > Hi all, > > On Tue, 5 Sep 2000, Drew Taylor wrote: > > > > >>>>> "GWH" == G W Haywood <[EMAIL PROTECTED]> writes: > > > GWH> Do you think this one could go off-List now? > > > No; I find it quite useful to help form my own descision on what sort > > > of templating system to use with mod_perl apps. > > I'm also finding it useful. There have been many useful ideas/concepts > > thrown about that I intend to use in the template comparison. > > OK, you win, I'm outvoted. I will say that the topic has greatly veered from the original subject. How about we continue the discussion with appropriate subject lines? At least it will be easier to scan the messages. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Vivek Khera wrote: > > >>>>> "GWH" == G W Haywood <[EMAIL PROTECTED]> writes: > > GWH> Do you think this one could go off-List now? > > No; I find it quite useful to help form my own descision on what sort > of templating system to use with mod_perl apps. I'm also finding it useful. There have been many useful ideas/concepts thrown about that I intend to use in the template comparison. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Nelson Correa de Toledo Ferraz wrote: > > Hi Drew, > > > I'm the one who volunteered, and then I went on vacation for a 2 weeks. > > I have decided I will have a bare minimum draft done within a week. And > > then, as Matt suggested, people can just send > > suggestions/corrections/additions and the document will grow. When I > > have a draft, I'll post it to the list. > > I'm new to this list, and I'd like to make a small contribution to the > HTML Template Comparison Sheet. > > I've been using Text::Template for some time now, and I really enjoy using > it because 1) it's fast, 2) it's small, just 28kb and 3) it uses Perl as > scripting language. Thanks for the intro to Text::Template Nelson. I'll make sure it gets included in the comparison. There is such a WIDE variety of modules available that it would be almost impossible for me to try them all. But I might give it a try anyway. ;-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Matt Sergeant wrote: > > If nobody is working on it, I suggest just getting 1 or 2 paragraph > synopsis from template authors about thier product. Just compile those > together and then let it evolve as people see other people's paragraphs > and think "Hey I should have mentioned X too...". I would happily accept the brief synopsis Matt mentioned above. If I get a few of them, I will combine and post them along with a brief document overview. It would be better than what we have right now. :-) If you do send me a synopsis, please include the major features and try to keep it to a few paragraphs. But I won't exclude anything if it happens to be long. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: HTML Template Comparison Sheet ETA
Matt Sergeant wrote: > > On Tue, 15 Aug 2000, Gunther Birznieks wrote: > > > Is there an ETA on when this will be out? > > > > I know everyone is busy, but I just figured I would ask. There have been > > hundreds of template messages generated in the last weeks on this topic, > > and then it seems to have gone a bit quiet (as usual). > > If nobody is working on it, I suggest just getting 1 or 2 paragraph > synopsis from template authors about thier product. Just compile those > together and then let it evolve as people see other people's paragraphs > and think "Hey I should have mentioned X too...". I'm finally getting through the huge volume of list emails after vacation, so I apologize for the delay in this response. I'm the one who volunteered, and then I went on vacation for a 2 weeks. I have decided I will have a bare minimum draft done within a week. And then, as Matt suggested, people can just send suggestions/corrections/additions and the document will grow. When I have a draft, I'll post it to the list. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Proxy setup w/ SSL
Vivek Khera wrote: > > >>>>> "DT" == Drew Taylor <[EMAIL PROTECTED]> writes: > > DT> What I would like is to add SSL to the frontend servers and ditch > DT> stronghold all together. I'm interested in suggestions for how to do > > Why not just add mod_proxy and mod_rewrite to stronghold, and remove > mod_perl from it. The it is your front end. Since you've already > paid for it, it seems the way to go. Using mod_ssl may pose legal > issues until the RSA patents expire next month. That is an excellent point. My initial thought was based on the fact that I was given the server with Stronghold already compiled w/ mod_perl and I was trying to get around having to recompile Stronghold again. Would it be worthwhile to have a non mod_perl stronghold as the front end for ALL incoming connections (of course having only the necessary domains running SSL) instead of the plain apache I'm running now? In the long run, your solution is the way to go and once I get back from vacation (thank goodness!) I will look into it. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Proxy setup w/ SSL
Everyone, I have successfully setup the proxy system outlined in the guide, and it seems to be working well. In my instance, the front-end httpd has mod_proxy & mod_rewrite, while the backend is only mod_perl. I also have a seperate instance of stronghold/mod_perl for SSL connections. What I would like is to add SSL to the frontend servers and ditch stronghold all together. I'm interested in suggestions for how to do this. Should I try mod_ssl, raven, etc? I am trying to have only 2 servers running instead of three. Does anyone have experience in this area? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: > > I believe XML is a way too heavy for docs writing. Why one will want to > get a messy source code, when you can get away with a minimalistic POD. > Just look at the Guide's source code and look at the generated PDF -- > isn't it great? I love POD. And if you want more than POD provides, it > takes secs to add the new functionality. I agree. XML has a nice "cool" factor, but I want to make this guide as simple as possible. > As for POD, I've already extended the POD in POD2HTML (which was buggy > anyway). For example, I've added new directives for embedding images, > linking to files and more... I don't afraid to extend the POD since I can > easily convert all my extended pod files back into the standard POD > format. So if you want a syntax for tables, this should be easy to add, > like: > > =table args > > =tr args > > =td args > > ... > > =/td > > =/tr > > =/table That might be a useful extension. How do you do tables now? "=for html"? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: logging out
[EMAIL PROTECTED] wrote: > > I used Net::LDAP, a pure Perl implementation, against a Novell eDirectory LDAP > server. > > You can find it at CPAN or at > http://sourceforge.net/project/?group_id=5050 > > I coded the authen_cred method to authenicate against LDAP and then store > the username in the session hash. > > The authen_ses_key method then recovers the username from the session > hash. I remember writing those methods long ago... :-) > I created a custom require method to check group membership so I can > include something like this in httpd.conf : > > require LDAPGroup cn=administrators,ou=groups,o=wl > > I want to extend it to check for container membership too but I don't need > that just now. > > I could send you the code if it would be of interest. That would be great if you don't mind. At least then I would have a starting point. My biggest decision right now is whether to use something like mod_auth_ldap compiled into Apache or to use Apache::AuthCookie with LDAP authentication like you used. Does anyone have experience with either situation? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Gunther Birznieks wrote: > > One book I would highly recommend on CVS is Open Source Development with > CVS by Karl Franz Fogel. I found it to be not only highly informative but > an incredibly fun read as well. Each of the semi-dry CVS chapters is > followed up by a fun anecdotal chapter about open source development > processes and how and why they work (esp focusing if possible on how CVS > helps that process). > > I've also found it to be a better "advanced" reference than any of the CVS > documentation I have. Somehow it just "feels" indexed better. I own no > stock in Coriolis Books by the way. :) I have read most of this book, and I agree that it is very well done. I was a total newbie at CVS, and now I can do everything I need on a daily basis. I still don't understand tags very well, but I haven't studied that part of the book much. > Stas does make the source available to the guide generator. Download the > guide from CPAN and poke around the distribution... :) > > We've been using it to do ALL our extropia documentation for 2 months now > (actually we use a modified older version, and am waiting to get some time > to upgrade since Stas has done many improvements). > > Does this format look familiar (albeit a little old)? > http://www.extropia.com/docs/webdb/ > > It's really awesome. I generate standalone HTML for standalone distribution > of scripts, HTML docs that integrate into the look and feel of our website, > and PDF within seconds each time we make a change. :) Sounds very cool! I like doing several steps at once. I think I'll fire up the old CPAN module later today and grab the latest guide distribution. > >Drew, if this all sounds like too much trouble for the first draft and you > >already started in HTML, I'd say just finish that up and we'll distill it > >into POD later. (html2pod?) > > Could be. Although, HTML is a pain in the ass to add onto anyway. It's a > lot easier to see differences between versions of docs in POD than in HTML > where you have all the formatting tags that interfere with reading diffs. No kidding#!@ :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Perrin Harkins wrote: > > Drew, if this all sounds like too much trouble for the first draft and you > already started in HTML, I'd say just finish that up and we'll distill it > into POD later. (html2pod?) I have no problems learning something new. I know basic POD, and it sounds like the tools are available to do things like the feature checklist. And as luck would have it, I've been swamped this week so I have not written a single word. :-( However, I am planning on banging out a quick outline during lunch today, which I will post on my website (hopefully) this afternoon. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: logging out
[EMAIL PROTECTED] wrote: > > I recommend Apache::AuthCookie. This has worked really well for me, and > allows me to use an HTML form which is much nicer for my users than the > default dialog box. > > FWIW - I sub-classed AuthCookie to authenticate against an LDAP directory > (using Net::LDAP) but you can use a RDBMS just as easily. I have used Apache::AuthCookie also and liked it. What module did you use to authenticate against the LDAP server? We are setting one up here for internal use and I am still trying to find the best (read easiest) way to authenticate against it. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: > > Sure, no problem. One of the current cvs access holders can commit the > first release for you, and then you will be able to continue by > yourself. Obviously getting all the support that you might need on the > way. Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. > I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: > > On Thu, 3 Aug 2000, Perrin Harkins wrote: > > > On Thu, 3 Aug 2000, Drew Taylor wrote: > > > > Gunther, has anyone found a good home for such a comparison to be > > > > hosted? It would be cool if it were at perl.apache.org, or even better > > > > at www.perl.com or something (since it's not mod_perl specific). As > > > > long as it's easily updatable by its maintainers (and who are they?). > > > > > > Excellent question. I was planning to initially host the document on my > > > home page. But I'm sure that wouldn't last for too long. I guess the > > > initial maintainer would be me, but I would have no problem expanding > > > that list in the future. Which brings up the question - how would it be > > > maintained? CVS? I'm all ears... > > > > Let's create a http://sourceforge.net project for it, which will give us > > an instant CVS and mailing list (for people working on the documents), and > > allow everyone to see the work in progress. Once it's together, we can > > figure out how to get onto perl.com and/or perl.apache.org. > > Documentation maintenance is a different process from code maintenance. > I'm telling this on the base of working on the guide in the last 1.5 > years. The maintainer is responsible for keeping the document clean and > consistent. > > Therefore it really makes things better if there is an owner of the > documentation project and people submitting the patches to him or her. > > Drew, once you get an initial doc, we will give you a CVS access to the > modperl-site repository, which is given to all people who do > significant contribution to the project. It shouldn't take a long time. Sounds great. Hopefully I will be able to have a first version out this weekend. I have been slammed at work this week, so I'll most likely be doing the writing on my personal time. I'll post when & where the first draft will be located. After that we can talk CVS. BTW, you probably don't remember me, but we briefly met at ApacheCon and I attended your mod_perl classes there (and enjoyed them). :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Ken Williams wrote: > > [EMAIL PROTECTED] (Gunther Birznieks) wrote: > >I am afraid that while I agree, a check system is really quite useful to > >me. Some things do need more quantification, but that can be done later. > > > >eg lightweight vs heavyweight is subjective. But it can be broken up into > >saying something like how much code needs to be loaded at start time (an > >issue for CGI/Perl). eg I think people would agree that the startup of > >CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of > >course, there are many other features that you get from them that can make > >a difference in your program. > > > >Anyway, that is why this checklist is being designed by all of you and > >handled by an independent 3rd party. It's not a marketing tool. So if you > >complain about session support being a checkbox, I am sure that the feature > >name could be refined. > > I agree. I came up with an initial set of checkboxes (posted here last > week), but I'd have no qualms about some author wanting to ditch some of > those. I think a useful comparison would use feature comparisons only > as a means of revealing the comparitive philosophies of the systems. I think splitting the systems into tiers (simple, average, framework) will also help to solve this problem. And of course, the feature checklist will be a continually evolving creature. > Gunther, has anyone found a good home for such a comparison to be > hosted? It would be cool if it were at perl.apache.org, or even better > at www.perl.com or something (since it's not mod_perl specific). As > long as it's easily updatable by its maintainers (and who are they?). Excellent question. I was planning to initially host the document on my home page. But I'm sure that wouldn't last for too long. I guess the initial maintainer would be me, but I would have no problem expanding that list in the future. Which brings up the question - how would it be maintained? CVS? I'm all ears... -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
"Randal L. Schwartz" wrote: > > >>>>> "Ron" == Ron Pero <[EMAIL PROTECTED]> writes: > > Ron> A few days ago I sent this suggestion to Drew Taylor, who is > Ron> preparing a web page comparing the templating systems. He said he > Ron> likes the idea. The Categorical "Congratulations: you wrote a > Ron> templating system!" web memorial. > > Wow, if making suggestions here gets that kind of immediate results, > let me also suggest I need a girlfriend who is travel-compatible and > email friendly. Maybe one will show up. :) > > Or do you get only one wish per quarter? :) Sorry, it's one wish per _year_. I'm a little slow that way. ;-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Matt Sergeant wrote: > > On Tue, 1 Aug 2000, Drew Taylor wrote: > > > Bill Moseley wrote: > > > > > > It seems as if there needs to be a general templating mailing list... > > > > > > Here I have a comment about comparing template systems, and then I solicit > > > advice on which system to use... > > > > > > > Bill, > > > > After all the response the thread generated, I wonder if perhaps we > > (meaning the people who have control over those things :-) really > > _should_ setup another list. > > Look at the history of this list: it often gets very bursty and the quiet > again. I think setting up a perl-template mailing list would be initially > heavily trafficed, but be pretty much dead in a few weeks (or days even). Oh so true! Hopefully as people put together resources and the URLs are publicized, we can avoid some of the same questions that come up time and time again. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
"Erich L. Markert" wrote: > > Drew Taylor wrote: > > > > Bill Moseley wrote: > > > > > After all the response the thread generated, I wonder if perhaps we > > (meaning the people who have control over those things :-) really > > _should_ setup another list. > > > > I could see the efficacy of a template developers site for those people > involved in the actual development of whatever solution but I think > another list would confusion. Besides, template questions would still > be asked on mod_perl anyway... So true. I do hope to eventually create an entire site dedicated to template developers. But you have to start crawling before you can run. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Bill Moseley wrote: > > It seems as if there needs to be a general templating mailing list... > > Here I have a comment about comparing template systems, and then I solicit > advice on which system to use... > Bill, After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. I will take yours (and everyone else's) thoughts to heart when I'm putting together the comparison document/site. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: template kit.....
"Erich L. Markert" wrote: > > > What I don't understand is *why*. Why can't you use to > > independent pieces of software: one for templates and the other > > for sessions that work perfectly well together (or seperately)? > > > > Paul, > > I don't think anyone (certainly not myself) is suggesting that all other > solutions be done away with - bigger is not always better. However, for > certain types of projects an intergrated solution certainly offers up > more appeal than trying to get all this disparate solutions to work in > unison... > > I know, personally, that my last project(s) would have benefitted > greatly from a integrated perl app server solution - especially if alot > of the underlying technologies can be hidden from the less than > technical folks... I'll throw in my $0.02 and agree with Erich. We have twice as many HTML people as perl programmers. So it was very important to make things as simple as possible for them. The less they have to learn, the better. I like to make my life as simple as possible... So a comprehensive app server would go a LONG way in this regard. I'll also say that I like the idea of plugging in different components (Sessions, templating, etc) I need, when I need them, and where I need them. There is also much to be said for flexibility. Not all our clients will need/want/allow a mod_perl server. Perhaps their situation calls for a $30/month shared hosting solution instead of mod_perl. This is where the plug-in approach works best. We have both types of clients, so choice is good. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating System
brian moseley wrote: > > On Fri, 28 Jul 2000, Drew Taylor wrote: > > > Anything that would make the above scenario easier would > > get a thorough look in future templating system > > decisions. In short, I'm looking for a good, FLEXIBLE > > application framework. I'm tired of writing it all > > myself. And while it has been excellent experience, I > > say build on the backs of other giants. :-) > > hi, just got back from vacation so i haven't weighed in on > this mighty thread yet. Good luck! It's gotten rather huge! :-) > i'm in the midst of porting to perl tomcat, the apache java > servlet engine. specifically, i'm reproducing the internal > architecture of tomcat in perl and providing some glue > modules to implement the internal classes with the apache > api where suitable. i'm also debating whether or not to > recouch relevant and interesting parts of the java servlet > api in perl terms and provide an implementation with the > engine. There are MANY excellent things (I've read) about servelets. Primarily, they handle many of the things this thread has been talking about - sessions (via cookies & URL), caching, etc. I personally am very happy to hear your news. There are so many cool projects in the works, I don't think I'll ever have enough time to properly evaluate them all! > i'd hoped to show the work to a few folks at the conference, > but i had to leave earlier than expected. nevertheless, i > have most of the core features working in a prototype > capacity - pluggable authentication and authorization with a > DBI-based implementation; pluggable session management using > Apache::Session, and a DBI-based implementation; simple and > extensible XML configuration of multiple web applications > inside the servlet engine as well as the engine itself; > pluggable logging (with Apache::Log and syslog > implementations); application control and response output > via 'servlets', and a Mason servlet. Cool! These things are some of the features java folks are always touting when comparing mod_perl to servelets. Keep up the great work. I'm sure many people on the list will be very interested. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating system
Perrin Harkins wrote: > > On Fri, 28 Jul 2000, Drew Taylor wrote: > > Andy Wardley wrote: > > > > > > And the REALLY, REALLY smart ones (i.e. TT2) can write the Perl code to > > > disk for persistance of compiled templates. That way, the templates > > > never need to be re-compiled (i.e. from TT syntax to Perl code) unless > > > you change them. They can simply be loaded via Perl's require(). > > What about having a shared memory cache ala HTML::Template? A disk cache > > is great, but I have RAM to spare at the moment. Any plans for a shared > > in-memory cache? (Someone had pointed out that TT does have in memory > > caching, but it is only per-process.) > > You can't actually share the compiled subs (except through copy-on-write > by loading them in startup.pl), and sharing the generated perl code in > memory rather than on disk is probably not that worth the extra work (or > memory). The key here is that the loading of the perl code from disk into > memory is only done once per process, so the value in optimizing this step > is very small. You learn something new every hour on this list! :-) Thanks. It's not a big issue now anyway since I have a proxy setup with only 12 mod_perl processes anyway. I was just curious. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: was Re: template kit..... - now session handling
Greg Cope wrote: > > I posted about a generic URL mangeler / cookie session handler a few > days ago. > > Allthough this is not rocket science - I've writen a URI transhandler > that will put the session id into pnotes, and if cookies are off will do > a redirect to itself with a munged URL > (www.foo.com/id_here/original_bit_here). A quick uri rewrite and bob's > one of your parents sister. The only major issue is that I cannot > appear to use posted values as they appear to get lost in the redirect > (Clues wanted !). > > It appears that a few other people would want a session handler that can > do this transparent and then they can use Apache::Session to do the > rest. At the risk of sounding like an AOL'er - Me Too! :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Matt Sergeant wrote: > > This is getting too complex. Just do a couple of paragraphs on each, and > let everyone bang it out to a bit more than that. I guarantee that once > one template system designer says "Mine does X", the others will chime in > and say "Well mine can do X too, and optionally Y". Eventually you'll get > the perfect document... True. And it's also the only sane way to do it as well. :-) > However I suggest taking that stage off the list, and just let them send > patches direct to you, and announce when you've got a new version. A-la > guide. In fact it might be a nice addition to the guide. (here I am making > Stas and Eric's book even longer...) If it turns out to be good enough for the guide, I'll be happy to contribute it. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Ken Williams wrote: > > I suggest having not just a simple checkmark, but a 3-way check. A > system either supports a feature, or it doesn't, or it *optionally* > supports it (can be switched on and off). This is often very helpful to > know, and might let one get a good sense of the differences between > various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Gerald Richter wrote: > > > > > Vivek had an excellent suggestion in private email: put together a list > > of features and let the developers check off the options their system > > supports. My biggest question is who comes up with the feature list in > > the first place? > > > I would suggest it the other way round. Put together what you already have > and let the developers correct and complete it. I often had thought about > creating such a comparison, but I don't have the time to do so, but doing a > proof read of what you have created should be possible. OK. I will do that and when I have the first draft done, I will post with a link to the document. I'll just grow and evolve the document(s) as needed. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Gerald Richter wrote: > > > As for summarizing, I have some pretty good info already: a private > > email from a user of embperl, Andy's post of TT, and Joshua pointed me > > to Apache::ASP's website. I'll probably do some serious reading this > > weekend and (hopefully) begin to sketch out the comparison. And yes, > > help is always appreciated. :-) > > > > For Embperl 1.x http://perl.apache.org/embperl/Features.pod.1.html is a good > starting point and for Embperl 2.0 add the things that I wrote in my mail > (search for "preview Embperl 2.0"). Thanks. I have saved the text of the "preview embperl 2.0" post. > If you have put something together, I would be happy to review it, to make > sure things about Embperl are correct. Of course! Having never used embperl, I'd rather go straight to the source. :-) Vivek had an excellent suggestion in private email: put together a list of features and let the developers check off the options their system supports. My biggest question is who comes up with the feature list in the first place? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating System
Perrin, I am about to embark on the same journey you describe below. My initial thoughts were just to highlight features/difference/drawbacks for each of the major templating systems. Have you done any work to date on this project? I would like to begin reseaching each of the systems this weekend. More heads are better than one - are you interested in collaborating? Perrin Harkins wrote: > > One of my goals is to eventually produce a site which will have commentary > and examples of the various templating options for mod_perl (and maybe > java servlets as well). I think it would be helpful to newbies who don't > want to slog through the hundreds of search returns on CPAN. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: The Template Toolkit (Re: Templating Systems)
Andy Wardley wrote: > > I'm the author of the Template Toolkit and I figure it's time for me > to give my take on the whole subject. Here's a collection of my > thoughts which hopefully answer some of the questions that have > arisen. Everything is IMHO, of course, but I like to think that I > know what I'm talking about, having spent some considerable time > working on and with such systems in a professional capacity. But > despite what I think, I'm not always right, so please feel free to > take me to task or ask for clarification if there's something that > doesn't fit. I'm always happy to be proven wrong. :-)= Andy, do you mind if I summarize your post in a template comparison document I hope to create soon? I know I'm not the only one who is almost overwhelmed with the template system choices avaiilable to programmers. > * AxKit is something entirely different, new and icy cool. It's an XML > data engine. I'm hoping to graft TT on to the top of it Real Soon Now. > I've created a mailing list for discussion of AxKit/TT integration > if anyone is interested. See: > > http://www.template-toolkit.org/mailman/listinfo/template-axkit Ahhh, now THAT is what I'm looking forward to!!! I have played with Axkit a little and think the concept is Ultra Cool (tm). I also think TT is Ultra Cool(tm) having just implemented it for a production site. I'll probably be lurking on the above list shortly. :-) > Version 1 is available from > CPAN, while version 2 betas are currently only available from the above > web site. Version 2 beta 2 is 99% stable, and beta 3, due out early next > week, should be rock solid. Once the documentation has caught up with > the code (almost there), I'll be releasing V2 gold and it'll find it's > way onto CPAN. Hurry, hurry! :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating system
Andy Wardley wrote: > > And the REALLY, REALLY smart ones (i.e. TT2) can write the Perl code to > disk for persistance of compiled templates. That way, the templates > never need to be re-compiled (i.e. from TT syntax to Perl code) unless > you change them. They can simply be loaded via Perl's require(). What about having a shared memory cache ala HTML::Template? A disk cache is great, but I have RAM to spare at the moment. Any plans for a shared in-memory cache? (Someone had pointed out that TT does have in memory caching, but it is only per-process.) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Simon, You aren't the only one who was pleasantly surprised to come back to a mailbox overflowing with messages on a topic near & dear to my heart. :-) As for summarizing, I have some pretty good info already: a private email from a user of embperl, Andy's post of TT, and Joshua pointed me to Apache::ASP's website. I'll probably do some serious reading this weekend and (hopefully) begin to sketch out the comparison. And yes, help is always appreciated. :-) [EMAIL PROTECTED] wrote: > > Yes please ! > > I've been following these threads with avid interest as I am just starting > to look at this technology. > > I'm currently using SSI to call mod_perl scripts to handle the dynamic > parts of the pages but this is getting very unwieldy when I start doing > form handling. > > If you would like some help with the comparison, please let me know. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Feature sets [was Re: Templating System]
After all this discussion, what would benefit me most in choosing my next template system would be a concise central repository of the features & benefits for the major template systems (TT, Apache::ASP, Embperl, Mason, & HTML::Template come to mind first). I'd volunteer to help put it together, but I don't know what the above features are. If the principal maintainer(s) for each system could post a short blurb about it, I would be happy to compile them together for use by all. Would anyone else benefit from a template summary? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating System
Joshua Chamas wrote:
>
> I'll be bringing auto formfilling to the Apache::ASP table
> just as soon as I work out the details with other interested
> parties. I'm thinking of some kind of $Response->{FormFill}
> attribute, and possibly a FormFill config setting, to specify
> runtime form filling, then there's that whole ASP+ syntax
> to possibly support as well.
That would be most excellent! I have yet to take more than a cursory
look at Apache::ASP and Embperl, so I don't know what feature set they
offer. I think the thing that is most difficult to currently do in my
modules is the form pre-filling.
In my case, it is imperative to save all input that the user entered,
except for fields incorrectly entered or missing. I currently do it my
grabbing form input, do some basic checking for each group of info, save
it to the DB, and then display either for form again with the
missing/error fields highlighted or show a response.
Anything that would make the above scenario easier would get a thorough
look in future templating system decisions. In short, I'm looking for a
good, FLEXIBLE application framework. I'm tired of writing it all
myself. And while it has been excellent experience, I say build on the
backs of other giants. :-)
I spent the first 1.5 hours today reading all the threads of "templating
system", and it was worth every second. :-) IMHO, the lack of a
"standard" framework is the perl community's biggest drawback. But then
we also have many systems to choose from, so that is a big benefit. As
someone else mentioned, interoperability, even in just it's a most basic
form, would be a major feature.
Oh yeah, and throw in a CMS to boot ;-) Keep up the _excellent_ work
folks.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: Templating System
David Hodgkinson wrote: > > Drew Taylor <[EMAIL PROTECTED]> writes: > > > While I would love to have the session management & form goodies of the > > other template systems, our production people are not ready for it > > (yet). Keep up the excellent work on these other frameworks - I might > > get to use them one day. :-) > > There's no reason why you can't use Apache::Session from within some > code backing a TT script. True. Except for the fact that I have already spent the time to do my own session tracking in my own custom sort of way. :-) I guess what I would like most is a framework that did everything (session management via cookies or URL [automagically], forms prefilling, etc) for me. Having done it myself once, I know that the problem is larger than it sounds and why re-implement the wheel? For this reason, I am very interested in Embperl 2.0 and Apache::ASP. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Seeking advice on excessive memory usage
Joshua Chamas wrote: > > As long as you are loading CGI in your PerlRequire startup.pl > with the compile option, CGI should not be hurting you as > its loaded in the parent httpd. You can also precompile > your CGI scripts with Apache::RegistryLoader for a big win > in processor speed and memory. Finally, I would recommend > running a reverse mod_proxy server even on the same box port 80 > to better leverage your heavy mod_perl processes. These things > are all documented in the guide. As someone who has just implemented the reverse proxy setup for a production site, I can wholeheartedly say, DO IT! I now run about 12 mod_perl processes and about 50 "normal" httpd processes, versus 40+ mod_perl processes which sucked up GOBS of ram. The site runs quite fast, although I have not done any benchmarking with the likes of ab. Remember, mod_proxy is your friend -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating System
Perrin Harkins wrote: > > On Thu, 27 Jul 2000, Erich L. Markert wrote: > > OK, I'm nearing the end of one project so I'm able to take a look at new > > solutions so one question comes to mind. What does the template toolkit > > offer above and beyond HTML::Embperl or some other templating solution? > > Well, keep in mind that TT does not try to provide an entire web > programming framework. It is a templating system only. Neat tricks like > automatic form state in Embperl are not built into it. > > However, it has a very complete syntax for dealing with templating, and is > easy for HTML coders who don't know perl to use. Programming with it is > usually as simple as dumping some data into a structure (which can be as > complex as you nedd it to be) and passing it to TT. The new version is > very fast, and it has a nice plugin framework for adding your own > extensions to it. I'll second that! The biggest reason I went with TT instead of Mason, Embperl, or Apache::ASP is because our HTML production folks don't know perl. However, we could (and did!) educate them on simple logic and looping as available under TT. The benefit to me, the perl programmer writting the modules, was that I had to do MUCH less work in my modules then I had to do using HTML::Template. I could just let the HTML folks figure things out, and TT gave them just enough power to do it. While I would love to have the session management & form goodies of the other template systems, our production people are not ready for it (yet). Keep up the excellent work on these other frameworks - I might get to use them one day. :-) My $0.02. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Templating system
David Hodgkinson wrote: > > Darko Krizic <[EMAIL PROTECTED]> writes: > > > As you know projects must be finished until yesterday. It would be a dream > > if we could share the templates between Enhydra and Perl. The only problem I > > see here is the performance. Enhydra compiles the java and the HTML pages > > and creates methods and a DOM model. Doing this on the fly (for mod_perl) > > would be a big drawback in performance. Maybe there should be some kind of > > precompiling. > > Smart templaters cache templates and results. The REALLY smart ones > compile the templates into perl code and hold them as a reference to > an anonymous sub. > > > The problem with many templating systems is the fact that they invent a new > > language like "$variable" which is usually not displayable in the > > Browser so that the designer and the programmer must work tightly. > > Read Andy Wardley's paper on www.template-toolkit.org. He talks about > its positioning between the programmer and designer. > > For the record, I've just done a by-the-book mod_perl-ed Template > thing and it's very quick. I'll be doing a lot more on deep-purple.com > very soon. As have I. :-) Modifying the existing modules to use Template Toolkit instead of HTML::Template (A great module for simpler tasks than what we were doing) and redoing the whole site (about 25 _very_ dynamic pages) took a month. Of course, we were killing ourselves to make that deadline, but the point is that Template Toolkit is great! I can't wait for version 2 to come out... -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Best book
Matt Sergeant wrote: > > On Tue, 11 Jul 2000, Scott Alexander wrote: > > > I used the eagle book. I have done very well with it. Are there > > really any other books out there on the subject? > > Not on mod_perl, but I wouldn't develop a big system until you've read > Damian Conway's "Object Oriented Perl". > > > Scott > > On 11 Jul 2000, at 10:22, Pramod Sokke wrote: > > > Any ideas on which is the best book available out there for mod_perl? I second that! It has been an invaluable source of information. And it is very readable as well. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Is variable initialization necessary?
Barrie, Thanks for the interesting benchmarks. In my case, I am only initializing to '' or 0 to avoid warnings (I have PerlWarn On). What was most interesting is the hit when you initialize an empty array. I'll probably just continue on my current course, but the numbers are very intriguing. Thanks again. Drew Barrie Slaymaker wrote: > > Drew Taylor wrote: > > > > Does anyone have good evidence either way? > > I don't see how C could ever fail to undef $foo, modulo > bugs in perl. A hell of a lot of code wouldn't work, then. > > My practice is to never init lexicals to undef/(), and only to '' or 0 if > they might be used before being set to a defined value. Can't see any > reason to = () in perl, where it's set to undef. C's a different question, > where you often get randomish values instead of perl's nice clean undef. > > Side note: stay away from the dreaded C idiom > unless you really understand it and really need it. > > Below are some useless benchmarks. The first focuses on the performance of > C, the second is an attempt to put it in perspective. Both > on perl 5.6.0. It's a lot slower to initialize (66%). My take is that > it's a minor hit compared to the other things you're usually doing, unless > you do it in a tight inner loop. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Is variable initialization necessary?
Rodney Broom wrote: > > A couple of points: > 1. I couldn't tell you for sure about performance, but I wouldn't worry too > much. If you are working on a perfessional system, then I'd bet that you have > enough hardware to handle any slight performance hit that might be seen. I know. But I'll soon be to the point where I can start optimizing code. The hardware can take it, but why not eek out a few more RPS? :-) > 2. Lear to use strict (see perldoc strict). Once you have this down, you'll have > everything you need on scoping. It's more difficult to program under strict, but > much safer. > > 3. Further, there are some issues on scoping vars (or rather failing to) when > running under mod_perl. My experience sais to always lexically scope vars, > preferably with my() where applicable. Been there, done that. :-) I no longer consider myself a novice. I was merely curious as to the general concensus. It sounds like all the major CPAN modules initialize to avoid warnings under -w, so I'll keep on my previous course. All in all, it was an interesting discussion - it mostly satisfied my curiosity. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
[OT] Re: Is variable initialization necessary?
Vivek Khera wrote:
>
> >>>>> "DT" == Drew Taylor <[EMAIL PROTECTED]> writes:
>
> DT> My underlying concern is that each time the code is run, I get "clean"
> DT> variables. Every variable is a lexical. If that is enough to guarantee
> DT> emptiness on each run, then initialization is unnecessary (and in fact a
> DT> performance decrease).
>
> If you initialize a variable at its declaration, will that
> initialization happen every time thru or will it be done similarly to
> a BEGIN block? I think that's your real question.
I believe what you said is my question. Can I safely do this?
my @list;
foreach qw(field field2 field3) {
push @list, $_;
}
I'm 99.99% sure snippet this will give me a clean @list each time it is
run.
My next question is: do most of the modules submitted to CPAN initialize
variables? I read Chris' response, and I'm inclined to keep initializing
variables. One day I hope to submit CPAN modules, so is this a good
habit to get into? Sorry for getting so off-topic.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: Is variable initialization necessary?
Vivek Khera wrote: > > >>>>> "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes: > > MS> I doubt you'll find evidence, just some hand waving. If you know what > MS> you're doing, use lexicals and don't worry about initialization. If you > MS> don't know what you're doing, initialize. > > Not to imply that initializing means you don't know what you're doing, > of course. ;-) But of course. ;-) My underlying concern is that each time the code is run, I get "clean" variables. Every variable is a lexical. If that is enough to guarantee emptiness on each run, then initialization is unnecessary (and in fact a performance decrease). -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Is variable initialization necessary?
Here's another topic I've had on my mind lately. I currently try to initialize all vaiables in the definition (my $var = ();) I've read where several I respect, Doug being one :-), initialize variables. Then I've read posts of people comparing the op count from initializtion vs. non-initialization where initialization creates a sizable more percentage of calls. So my question is: Is variable initialization necessary? Is being a lexical enough? To date, I've played it safe. But if I don't have to... then I won't. Does anyone have good evidence either way? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Using handler for index
Eric Cholet wrote: > > > > > > > SetHandler perl-script > > > PerlHandler ModuleName > > > > > Well, seems like I tried that, and then it ALWAYS used that handler. I > > also have other handlers, and I _think_ the setup above overrode the > > others. I'll give it a try again now. OK, I just tried it, and it > > overrode everything else. :-( > > Try Thanks to both of you. I have never used the regular expression part of the directives before. This is exactly what I need. Thanks! -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Using handler for index
Matt Sergeant wrote: > > On Mon, 10 Jul 2000, Drew Taylor wrote: > > > darren chamberlain wrote: > > > > > > Drew Taylor ([EMAIL PROTECTED]) said something to this effect: > > > > Hi all, > > > > > > > > I am using an Apache Handler module to create my home page, using > > > > > > > > > > > > SetHandler perl-script > > > > PerlHandler ModuleName > > > > > > > > > > > > I have DirectoryIndex set to "index.pl index.html", but the Location > > > > directive is not being picked up for the index, so I get the default > > > > directory listing. Is there another solution instead of a RewriteRule to > > > > redirect "/" to "/index.pl"? Any thoughts would be appreciated. > > > > > > Calling /index.pl explicitly works correctly, right? > > Yes, /index.pl works properly. But since it's a "virtual" file, I have > > to just type it in. > > > > > Replacing with a which sets the correct > > > handler for .pl files should do it, and let mod_dir call index.pl itself. > > Well, the thing is "index.pl" really is Base::HomePage::Anystock. What > > I'm really looking for is a way to use a module as the directory index. > > I'm not terribly opposed to using Rewrite, but I'm curious if there is > > an alternative method. > > Yes, use a PerlFixupHandler instead of DirectoryIndex. This use of a fixup > handler is detailed in the Eagle book. Now that's a good thought. I already have a fixup handler to do my browser sniffing. But rather than write another module, I'll probably stick with the two-line RewriteRule. :-) Now I just have to recompile apache on my workstations because I didn't add mod_rewrite the first time... RewriteEngine On RewriteRule ^/$ /index.pl [R,L] -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Using handler for index
Chris Winters wrote: > > This always worked for me: > > > SetHandler perl-script > PerlHandler ModuleName > Well, seems like I tried that, and then it ALWAYS used that handler. I also have other handlers, and I _think_ the setup above overrode the others. I'll give it a try again now. OK, I just tried it, and it overrode everything else. :-( -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Using handler for index
darren chamberlain wrote: > > Drew Taylor ([EMAIL PROTECTED]) said something to this effect: > > Hi all, > > > > I am using an Apache Handler module to create my home page, using > > > > > > SetHandler perl-script > > PerlHandler ModuleName > > > > > > I have DirectoryIndex set to "index.pl index.html", but the Location > > directive is not being picked up for the index, so I get the default > > directory listing. Is there another solution instead of a RewriteRule to > > redirect "/" to "/index.pl"? Any thoughts would be appreciated. > > Calling /index.pl explicitly works correctly, right? Yes, /index.pl works properly. But since it's a "virtual" file, I have to just type it in. > Replacing with a which sets the correct > handler for .pl files should do it, and let mod_dir call index.pl itself. Well, the thing is "index.pl" really is Base::HomePage::Anystock. What I'm really looking for is a way to use a module as the directory index. I'm not terribly opposed to using Rewrite, but I'm curious if there is an alternative method. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Using handler for index
Hi all, I am using an Apache Handler module to create my home page, using SetHandler perl-script PerlHandler ModuleName I have DirectoryIndex set to "index.pl index.html", but the Location directive is not being picked up for the index, so I get the default directory listing. Is there another solution instead of a RewriteRule to redirect "/" to "/index.pl"? Any thoughts would be appreciated. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
