Hi,

Someone awhile back asked about pure perl shopping carts. I mentioned Perlshop because the code was simple and it was fast.

To "cut to the chase" go to http://zentara.net/store and test the sample store and administrator. Details below. You can download it if you want.

Use it if you want, improve on it, email me questions if you need help setting it up. My sample store dosn't have a secure server available, but the code works with a Secure Server if available.

My goal is to make a general purpose small scale store for farms or small home businesses.

This is not an "Enterprise Level" ecommerce solution, but more of a "mom and pop online store". But it would suit the needs of a small operation.

Before I even knew the difference between $ and @, I setup my first store with Perlshop. It is an older store, that used ReadParse, but otherwise worked nice. All these new stores coming along are so complex, that I always liked Perlshop better, because I could understand the code and modify it to my liking. Also, it had a very nice method of generating a SHA1 page key.

As my "pet project" to teach myself some Perl, I have improved the old Perlshop(which is GPL'd), and added an administrator.

My improvements:

Have fun,
zentara

Edited ~Mon Apr 15 04:31:06 2002, by footpad: Fixed HREF and revised formatting.

Replies are listed 'Best First'.
Re: Perlshop-z Perl Shopping Cart
by gav^ (Curate) on Apr 14, 2002 at 22:50 UTC
    Having a quick skim through the code for perlshop I think it is something best thrown away. The code is badly written, not very modular or extensible, and embeds HTML (meaning less flexibility).

    Personally I don't think a "mom and pop online store" should be using such a system, when something like Yahoo Store (or one of their competitors such as CatalogCity) is more cost effective, secure, easy to administer and more importantly brings a lot of business your way.

    gav^

[reply]
      While I agree with you on the issue of who should be using it (semi-skilled administrators would be better, unless mom or pop gets into Perl), I don't think the code should be thrown out. I'm with Joel Spokain (sp?) about code refactorisation. From my own quick skim through the code, there's nothing there that is wrong, just a few things that could be done more neatly.

      Also, flexibility is desirable in code design, but it's not everything. There's nothing wrong with making a program that does one thing well, but is difficult to adapt. As long as it fills your purpose, it's OK. And since it's open source it should be easy to port the database to abother product, should the time ever come.

      The really important point is that someone actually did the work, and released the code. After that, anyone who feels that the code lacks something can walk in and improve it. In fact, by open source community tradition, you just volunteered to implement the changes you suggested :)

      Getting back to the point, I have in the past, had to go back through and refactor my own code to remove HTML. It's a big task, and boring, but I'm glad I did it that way, rather than throw out the code.

      ____________________
      Jeremy
      I didn't believe in evil until I dated it.

[reply]
        With something like this, my thoughts are that starting from scratch with a set of requirements and building towards them would be a better use of time than refactoring.

        That would also allow you to break things up into a set of achievable subgoals rather than having to work on a complex 3000 line (and in my opinion badly written) script.

        Of course I'm not going to do either :) but if you wanted to learn perl well, I'd steer towards the former.

        gav^

[reply]
[reply]

Back to Meditations