Given it's going to be awhile before we get the new version, I can't sit still any more. THe past 10 days have been torture enough.
I'm going to get started on this, and work on the central features, in stand-alone code segments, without modifications to anything but the Links SQL templates.
I have some of the code done, but I need to know what core features people would want in the cart, and how you'd like it to work with Links.
I will have a "Shopping Cart/Catalog Only" version, which Links SQL _is_ the catalog/cart, and one that hooks into the Links SQL you might be running on your site, with the addtion of a few extra table fields and some template tags.
What I would _really_ like to see, is someone working on a Book/CD/Video add on, to integrate Amazon & Barnes&Nobles & Reel.com into the program. Amazon should be fairly easy, B&N has tried to make it easy, and Reel.com I haven't a clue. This would be a separate thread, and there is plenty of room for a group project on this. THere are many aspects -- from searching, to creating targeted book links (like a spider, but for books only), etc.
But, back to the shopping cart.
I'm going to _assume_ (Felix Unger not withstanding) to figure the user-sessions features are going to be in the next version of LInks, and will be accessible to other programs. So, no user-logon, session tracking, or other features are going to worked on at this point.
Also, I'm going to make the assumption that certain user data will be entered in the primary user-logon, so a user hsa one ID/pw for the entire site.
The final assumption is that I'm not going to use cookies for anything except ID and session data. Everything else will be stored in sessions tables (this will be worked out later). I don't want any arbitrary limit on data, _AND_ most importantly, I would like an aborted session to persist to the next log-on, or for some pre-determined time. (A user would be advised a previous shopping session exists, and they can either resume, or start a new one.) (remember, if everything is ID/PW coded, "session data" is only necessry for time-tracking and current "state" information, everything else is stored as a "session record" in the "Sessions" table). This can lead to "wish lists" and persistant carts, since does anyone really want to lose ANY sale??
The "User_extra" table will contain data for those users who chose to purchase from thes ite -- such as full address, billing, shipping, and credit card or other payment info. This table is not set, will be linked by the UserID to the rest of the site, and can have extra fields added to it, as long as certain "required" ones are left alone.
The "Transaction" table will contain the UserID, order_num and a few other fields necessary for order tracking.
The "Ordered_Items" will be linked to the "Transaction" table via the order_num
and will contain the line-items for each item ordered. They will be linked to the Transactions table via the order_num (to use the UserID would violate rules of 'normalizing' but might add extra functionality, so I'm not sure).
The "Ordered_Items" will contain the Item_Num and extra fields to override any of the information in the "Item" record. Why? Let's say you want to apply discounts, sale prices, etc to _some_ people -- (perhaps a members discount on an item). You can enter this, and the PROGRAM code can set the price in the Transaction record, without having to affect the "Item" record at all. If there are no override pricings then the "default" data is entered in the fields. (Why? Lets say you change the prices of the Item in the database. Some programs might force you to enter a new Item number for that in order to allow proper recording of old transactions. If this information is recorded in the record, then the "Item" table can change, without any effects.) (If you change the description or anything else that isn't tracked, you will be presented with an option to enter a new Item_Num or keep the old one, with a warning that previously entered orders may become inaccurate.). This seems to be the best way to handle this, but I'm open.
I haven't worked out the override system, but it seems to me the best would be to use a system of something like Item_ID/Key_to_apply_Discount/discount. That way, when someone orders an item, the PROGRAM checks the "overrides" table, and sees if that Item &/or User is eligible for any discounts. (This is for a LINE-ITEM discount. Any "group" discounts are applied at the end -- such as 10% off for being a "Member".) This is for "special" discounts, sale prices, etc. Each override would have a UNIQUE number, and (you could copy them, if you wanted to change it but) every time you changed the override (or sale price, or discount, etc) you had to create a new override record. This would allow multiple overrides, expirations, etc, and allow you to change an override at any time. Obviously, each override would have a date_start and date_stop. (For performance reasons, expired overrides, deleted items, etc would be moved to "expired" tables, for secondary look up if necessary. The "purge" features of this have not been worked out yet, but the catalog has to be working and running before anything needs to be purged, so I guess I have time <G>)
Then there is the "Item" table, which is the equivalent of the "Links" table, and a "Categories" table, that is the same as the "Categories".
I'll try to allow internal alt-link and alt-categories at a later time, but this version is not going to have that.
This covers most of the "variable" tables. I'd like to know what sort of data you want to be tracked in these tables, since some of it can be made part of the defaults, other parts you'll have to modify on your own.
There will be other tables, hopefully from 3rd party sources, to keep updated on shipping, tax, and other rates. I'm looking for sources now. Nothing is set. I'm _not_ going to try to make this some super impressive stand-alone program, but a basic functional program to solve a specific problem for "average" websites.
I'm working from my own needs of a way to set up one-of-a-kind and inventory items, in an easy to use and integrate way. Template based, automatically generated. Order handling -- MC/Visa/etc. USPS and UPS or FedEx. I'm not going to try to support everyone, or everything. I can't, and I have no delusions of trying :)
If anyone has good open-source products they've found for any parts of this, please let me know. I know there are transaction gateways and modules being worked on, and I will wait for those to get developed. You still need to have your own merchant accounts, etc. But this program will _HOPEFULLY_ be able to pass the data to any of them that you want to. If your ISP offers transaction processing, hopefully it will be an easy mod to send the order data to them for processing, and get it back (getting it back depends on them, more than anything else, sending it can be faked in any number of ways.).
Anyway, this is the start.
(I'm not working on the banner or other systems that are going to be in any way part of the new Links SQL. Once it's released, I'll be happy to hack on them :))
Oh... the final word. YES - this probably could be done in PHP, and maybe even more easily and with a lower overhead than perl, since it's 99% database look up. The _problem_ is that you'd have to develop a new set of templates and template parser to allow the "look and feel" of your main site to be carried through the catalog. By using PERL and DBSQL.pm, and HTML_Templates.pm, etc, the look & feel is maintained very easily. You also couldn't have built-in automatic maintennance features (cron). Additionally, the new release of LinkSQL promises cross-product integration that allows whole-site development with one set of logic for email, spider, links, and whatever else is in the works. I'd rather stick with that. If anyone wants to develop a PHP version that works with this version, feel free. I'm going to stick with perl at least for now.
http://www.postcards.com FAQ:
http://www.postcards.com/FAQ/LinkSQL/