I just ran into a possible bug in the URL setup in at least XSLT, possible Razor too!
<product index="1" id="213" sku="ART501">
<product index="0" id="273" sku="213">
Check the two parts of the product XML above. Notice @id on the first equals @sku on the last. This breaks the niceurl functions, as the top product actually links to the bottom product.
Reason... Quite simple, the extension method takes either @id or @sku as property, and now can't tell the difference as there's a matchup witch hasn't been foreseen.
Can this be fixed?
Is there any problems in only taking @id as property and not the @sku?
The issue is that while XSLT does have the concept of types it interprets everything as a string thus we made the API try to figure out whether it's dealing with a string or a SKU, but as you've found in some cases where the SKU is a number it will be interpreted as an int instead of the SKU.
The solution is to have two APIs: NiceUrlForSku, NiceUrlForProductId, which is kinda ugly, but it is necessary as XSLT doesn't support overloading of methods.
I'll look into scheduling a work item to add the new APIs to the XSLT library.
The Razor API is not affected by this because it's using the Product object rather than ints and strings.
Bug in CommerceLibrary:GetNiceUrlForProduct()
Hey
I just ran into a possible bug in the URL setup in at least XSLT, possible Razor too!
Check the two parts of the product XML above. Notice @id on the first equals @sku on the last. This breaks the niceurl functions, as the top product actually links to the bottom product.
Reason... Quite simple, the extension method takes either @id or @sku as property, and now can't tell the difference as there's a matchup witch hasn't been foreseen.
Can this be fixed?
Is there any problems in only taking @id as property and not the @sku?
Hi Mads,
The issue is that while XSLT does have the concept of types it interprets everything as a string thus we made the API try to figure out whether it's dealing with a string or a SKU, but as you've found in some cases where the SKU is a number it will be interpreted as an int instead of the SKU.
The solution is to have two APIs: NiceUrlForSku, NiceUrlForProductId, which is kinda ugly, but it is necessary as XSLT doesn't support overloading of methods.
I'll look into scheduling a work item to add the new APIs to the XSLT library.
The Razor API is not affected by this because it's using the Product object rather than ints and strings.
Sorry about the inconvenience.
is working on a reply...