Okay - things are better. When the DOS more command is removed from the equation, the script processes the entire file fairly quickly.
One thing still bothers me.
Lazy type that I am, I didn't bother to find out how to represent that mashed-together AE symbol; I just built a check to see if the first character of the line is nonword (\W in the regex) and if it is, replace it with Ae.
That's just sloppy. If they ever make a card called @#&*ing Bastards (say, in the next Unglued expansion), then I'll be shown for the fraud I am.
Until then, I'll keep programming.
Other than that, I've got how it's going to be laid out in the file all set up.
I realized that all this complex crap boils down to essentially three things - card name, card cost, and how many of the card is there to be bought. Then it occurred to me:
"All of that can be compiled in pre-site scripts."
It should help make the CGI fast, if all it's got to do is strip three values out and slap a little bit of table this, table that around it. That, of course, plus build and access their cart file.
Drew it all out on my whiteboard, which I'm really getting used to now. Just have to implement it now.
Still got ice cream, but I'm all out of Swiss Cake rolls, all out of Dew as well. Nice fresh coffee though.
(This isn't a food review, self...let it go. Drink your coffee and eat your ice cream and CODE.)
Oh, another little decision: The inventory file will only get updated when the compile goes through. I'm presuming this guy is going to want to do the price updates at least every two or three days, so that shouldn't be a problem. (He wants to make sure nobody buys out some of the faster-selling cards all at once, so this should serve that purpose admirably.)
This whole thing is going with a physical model of inventory. That is, when someone puts something in their cart file, it gets *decremented* in the stock file. Like it's physically in a 'cart'.
I realize that may sound stupid, but there's actually a good reason. The inventory for the website is the inventory for the shop; when there's a physical store, this system will use the same file to act as a cash register of sorts. The only real downside is the lack of physical security; he's going to have to trust the people running the register with his life, because they could just take what they want and there'd be no tracking of the money. (I am literally assuming that he'll be working out of a cash box at first, as he is assuming as well. It's slipshod but it will work, I think.)
Times like this remind me of something from _Farscape_.
"You're learning more slowly than the dumbest recruit."
"Yeah, but I *am* learning."
I'm yawning, so I better hurry.
It occurs to me that I'll probably collapse some, perhaps all, of these programs together; that way, there's less "whaddaya mean, I ran it in the wrong order and now we don't have enough stock" style problems that could crop up. If it all just gets fed into 'pricer.pl' and comes out the other end ready and clean, good, one program would simplify things.
That's future work, though. For now, if it works, it works.
