Seeking Advice: Building A Web Store From Scratch

Jesse Stay jesse at
Mon Nov 6 14:45:37 MST 2006

While some of it is pretty messy, I think Interchange has improved
quite a bit of it over the years, and it is easy to grok if you need
different functionality from it.  They have moved more towards an MVC
model over the years.  Their website is, and
it is Perl and/or Mod_Perl-based. uses this right
now.  I know there are some QuickBooks extensions for it as well that
will probably make your accountants happy.


On 11/6/06, Kimball Larsen <kimball at> wrote:
> On Nov 6, 2006, at 2:00 PM, Daniel C. wrote:
> > Why does the language it's written in matter?  I realize I know
> > nothing about your architecture, etc. and I'm giving you the benefit
> > of the doubt here, but it seems like a weak reason to me.
> >
> Your original question was:
> You can't modify something like Zen Cart to make the accountants happy?
> And my response:
> > On 11/6/06, Kimball Larsen <kimball at> wrote:
> >> Zen Cart / OS Commerce and their ilk are lacking several things that
> >> would require major plumbing changes to achieve (notably, that they
> >> are not written in Ruby on Rails - natch), thus I wish to roll my
> >> own.
> Your implication is that I can start with OSCommerce/ZenCart and
> simply modify it to do what I need.  That locks me into PHP.  I have
> decided not to use PHP for this, thus I can't just modify
> OSCommerce.  I would have to re-implement it all in RoR.  This would
> be fine, if I thought OSCommerce offered some best practices.
> My original question is where can I go to find some best practices
> with regards to setting up a Point of Sale solution.  I have done
> extensive work with OSCommerce, and don't feel it really adheres to
> what I consider to be best practices in several areas, not just
> accounting.
> The language of good example software is irrelevant to me - as long
> as I can grok it and learn from it.  It's best practices techniques
> I'm after here.
> (stuff like - at the time of an invoice it is a good idea to take a
> snapshot of all the relevant data, flatten all relationships and
> store it all with the invoice - thus when you later change the items
> offered for sale in your store, you don't have item_id fields in an
> invoice that point to a now non-existant item, but rather have stored
> all the item's details with the invoice.) (of course, it could be
> argued that flattening data is a horrible idea, and you should just
> never delete/modify the stuff you have for sale, but just add new
> inventory items when you wish to change your inventory)
> -- Kimball
> /*
> PLUG:, #utah on
> Unsubscribe:
> Don't fear the penguin.
> */


$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/

More information about the PLUG mailing list