[ic] Interchange 6: Status report and roadmap
paul at gishnetwork.com
Tue Sep 27 14:57:00 UTC 2011
> On 09/27/2011 02:10 PM, Paul Jordan wrote:
> >>> That's just a start, so the following steps are:
> >>> * Carts and wishlists from the database
> >>> * Remove single item from cart
> >>> * Checkout procedure
> >>> * Documentation on recommended database structure
> >> I would like to add Category& Navigation structure, which will roughly based on the
> >> tables we are using for WellWell:
> >> http://git.icdevgroup.org/?p=wellwell.git;a=tree;f=database/pgsql
> >> categories
> >> product_categories
> >> menus
> >> Maybe we should merge categories and menus, what do you think?
> > I don't use any of that from Standard, nor will in the new IC so I don't know if what I am saying holds true to the actual data and how it is used. I glanced at it and it looks very similar.
> Standard doesn't really have a well thought navigation concept.
> > I would agree with Racke that as an efficient end solution, it is a better concept to store things like menus and categories into conformed "views" or "relationships" table(s). However, well-integrated structures can probably be more formidable for new people to grasp and "hack".
> > The more one thing is tied to another increases the intimacy you need to have before you can create change.
> I suppose I'll go for a "navigation" table, which combines categories, menus and related things like views by tags etc.
> Also think about meta description, page title and other stuff which is related to categories and menus, this would appear
> in this table as well.
What about something more general, like product_relationships. I know that is long, but it also covers "related items" and anything that is not directly for navigation. Although it could be argued that anything is ultimately to build a navagatable link.
Another thought I had recently, what about using variables for table names in the functions that call the table. This would help when you need to tie interchange together with some other system that is less flexible that has matching table names. Lame idea?
> Question: what is most common name for the link/url/page in this navigation table:
> *something else*
What is stored in there? Isn't URI supposed to have the whole enchilada, i.e, http://www.etc.com/foo.html?Product123
Maybe relationship_metadata should be another table - if an item in the relationships has a url - there is an entry, if it has a tag - there is another entry, if it has a description - nother entry.
PS, sorry if my mailer is inserting too many hard returns...
More information about the interchange-users