When you use alternate elements as buttons you forfeit a lot of built in functionality which you then have to replicate with custom code. This custom code can add a lot of time to a project and should be avoided whenever possible. There are many reasons to use <button> elements rather than styling a non button element to look like a button. Out of all of the reasons, the following three reasons resonate with me the most.
With the Sitecore Experience Platform and Sitecore Commerce Connect (Connect), Sitecore provides the tools to empower organizations to build the effective, meaningful relationships that win customers for life. Insite Plus Sitecore Connector (IPS) is built on the Sitecore Commerce Connect framework. Recently, we released a new version of the IPS connector.
Sitecore provides us an option to add data source location for a particular rendering. For a multisite Sitecore solution, setting up a Datasource location to be a query will be very helpful as it resolves the location based on the site in which they are adding a rendering. In this article, I will discuss my experience and an issue I found with using queries for Datasource location…
Our client required a cart that could be accessed from any browser and any computer, when the logged in. For example, if a user creates an order from their work computer, they'll be able to complete it from their home computer. Insite offers a few different cart providers, by default - Generic, ByCustomer, and ByShipTo. These out of the box providers are great! They push the state responsibility to the browser, freeing up the web server's CPU. However, they weren't what the client was looking for. So, I got the exciting opportunity to roll my own cart provider.
Implementing Incremental Product Sync using Sitecore Commerce Connect