Stephen Howard wrote:
The short answer is you can just include whatever modules you want to use from CPAN in the distribution right along with your script, provided they are Pure Perl modules that don't require compilation (with a little work you could probably figure out how to include binaries for a given program for XS modules). They can be uploaded to the user's account and be useful without needing to have them installed in the standard location. You just then have to write a 'use lib' statement at the top of the scripts you are developing. Besides, as the developer, wouldn't _you_ rather be the person who decides which libraries you build from rather than a community decision?
-Stephen
franki wrote:
Hi guys,
I don't post much here, but I read everything, and have found much of the recent discussions of particular interest.
What I have been looking for is to be able to do with Perl what can be simply done in PHP. (albiet much uglier with PHP)
The apps I write hardly ever end up running on a server under my control, for those that are, I have no problems installing modules etc, but that's not always an option. And some clients get upset when you tell them they should move their site to a "real host".
What I'd like to see, is a complete package containing everything a web application could need, session management, password validation, templating, something like validateRM and so on, all in stand alone package that can be included with my scripts and added to @INC with "use lib".
Asking hosts to install half a dozen modules has been getting painful of late, and the associated pain of talking them (the script owners) though the install is a big time waster as well.
I understand the love of choice for Perl guru's and thats great, but what Perl needs to compete with the growing number of app platforms in particular PHP, (which for all its downsides, is easy enough and inclusive enough for anyone to pick up and run with.)
To be honest, most of the time I don't much care about choice in (for example) a templating system, if the one included does the job, I'll get used to it. Ditto session management, form validation and so on. I want to get the job out as quickly as possible and with as little effort for me, (and the new owners of said script) as possible.
If I've learned anything over the years, it's that choice scares newbies.. that's one of the reasons that PHP is so popular, you don't get a huge amount of choice.. there is a predefined "way" to do most things. (I know that there are several different app fameworks for PHP, but for most things, you don't really even need one.) the end result may be ugly from a coding perspective, but it works and thats what gets newbies learning PHP.
I have to write PHP code allot, but given the choice, I'd not piss on it if it was on fire.. give me Perl anyday.. To that end, I've written my own module of commonly used code containing my own basic templating system, session management, authentication and so on...
And all my scripts that are not based on CGI::App have a strongly structured layout which serves many of the same purposes as CGI::App does.
But all of those are much simplier then the stand alone modules like CGI::Session, HTML::Template and so on..
I'd love to see a release of some sort where all of the individual modules are packaged together as a standalone that can be used with a unified integrated inferface and that can just be dumped into a library directory in the cgi-bin (or wherever) without normal module installation add to @INC with use lib and then just "use" it.
For my own projects, I'd probably keep using the CGI::app system as I've learned it here over the past year or so, but for client installs where you don't know what server an app will end up running on, I'd use this new setup.
Does anyone know of such a system ? If not, I'll probably continue developing my library module for such projects and perhaps incorporate some of the design aspects of CGI::App into it.
It goes against most of what I believe with regards to programming, but for the real world purposes I face every day, it would save me time and I'd end up making more money.
To give something of an example of one of the problems I've had recently is a MIME lib, I had a script that needed to be installed by a heap of different users, many of whom had no experiance installing scripts, and onto many different servers. My initial solution involved the users installing Mime::Lite or Mail::Sender, but both of those modules have other requirements and nearly all the users complained about it.
There is no GPL library for Perl that I could find that can send Mime multipart e-mails that doesn't rely on base64 or QuotedPrint or something similiar, and can be installed by a user without shell access on the server. As a result I waste ages talking users though installs and the users are not happy about it either.
I'd love to be able to tell them to just get a real host, or something of that nature, but when it costs me money to do so, I become alittle more open minded. As a result, I'm going to have to write my own standalone MIME module, or build on an existing one to make it standalone. (I'm not the only person that's felt that pain before, as there is a commerical Perl library that does it already.)
In another mailing list, I've had a minor arguement with Randal Schwartz about this, he is off the opinion that the users should be told to get a real host, and any that can't live with that can essentially go to hell. Which is a fair enough opinion, but one that takes money from my pocket and puts it into someone elses. One of the things I find most ironic, is that in this respect, Perl has gone backwards since perl4, where anyone could just require cgi-lib.pl type libraries into scripts and just run with it. Now we need to install half a dozen modules and such to get the same functionality (It is getting better now that most of the modules needed are now core, but not every host runs 5.6 or above.). Perl seems to be going back to it's beginnings, as a Sys admins tool, or a tool for the root user. That eliminates much of the target audience and is why PHP gets so much more press then Perl. Like I said, an elitist attitude is great, until it costs you money, then it isn't worth it anymore. (before someone tells me that you can install modules as a user, I am aware of that, but I hate talking unexperianced users though that process, and they don't always have shell access. (in fact they usually don't.) Not all hosts run mainframes with thousands of Linux/unix images that they can hand out to clients.
What do you guys do in cases like this? or better yet, what are your opinions?
Rgds
Franki
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
