[ic] Interchange 6: Status report and roadmap

[Stefan Hornburg (Racke)]

On 09/27/2011 04:57 PM, Paul Jordan wrote:
>
>> 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?
>

This is stuff that would go into the configuration (Dancer's config.yml) and yes, I already thought of that.
Dancer::Plugin::Nitesi::Cart::DBI already supports this to a certain degree.

SQL::Abstract is helpful here.

>
>
>> Question: what is most common name for the link/url/page in this navigation table:
>>
>> page
>> link
>> url
>> uri
>> *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

Just the path part of the URL/URI, e.g. books/bestsellers for http://mybook.xyz/books/bestsellers.html.

Regards
	Racke


-- 
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team