Well, the arbitrary tables thing will probably happen due to GoCart. For my needs, burrying the product in the link record is not working out well. My "Links" need to be something besides a product, the products need to be "attached" to a link(s) and once they are sold, the products disappear, but the link(s) remain.
This requires an Items/Products table, and I have to try to resurrect that code.
GoCart looks like it can attach to a table, and then map it's required fields onto that table. This is a _good_ thing, and very close to what I am working on (but not exactly). It does have the idea of making each program responsible for "knowing" what fields it needs, but that is a more complicated set up than I was hoping for.
What I want, is a way for setting up a table, that using "associations" to the Links table (or even each other). I've talked about it in other messages, but the key concept is that the associated tables contain data items that are tightly (contain the LinkID) or loosely (do not contain the LinkID) related to the Links table. When a link is called (via select or display), these associations are checked, and the relevant ones are loaded. It makes no sense to load _all_ associations.
This requires some sort of "dispatcher" to work properly, and allow new tables and associations to be created and managed.
For instance, you have a links directory, but some links are classifieds, some are products and some are member profiles or reviews. When you load a link from the classifieds area, you want to attach the classifieds data and perhaps products, but there is no reason to fetch reviews or member profiles.
More clearly, a Link has several attributes. In a photo gallery situation, it may be a description of a photo group with a reference to a photographer, location or style. Attached to this link may be images or other image groups, a photographer bio, purchase information, etc.
In the category display, you may want to "Know" that these items exist (check out the sidebar on
http://imdb.com when you look at a movie), but you do not want to load them until called. So, some dispatcher has to know that link 42 has associations with various tables. This can be done via a Links_Tables table, were you have non-unique fields of LinkID:Table_Name associations. Table_Names are mapped to "features" so you can illuminate features.
In the category display, if you are in the Images sub-topic, you might want to "fetch" the image data, not that it just exists. ie: that 99 images are associated with this link, and provide links to them. You are not "deeply" interested in the photographer, or locations, or other associated information.
Or, when you pick an image to purchase, you want to load the information from the Items/Products table, but you do not need to bother with calling for any overhead from other tables.
If there is none of this "intelligent" decision making on which tables to reference and when, some sort of decision tree, then the overhead goes way, way up. You start passing around all sorts of unnnecessary data, and I don't like that :) Never liked it, not since my first real programmatic break through on multiplying arrays of arrays for disease spread analysis on a TRS-80, when I got processing time down from over 22 minutes to under 30 seconds by applying this "relevant data only" model. That sort of example (when there are only 2 computers in a class and classes lasted only about 40 minutes) sticks with you :)
This project needs the following modules (that can be worked on by others who want to contribute something in the way of code:
1) table editor: create/add/modify/update tables. The ability to define a new table, have it created, and have entry forms for data created (either once, or dynamically) so people can create new tables and have a simple interface to them. Preferably, this hooks in as both an admin module, and accessible from the user-interface so editors and logged in users can get to it, but the code itself is most important now, as a free-standing "simple" widget module. Caveat: Foreign Keys may play here, if some records need to be removed automatically if a Link is deleted (such as item/LinkID relations). This sub-module may be a separate project in itself, since determining these relationships is a decision tree unto itself. Then, not only "house keeping" references need to be cleaned up or deleted, but if a hard reference is made between an item in a table and LinkID those items should be cleaned up (deleted, moved to "dead" table, etc) if a Link is deleted. NOTE: this table creation module has application in many other plugins, programs, etc so is a useful 'widget'.
2) Decisions (dispatch) Module: this module hooks into the call for a link, and finds out all the information about it. It finds out what tables it is associated with, then decides what table data to load. Most likely it needs to be passed a flag that "0", only load tables, "1", load table summary ie: tables and number of related elements in that table, and then specific flags for each table, such as the table(s) names so it goes and loads the relevant data for each of the related tables and returns that. In it's simplest form, it does just this. In it's more complex form, it maintains a config file, relations file, and summary file to speed up this sort of access. It takes the returned data, formats it, and returns the "string" to the calling routine.
If anyone's interested, the "test" data is an Items table, that has basic (detailed) information on an "item" and based on several flag fields may have tables with related data for that item. Items are linked to the Links table via an Item_Links table.
The first module would allow creation of this table within a users system, and allow them to add/enter data into that table through a simple form.
The second module would respond to a request to display a link, by returning the associated Items attached to that link.
As noted, there might be second-level associated tables, such that an Item that has several variations or styles will have a separate record for each, with the basic information wrapping it. Manufacturer, features, etc may all be the same, but sizes or options may vary. These are best kept in second-level associated tables. This is a complexity that doesn't need to be addressed at first, but needs to be considered when designing the system.
Some fields are best left as associated tables/fields. Such as clothing with 19 colors and 9 sizes. Simple drop-down boxes with the color/size and associated weight/price etc that check a back-end inventory is possible. But for others, where there are fewer variations, but more changes entering a new item record based on an exisitng record is better.
Others, might be addressed by making each variation a separate record. Data is carried over, and what needs to be changed can be. Caveat: changing one set of fields should be able to change all fields in all records (check boxes??). If there are 4 entries for a tractor, each with 10 fields the same but 6 fields change, if one of the 10 fields is changed, it should be able to be changed in all 4 records, not just 1.
Anyway, it starts to get complex, as you can see :)
PUGDOG� Enterprises, Inc. The best way to contact me is to
NOT use Email.
Please leave a PM here.
Overall Site layout question