idiotprogrammer has asked for the wisdom of the Perl Monks concerning the following question:

This may be long, and go off in tangents. I dont really know what Im asking...

I have been programming in Perl for 3 years, almost entirely web based applications. I have written things like database browsers, stat apps, dynamic-data driven web sites, etc.

I am never happy with my code. I am probably the sloppiest coder ever, and try as I may I haven't improved. I still struggle with OOP. I have no problems using objects from classes written by others, but I cant write my own. Just when I think Im getting there, I get discouraged again when I try something more difficult.

Currently I am developing a "shopping cart" for some clients. I would like to get it done the right way (am going to use CGI::App). I want to make it as reusable as possible, ie the same Perl code for all users with a config file to tweak the differences for different users. Now, I want to be able to write it and have it be self sufficient. What I mean is, I want it to be like a shrink-wrapped program you may buy at a store. I cant figure out how in Perl. When I sign up a new client, I spend the better part of a day configuring it for the specific user.

Some questions:
I use Sessions stored in a mySQL db. HOw can I build into the cart each users mySQL connection parameters? Can't, obviously. So then what, leave it up to the buyer to figure out all this on install? Well, that doesnt seem good enough. I thought about using my server, and setting up a session table for each client in my db. Doesnt seem right either. Resource heavy? Security issues, etc. (I do have https however).

2) How would you distribute online such a thing? I am correct in assuming Pel cannot be compiled. What Im getting at here is I cant distribute like a install file that does all the setup for a user. IE, Joe gets my Cart App online. He downloads 1 file, uploads to his server, and somehow runs the file which does all the installation (Wow, Im even confusing myself now). So what are the other options? Distribute the source code? Doesnt seem right. Joe wants to sell Piggy Banks online and that is his specialty, he has no tech training and doesnt want to deal with source code and modifying DBI connection parameters and such.

This is a specific example based on what I am currently doing, but in a broader sense I guess I struggle with theoretical issues. Like for the cart, I can't figure out what to put in what packages, ie how to break it up. I cant figure out where to use objects, or OOP here. So I resort to doing it the sloppy way, like everything in one cart.pl file.

Well, I'll stop for now and await some replies. Sorry if I broke any PM etiquette or anything like that.

Thanks, idiotprogrammer

Replies are listed 'Best First'.
Re: developing and distributing perl apps
by rdfield (Priest) on Feb 26, 2004 at 11:15 UTC
    I guess if your customers are not tech savvy they should be using hosted services. Hosted services are generally offered with bundled software installed, usually including (amongst many others) mySQL and Perl (even mod_perl for a price). Just distribute your packages/cgi-scripts bundled up as a PAR and include a database table install script. Easy.

    Oh, and you'll need some way of adding your PAR to the mod_perl configuration. Not too hard.

    And some way of making sure all your applications dependencies are satisfied. Probably very difficult with a hosted service.

    Hmm, how about fully configuring boxes as application specific webservers and shipping the entire package to your customers? Probably not a viable option.

    Or maybe your customer will just use the hosted services freely supplied shopping cart application.

    rdfield

[reply]
      rdfield,

      You can add a PAR file to a mod_perl configuration via the Apache::PAR module. Apache::PAR is written for exactly these kinds of situations.

      Dependency checking is probably best avoided by packaging all dependent modules into the PAR file. If this isn't possible, there are a couple of other ways I think dependency checking could probably also be handled:

      • Make the PAR file an executable with pp and have the main script check dependencies. That way, a user could run the par file to check dependencies, but still install it on mod_perl using Apache::PAR (untested)
      • Using Apache::PAR, add code to the web.conf file in the PAR file using a <PERL></PERL> section which checks dependencies, and prints warnings or errors out as appropriate. Of course, this couldn't check for the existance of Apache, mod_perl, PAR or Apache::PAR, as these are prereqs for loading a web.conf

      Thanks,
      techy

[reply]
        Nathan? Is that you? :)

        Script reload still doesn't happen under Apache 1.3.x on Win32, but the module reload is working fine now. I haven't tested 0.30 under Apache 2.0 yet.

        rdfield

[reply]
Re: developing and distributing perl apps
by bradcathey (Prior) on Feb 26, 2004 at 12:47 UTC
    Your self-deprecating username notwithstanding, you ask some good questions. I've asked them about my own applications. Two things I toyed with: 1) require all users to call the routines from only one server, mine, but this makes any customization problematic. Besides the bandwidth issues, referencing URLs, there are security issues, etc. 2) distributing them in the way you allude to. Bear in mind, a) once they are distributed, because they are not compiled, they become 'open source' (not a bad thing in the current climate of Typo3, and others). Also, there may be formidable support issues because of the variety of hosting platforms and supporting modules, etc.

    I didn't really answer your questions, possibly raised more, but IMHO there are no easy, clear cut paths for what you are trying to do.

    A comment about your introduction: I too wrote Perl apps for 3 years before coming to the monastery. What I had been writing truly was more like duct tape than smart, efficient, safe code. I suggest you put your marketing strategy on the shelf, at least temporarily, spend some time here walking the halls, and the many good practices of coding Perl will be revealed. You may get beat up once-in-a-while, but it's worth it. But since your XP is low, I'd start by re-registering with a different name (though, please be more creative than I was ;^). Good luck.

    —Brad
    "A little yeast leavens the whole dough."
[reply]
Re: developing and distributing perl apps
by Ctrl-z (Friar) on Feb 26, 2004 at 15:19 UTC
    This is a specific example based on what I am currently doing, but in a broader sense I guess I struggle with theoretical issues. Like for the cart, I can't figure out what to put in what packages, ie how to break it up. I cant figure out where to use objects, or OOP here. So I resort to doing it the sloppy way, like everything in one cart.pl file.

    unless your planning on discovering OOP principles yourself, id highly recommend investing in some good old fashioned bookage. Theres even a perl flavoured introduction.
    Downloading and playing with the Java SDK would probably help a lot too. No DWIM shortcuts there ;-)

    good luck



    time was, I could move my arms like a bird and...
[reply]
Re: developing and distributing perl apps
by Popcorn Dave (Abbot) on Feb 26, 2004 at 18:30 UTC
    A quick Google search revealed this project on FreshMeat with a Perl/MySQL shopping cart. You might want to check that out to see what was done, and how it was done, just to hopefully save you the pitfalls if you're doing this yourself from scratch.

    There is another one I've seen on the web that is open source that I was playing with a while back but I can't find it at the moment. That one clocked in at about 3000 lines of Perl code and I was going to have to make modifications to make it work for me.

    Do realize that with any shopping cart, if you're doing US sales, you have multiple sales tax rates to deal within the country and sometimes within states. California itself has sales tax rates by county. You're also going to have to probably figure out your own shipping charges routines.

    Hope that helps!

    Update: I finally found the link to the shopping cart I had looked at. It's www.perlshop.org

    There is no emoticon for what I'm feeling now.

[reply]
Re: developing and distributing perl apps
by tbone1 (Monsignor) on Feb 26, 2004 at 13:11 UTC

    I am correct in assuming Pel cannot be compiled.

    Hm, I thought you could use the '-u' switch with 'undump' can be used to create a platform-specific executable.

    Or do I need to upgrade our Sun boxes at work to 5.8?

    --
    tbone1, YAPS (Yet Another Perl Schlub)
    And remember, if he succeeds, so what.
    - Chick McGee

[reply]
      the -u option is to dump the core after parsing.

      There are a handful of different ways to compile perl into an executable, depending on what platform you are on, what you're willing to spend, and what you need. I use ActiveState's PerlDevKit, but my work paid for it.

      - - arden.

[reply]

Back to Seekers of Perl Wisdom