Minibasket on Category.aspx Page?

[zzaacchh]

I have successfully added the minibasket control to the bottom of the Standard Sidebar 1 scriptlet, and changed Standard Sizebar 1 to appear on the left side of Category.aspx.

Everything is fine, except that when a user selects an "add to cart" link from CategoryGridPage.ascx, the mini-basket isn't updated. If I continue to select additional items ("add to cart" again), the basket will begin to update, but it's always behind by one product. In other words, the most recently added item is never shown in the basket.

I've traced this a bit, and seen that the problem is due to the fact that the minibasket's important event (MiniBasket.aspx.cs's Page_PreRender event) happens *before* the AddToCart() event actually occurs. I'm not enough of an ASP.NET expert yet to figure out why these event are occurring in the wrong order. I'm guessing, though, that it has to do with the AJAXy nature of the Category.aspx page.

Any help would be greatly appreciated,
Zach

[Katie]

Hi there,

Yes, we are aware of this issue. We have a partial fix in the recently released SR1 update. You can download the patch here -

http://help.ablecommerce.com/upgrades/a ... _final.htm

However, I would like to point out that this issue could not be fixed for the "Category Grid" content scriptlet. You can view the details for bug ID 6842. It was a case where fixing one bug (7006) broke the mini-basket in certain cases. The easy solution is to put the mini basket in the right column.

We will have to do quite a bit of redesign work to fix both issues so a decision was made to hold off until a future release.

Thanks,
Katie

[AbleMods]

I've traced this a bit, and seen that the problem is due to the fact that the minibasket's important event (MiniBasket.aspx.cs's Page_PreRender event) happens *before* the AddToCart() event actually occurs.

Very good deduction. The reason is all .Net web pages are constructed in a very specific order. Depending on how the user controls are designed greatly determines the outcome of the page. Certain user controls are designed to manipulate their output on Page_PreRender, while others do "the important event" during Page_Init. An AJAX implementation further complicates things by creating additional (and possibly unforeseen) callbacks to the server-side code.

Depending on where on the page you put an object, you alter the sequence in which objects are constructed for that page and thus the controls must be designed a very specific way to allow for use in multiple locations.

In other words, not all user controls are universal in where they can be located on any given page. It takes a remarkably complex amount of design effort to make a system where every control is usable in any location on any page. So designers subsequently write code with a certain "mindset" when the user control interacts with other user controls. This keeps both their sanity and their code complexity to a manageable level. Or at least the code complexity