I've got about half of it done. Half the work is in designing the database, the logic flow, and then developing the add_item and place_bid code. 90% of that is done. The templates for that took at least 2x as long as the code! <sigh>
Anyway, I think I may have to yeild to CSS for template design, since basic HTML seems to be lacking the grain to fit so much on the screen as needed. Everything has changed, to where the "style/CSS" tags are preferred over the HTML tags and way things have been done (tables, transparent spacer gifs, etc).
I may have a demo site working in about a week. It depends on numerous factors, including whether the beta comes out (since getting that working is my first priority).
Once that happens, I may need people who are interested in trying it out. Unfortunately, as I indicated before, this incarnation will take a full install of Links SQL to run. Hopefully, as I learn more about the structure and logic flow, this will become an add-on as well. Because this program uses all external scripts, and by nature _must_ be dynamic, it uses the GT libraries, but not the CGI, which makes it an add-on, from what I understand. _BUT_ right now, certain limitations in my understanding of the logic/hierarchy of Links SQL NG are relying on the default behaviour of the triad of Links/CatLinks/Category tables.
Because this is geared to small or medium sites, of a targeted or niche nature, while I worry about efficiency, I'm not worrying about problems due to high-load or multiple "snipes". The default behaviour of the program will be to extend the end-time 5 minutes after the last bid.
Because of this, many, many additional features can be made available, and increase the value and informative nature of the auction site. Virtually _nothing_ is unable to be put into the database, or gotten out of it.
Because of the extended close, and _NO_ATTEMPT_ to play in the big leagues, you can customize the display template to show any type of relations, and allow users to generate any sort of search or display options you would like.
Most of the big places don't let you search and get auctions sold by User1 to User2 or all of User2's auctions from User1. They don't let the user customize their output display or their "my page" to their liking. All this is possible with replacable parameters or targeted scripts. It's _your_ database, and a familiar output, so there are _no_restrictions.
By separating the user-interface development from the underlying engine, you can maintain the same engine, and look/feel across your site, while adding features to it that you or your users may want.
When I say I'm targeting this at smaller sites, the auction program has essentially unlimited capability to hold categories or items, but it will suffer from system performance issues related to it's pure-perl nature and high-level design. It will not perform in milli-second type situations, but I'm not designing it for that. Brick and morter auction houses never ended bidding at "3:05:33". As long as there was a hand raised, the bidding continued.
Basically, this disclaimer is the "dose of reality". Don't expect to run an eBay off this. An Amazon... maybe. :) It's a high-content, medium traffic type of solution -- for the rest of us :)
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
Anyway, I think I may have to yeild to CSS for template design, since basic HTML seems to be lacking the grain to fit so much on the screen as needed. Everything has changed, to where the "style/CSS" tags are preferred over the HTML tags and way things have been done (tables, transparent spacer gifs, etc).
I may have a demo site working in about a week. It depends on numerous factors, including whether the beta comes out (since getting that working is my first priority).
Once that happens, I may need people who are interested in trying it out. Unfortunately, as I indicated before, this incarnation will take a full install of Links SQL to run. Hopefully, as I learn more about the structure and logic flow, this will become an add-on as well. Because this program uses all external scripts, and by nature _must_ be dynamic, it uses the GT libraries, but not the CGI, which makes it an add-on, from what I understand. _BUT_ right now, certain limitations in my understanding of the logic/hierarchy of Links SQL NG are relying on the default behaviour of the triad of Links/CatLinks/Category tables.
Because this is geared to small or medium sites, of a targeted or niche nature, while I worry about efficiency, I'm not worrying about problems due to high-load or multiple "snipes". The default behaviour of the program will be to extend the end-time 5 minutes after the last bid.
Because of this, many, many additional features can be made available, and increase the value and informative nature of the auction site. Virtually _nothing_ is unable to be put into the database, or gotten out of it.
Because of the extended close, and _NO_ATTEMPT_ to play in the big leagues, you can customize the display template to show any type of relations, and allow users to generate any sort of search or display options you would like.
Most of the big places don't let you search and get auctions sold by User1 to User2 or all of User2's auctions from User1. They don't let the user customize their output display or their "my page" to their liking. All this is possible with replacable parameters or targeted scripts. It's _your_ database, and a familiar output, so there are _no_restrictions.
By separating the user-interface development from the underlying engine, you can maintain the same engine, and look/feel across your site, while adding features to it that you or your users may want.
When I say I'm targeting this at smaller sites, the auction program has essentially unlimited capability to hold categories or items, but it will suffer from system performance issues related to it's pure-perl nature and high-level design. It will not perform in milli-second type situations, but I'm not designing it for that. Brick and morter auction houses never ended bidding at "3:05:33". As long as there was a hand raised, the bidding continued.
Basically, this disclaimer is the "dose of reality". Don't expect to run an eBay off this. An Amazon... maybe. :) It's a high-content, medium traffic type of solution -- for the rest of us :)
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
