Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Move Main Content table tags to header/footer


rthrash

Recommended Posts

In order to modify the look and feel of stores, you have to touch many files. While it's easy to do so via a quick find-and-replace, it would be more simple and eliminate a lot of redundant code if the opening and closing "main content" tags were moved to the header and footer files, respectively.

 

The benefit: the control of a stores' look-and-feel is isolated from the actual main content of each page. That way, if one desires to modify the width, background image or any other aspect of the main content section, or convert from <table> to <div> tags, it's only two quick changes in the same number of files vs. making two changes in, by my estimation, roughly 50 more or less files.

 

This could also be expaned upon by moving the left-column and right-column to the header and footer respectively, although I personally prefer to have the flexibility to include them on a page-by-page basis (for instance, eliminating all info boxes during checkout so to make it as streamlined as possible during the checkout process).

 

If control of the info boxes on a page-by-page basis is desired, then the logic would need to be changed. Perhaps there could be a new function/class written to put the available info boxes into an array that can be modified for each page. This would allow admins to determine which info boxes appear on each page, in which column and in what order.

 

This should be done for (at least) two levels of users, so that non-registered site visitors could be presented different options than registered site visitors. Purely as an example, an admin may not desire for guests to see an order history, wish list or GV account, but might want hese options visible for registered and logged-in users.

 

This could be further extended to allow different levels or classes of registered site visitors to be presented different info boxes, depending on their classification. As a hypothetical example, "preferred members" could have be shown a box with specials for preferred members only.

 

To accomplish this, maybe the existing work of the Column Controller contribution could be leveraged and extended. Coding the administration side of this may be tricky, but then again, this may be getting into the area that will be addressed by MS3 with the template options and integrated catalog and admin functions/classes...

 

And just to raise yet another architecture-level idea, I think it would be beneficial if Infoboxes could be automatically registered if the code or confinguration file were dropped into an infobox-registry directory, and to tie this in with the existing caching system so the load on the server may be lessened once the store is set up and running.

 

Does this sound like a good or viable idea?

Ryan Thrash

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...