Ricky, some of the enhancements were actually inspired from seeing how you customized ecommerce.
The ecommerce code isn't yet up-to-date with openacs standards, but importantly it *does* work with much of it.
Regarding the general idea of moving code to OpenACS core features, one can apply these disadvantages:
The more core features are used, the less likely that someone without much experience will be able to maintain/fix it when there are problems, and the more likely a de-stabilized problem with another package will affect ecommerce.
A) Use acs-categories for the product categories instead of dedicated data structures.
i) Would deeper category structures degrade performance?
No degradation. My understanding is that the hierarchal representation is "shadowed" into a column for fast referencing etc.
ii) Would ecommerce performance be degraded in systems that grow to very large numbers of acs_objects?
ec_products is already linked to and an extension of acs_objects. Look at the table definitions in ecommerce/sql. Degradation shouldn't be significant, unless one starts adding per product permissions etc.
B) Use list-builder to generate product listings.
This may be fine, is certainly fine if can be completely defined in ecommerce/lib so that it's easy to switch to another includelet if needed.
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.
i) Would performance be acceptable with large datasets?
I believe so. listbuilder used to handle some db related functions in tcl (which was slow), but since about 5.1 uses the db properly to gain the most in performance.
ii) Is display layout flexible enough?
I'm not sure. if css references can be controlled, then yeah. If the css references are fixed, then any product list display changes would likely affect lists all over the affected website.
C) Use AMS for re-code of custom product fields.
1) Automatic form generation for use in re-coded product edit pages.
2) Better abstraction and code structure.
3) Tighter integration with core.
i) Performance with large datasets and large numbers of custom fields?
Automatic form generation is fine until you don't want it automatic. I conceptually understand how ad_form works, but have never gotten one to work ..not even the example notes package. I believe that using ad_form could significantly decrease the qualified labor base, should a company want to hire help to make changes. ad_form has it's own meta language space different than tcl, sql, and adp/html.
ad_form has the limitation of requiring no more than one form per page. Ecommerce tends to have multiple forms per page.
Yes, the display code needs to be separated from data. These ec_ procs should be deprecated in lieu of using includelets and formatless procs.
I think the data model has reached it's limit, and needs radical changes, which is one of the reasons for starting ecommerce-g2 project ( http://dekka.com/p2/ ). One main limitation is that ec_items does not have a quantity column. ec is currently not suitable for shops that allow/promote bulk quantity sales.
I agree that ecommerce can benefit by using xowiki or implementing xowiki-like processes. See http://dekka.com/p2/xowiki/online-catalog Xowiki css needs to be standards compliant and the css more cross-browser stable. Try changing some of the DIV background colors to see the differences in display between browsers.
I haven't had a chance to play with adp includelets much in Xowiki, but believe it's going to be straight forward once the ecommerce/www pages have been deconstructed into ecommerce/lib.
There already exists some code in ecommerce to use (an early version of) site-wide search. Hopefully it wouldn't take too much to update it to work with the latest.