I've started work on a new project, a first step to the shopping system. I find it easier to do things in pieces, rather than try to do it all at once, and an auction program is perfect for that. Different functions are just that, different functions, and it will give a chance to get familiar to the Links SQL new logic.
Right now, I'm using a full copy of links, and modifying from the outset. So, before anyone gets too excited, that means it may require a full Links SQL license to run.
If you analyze Links, it does many things just like an auction program. After all, the big auctions are just a front end to a database. Each item is a unique object, and unrelated to anything but it's parent category. Categories are exactly the same as in links. The only difference is that the Detailed page is a part of the "link" and is the ultimate object.
Detail pages can be built static, and a dynamic header pre-pended to the output, or they can be built completely dynamicly. There are slight benefits to each method. If the static portion is kept in a "user" directory, accessed by 'UserID/ItemID.html' then you 1) over come directory limits on large numbers of files, and 2) you allow the user to keep a certain number of these stock files on their disk, in a workspace, to allow them to re-list common items, with a single click(advanced feature and 3) you take some real-time load off the parser since it just "includes" the item file and you can exempt that field from parsing. As I said, there are benefits to each system -- the dynamic system stores everything in the database, and eliminates any disk storage, but it puts more load on the server and server connections (which if you are on the same machine may not make a difference, but with a remote server, might make a difference).
Anyway, the following is a list of functions I visualize users will need, I added the admin and config options just to show I was thinking about them :) The first clumn is the function name, the "value" is the description of the function, and the stuff behind the ### is what the function expects.
All functions expect a User to be logged on, and will require that before doing anything that requires a User_ID. In most functions the {User_ID} being passed, is the QUERY ID, not the current user, which is always obtained from the logon cookie, never passed in.
config => "Board configuration Options, admin only",
add_item => "Add an item to the auction" ## form based, multiple
ask_seller => "Ask the seller a question", ## {seller_ID, Item_ID, User_ID}
change_reg => "Change registration information", ##
change_pass => "Change password", ##
change_email => "Change Email address", ## requires re-validation
contact_memb => "Contact another member in the system", ## {User_ID}
display_cat => "Displays a detailed category tree/list", ## {Categor_ID}
display_item => "Display an item", ## {Item_ID}
display_list => "Display items in a category", ## {category_ID, Next}
display_closed => "Display closed items, historical information", ## any search parameters
display_closing => "Display a list of items closing", ## any search parameters
display_going => "Display items closing in x-time", ## {Category, Time, Day}
display_hot => "Display items flagged as "hot"", ##
display_new => "Display New items", ## {Date}
display_seller => "Display a list of a Sellers Items", ## {User_ID}
display_bidder => "Display a list of a bidders Items", ## {User_ID}
edit_item => "Edit an item you have for bid", ## {item_ID}
feedback => "View or add feedback to a user", ## {User_ID}
help => "Help system, context sensitive", ## {Context_Tag}
join => "Join system", ##
lost_pass => "Send a new password to a user", ## or present "question"
place_bid => "Bid on an item", ## {Item_ID, BidAmount, User_ID}
view_seller => "View a sellers profile info", ## {User_ID}
view_bidder => "View a bidders profile info", ## {User_ID}
view_feedback => "view a users feedback", ## {User_ID}
view_bid_hx => "View an items bid history", ## {Item_ID}
view_similar => "View similar items", ## ?? fuzzy search, related keywords?
view_U2U => "View all transactions between two users", ## {User_ID_1, User_ID_2}.
Distinction between "view" and "display" is very blurry. But, in brief,
display is a non-registered user call, and view requires logon.
As you can see, most of the above calls are a simple "SELECT" statement, wrapped
up in a display routine.
The only routines that are complicated are the place bid, since some calculations
and timing are required. Everything else is a query/response type action.
It would even be possible to provide a "my auctions" feature, simply by extending the user profile to hold a few options, then passing those options to a program that does a few "select" statements and passes them back to the "my_user.html" template.
Granted, I am not talking about a high-traffic system, since it's all PERL and lots of templates, but it should handle a reasonable volume. The biggest improvement would be in how well MySQL caches queries, so that repeated requests for an unchanged record come out of a cache, rather than a disk access (for example, someone hitting the refresh button every 5 seconds). The time update occurs after a record is retrieved, just before output, so that would be unaffected by an unchanged (or even changed) database record. The output always reflects the current time offset.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
Right now, I'm using a full copy of links, and modifying from the outset. So, before anyone gets too excited, that means it may require a full Links SQL license to run.
If you analyze Links, it does many things just like an auction program. After all, the big auctions are just a front end to a database. Each item is a unique object, and unrelated to anything but it's parent category. Categories are exactly the same as in links. The only difference is that the Detailed page is a part of the "link" and is the ultimate object.
Detail pages can be built static, and a dynamic header pre-pended to the output, or they can be built completely dynamicly. There are slight benefits to each method. If the static portion is kept in a "user" directory, accessed by 'UserID/ItemID.html' then you 1) over come directory limits on large numbers of files, and 2) you allow the user to keep a certain number of these stock files on their disk, in a workspace, to allow them to re-list common items, with a single click(advanced feature and 3) you take some real-time load off the parser since it just "includes" the item file and you can exempt that field from parsing. As I said, there are benefits to each system -- the dynamic system stores everything in the database, and eliminates any disk storage, but it puts more load on the server and server connections (which if you are on the same machine may not make a difference, but with a remote server, might make a difference).
Anyway, the following is a list of functions I visualize users will need, I added the admin and config options just to show I was thinking about them :) The first clumn is the function name, the "value" is the description of the function, and the stuff behind the ### is what the function expects.
All functions expect a User to be logged on, and will require that before doing anything that requires a User_ID. In most functions the {User_ID} being passed, is the QUERY ID, not the current user, which is always obtained from the logon cookie, never passed in.
Code:
admin => "Admin Menu Options, Board Configuration, etc", config => "Board configuration Options, admin only",
add_item => "Add an item to the auction" ## form based, multiple
ask_seller => "Ask the seller a question", ## {seller_ID, Item_ID, User_ID}
change_reg => "Change registration information", ##
change_pass => "Change password", ##
change_email => "Change Email address", ## requires re-validation
contact_memb => "Contact another member in the system", ## {User_ID}
display_cat => "Displays a detailed category tree/list", ## {Categor_ID}
display_item => "Display an item", ## {Item_ID}
display_list => "Display items in a category", ## {category_ID, Next}
display_closed => "Display closed items, historical information", ## any search parameters
display_closing => "Display a list of items closing", ## any search parameters
display_going => "Display items closing in x-time", ## {Category, Time, Day}
display_hot => "Display items flagged as "hot"", ##
display_new => "Display New items", ## {Date}
display_seller => "Display a list of a Sellers Items", ## {User_ID}
display_bidder => "Display a list of a bidders Items", ## {User_ID}
edit_item => "Edit an item you have for bid", ## {item_ID}
feedback => "View or add feedback to a user", ## {User_ID}
help => "Help system, context sensitive", ## {Context_Tag}
join => "Join system", ##
lost_pass => "Send a new password to a user", ## or present "question"
place_bid => "Bid on an item", ## {Item_ID, BidAmount, User_ID}
view_seller => "View a sellers profile info", ## {User_ID}
view_bidder => "View a bidders profile info", ## {User_ID}
view_feedback => "view a users feedback", ## {User_ID}
view_bid_hx => "View an items bid history", ## {Item_ID}
view_similar => "View similar items", ## ?? fuzzy search, related keywords?
view_U2U => "View all transactions between two users", ## {User_ID_1, User_ID_2}
Distinction between "view" and "display" is very blurry. But, in brief,
display is a non-registered user call, and view requires logon.
As you can see, most of the above calls are a simple "SELECT" statement, wrapped
up in a display routine.
The only routines that are complicated are the place bid, since some calculations
and timing are required. Everything else is a query/response type action.
It would even be possible to provide a "my auctions" feature, simply by extending the user profile to hold a few options, then passing those options to a program that does a few "select" statements and passes them back to the "my_user.html" template.
Granted, I am not talking about a high-traffic system, since it's all PERL and lots of templates, but it should handle a reasonable volume. The biggest improvement would be in how well MySQL caches queries, so that repeated requests for an unchanged record come out of a cache, rather than a disk access (for example, someone hitting the refresh button every 5 seconds). The time update occurs after a record is retrieved, just before output, so that would be unaffected by an unchanged (or even changed) database record. The output always reflects the current time offset.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
Links SQL as Auction Site (plug-in ??)