Forum OpenACS Q&A: Re: E-commerce 'category-browse-subcategory.tcl'

Collapse
Posted by Torben Brosten on
Interesting, Ricky. db_multirow specifically states that it uses 1 for the start row ( https://openacs.org/api-doc/proc-view?proc=db_multirow ). There must be another way to handle this, or the calculations will need to be changed on this and the other category-browse pages.
Collapse
Posted by Torben Brosten on
Also, the local versions here are working as expected, ie 1 item in a subcategory shows.. 1 item.

Some of the category browse code caches other values. I'm guessing that a server restart would fix it..

The category browse pages were originally coded to handle all three category levels on one page.. and were then separated to add more level specific options.

The code on these pages needs to be simplified, new features added, and moved into /lib

I'm making this priority for the weekend.

cheers,

Torben

Collapse
Posted by Richard Hamilton on
Torben,

I think we may be at crossed purposes here. I am talking about the OFFSET in the query itself, not the data representation created by db_multirow.

"OFFSET says to skip that many rows before beginning to return rows to the client. OFFSET 0 is the same as omitting an OFFSET clause. If both OFFSET and LIMIT appear, then OFFSET rows are skipped before starting to count the LIMIT rows that are returned."

From: http://www.postgresql.org/docs/7.2/static/queries-limit.html

In subsubcategories there was a default OFFSET of 0 but in subcategories there was a default OFFSET of 1. Both can't be correct, so one way or the other one of these needs to be changed.

I agree that this code is a little obscure and could do with being improved, although as it stands it does work well. Time invested in trying to reduce query times on your large dataset might be well spent and I'd be happy to help with that if you'd like me to.

As far as a complete re-write of this code is concerned, I mentioned before that I would like to contribute to that process.

I have had a look at the new version now and can see lots and lots of evidence of the fantastic work that you have done on this module to bring it up to date. It looks great and you have added some really important new features and support. Congratulations.

Looking forward, I wonder if it would be worth gathering some opinions on the benefits and disadvantages of migrating some of the ecommerce data structures to take advantage of some of the newer core features. This would have to be done with due consideration for performance (we don't want to 'improve' the code structurally only to find the performance degraded).

The ideas that I think we should explore are:

A) Use acs-categories for the product categories instead of dedicated data structures.

Benefits:

1) Would provides ability to have more than the three levels of category.
2) Would allow mapping of more complex reationships.
3) Integrates module more tightly with core system.

Questions/disadvantages:

i) Would deeper category structures degrade performance?
ii) Would ecommerce performance be degraded in systems that grow to large very large numbers of acs_objects?

B) Use list-builder to generate product listings.

Benefits:

1) Should be quick to code, consistent presentation and robust.
2) Provides pagination and other features already.
3) Better abstraction and code structure.
4) Benefits from code performance improvements to list builder and core rather than requiring separate optimisation.

Questions/disadvantages:

i) Would performance be acceptable with lare datasets?
ii) Is display layout flexible enough?

C) Use AMS for re-code of custom product fields.

Benefits:

1) Automatic form generation for use in re-coded product edit pages.
2) Better abstraction and code structure.
3) Tighter integration with core.

Questions/disadvantages:

i) Performance with large datasets and large numbers of custom fields?

These changes, if workable, would be a great first step and would provide the platform on which the rest of the pages could gradually be re-worked and structurally improved. In particular I'd love to lose the spider's web of progressively nested tcl functions that containing display
information. I'd like to separate that out into css for all pages. However, I think to aboid wasted effort we should address the data model questions first.

As a separate suggestion, I also think we should code up some xowiki ecommerce includelets so that once an ecommerce module is in place in a system, users could build shop functionality arbitrarily into user pages.

Some initial ideas for different includelets:

1) Product category tree display with browse and product listing.
2) Single product display with product view and 'add-to-cart' options.
3) Your account/ orders display
4) Shopping cart display
5) Ecommerce utility box with log-in link, items in cart count, value and link to cart display.

What do you think?

Best regards
Richard

Collapse
Posted by Richard Hamilton on
Oh sorry - one other thought. Implicit in what I have already floated is the notion of making products acs_objects. There benefits of this might be:

1) Different product managers could then have admin control over different products and categories of products. This would allow permissions to match organisational product management and sales accountabilities.

2) Categories of product and products themselves could be restricted to specific users and user groups. Perhaps this would be useful for example in a members' or purchasing club where certain products are only available to club members.

3) Built in notification capability through notifications in core. This would make notifying users for any reason (i.e items changing stock status or pre-ordered new products being made available for sale) very straightforward.

4) Better integration with core, better abstraction.

5) Easier to write content provider to site wide search module and would allow us to use sws to replace the ecommerce search.

Regards
Richard