I am looking for the best/most appropriate way to handle showing a price range for a Product. The Product has simple variants underneath it. I know I could do it by writing it in my own way but I wanted to pole the community if you have found a built in/quick effective way to do this.
What I need is the following:
$19.99 - 64.99
$19.99 being the lowest price out of the variants and 64.99 being the highest price out of the variants. Again this is fairly trivial with a loop of sorts to go check pricing but is there a better way?
The only way I have done it so far is to loop the child nodes. You could do this in a partial and cache the partial result to save having to perform the loop on every request.
Another option I could think to do would to maybe hook into examine and whenever the node / child nodes are re-indexed maybe save the min / max prices on the parent nodes entry so that you only have to do the same calculation once.
I was thinking of doing the first option you mentioned. Though I wonder how much more expensive it would be to put it in an extension method that returns a string...
I'd probably say negligible difference really. I think the more important thing is caching the value correctly. I tend to go for a simplistic caching strategy whereby the whole view cache is cleared whenever something is published as this should ensure you always have the up to date pricing but at the same time caching to prevent over-fetching. It really depends how busy the site is though and whether there will be a lot of publishing going on.
How does Vendr relate Parent Products to their Variants? Is there a method of sorts to get all variants for a product based on the ID?
I am contemplating turning the parent product into a product snapshot and working from their, however, this may not gain me much in the long run as this is sort of a one off instance.
For variants using the variants editor, the variants data is stored in a property value so to get all the variants for a particular node, you'd use Umbraco's published content cache to get the primary product node by ID, and then access the variants property to access the variants.
Vendr comes with a value converter already defined, so if you are using Models Builder the variants property should already be strongly typed to a ProductVariantCollection from which you can iterate over for all the defined variants.
If you aren't using Models Builder you can use something like productNode.Value<ProductVariantCollection>("variants") instead to get the strongly types variant collection.
Ultimately I used the .Value() method just like you would in Umbraco, I like the way Vendr treats everything just as Umbraco would, however, that does sometimes have me questioning if I am getting the data in the “right” manner.
Not that the way I did it is wrong but I am looking to streamline the fetching of data where ever possible.
Right now I have an extension method created that takes the child nodes and converts them to a list so I can put an index to them and compare pricing.
If you want this method for ideas or to use in a later version let me know.
I was thinking that if you had a strongly typed Product object that this could be a method on the object. Though given the nature of the way Umbraco and Vendr work together I’m not sure how you would relate a product document type to an object like that as it’s really up to each individual developer of how they want to treat their products.
I'm always open to suggestions if there is a nicer way to do things, or if you want advise on the optimal way to do something by all means share your code and I can point out any pitfalls.
Ultimately, products being umbraco nodes means most "best practices" for performant node access hold true for Vendr too so following Umbraco best practice should lead to good Vendr best practice. Beyond that, we try to cache a lot so hopefully accessing most things shouldn't create any bottlenecks.
Show Price Range of Variant Products on Product Family Listing
Hi all,
I am looking for the best/most appropriate way to handle showing a price range for a Product. The Product has simple variants underneath it. I know I could do it by writing it in my own way but I wanted to pole the community if you have found a built in/quick effective way to do this.
What I need is the following:
$19.99 - 64.99
$19.99 being the lowest price out of the variants and 64.99 being the highest price out of the variants. Again this is fairly trivial with a loop of sorts to go check pricing but is there a better way?
Hi Kyle,
The only way I have done it so far is to loop the child nodes. You could do this in a partial and cache the partial result to save having to perform the loop on every request.
Another option I could think to do would to maybe hook into examine and whenever the node / child nodes are re-indexed maybe save the min / max prices on the parent nodes entry so that you only have to do the same calculation once.
Hope this helps
Matt
Thanks Matt,
I was thinking of doing the first option you mentioned. Though I wonder how much more expensive it would be to put it in an extension method that returns a string...
Hey Kyle,
I'd probably say negligible difference really. I think the more important thing is caching the value correctly. I tend to go for a simplistic caching strategy whereby the whole view cache is cleared whenever something is published as this should ensure you always have the up to date pricing but at the same time caching to prevent over-fetching. It really depends how busy the site is though and whether there will be a lot of publishing going on.
Matt
How does Vendr relate Parent Products to their Variants? Is there a method of sorts to get all variants for a product based on the ID?
I am contemplating turning the parent product into a product snapshot and working from their, however, this may not gain me much in the long run as this is sort of a one off instance.
For variants using the variants editor, the variants data is stored in a property value so to get all the variants for a particular node, you'd use Umbraco's published content cache to get the primary product node by ID, and then access the variants property to access the variants.
Vendr comes with a value converter already defined, so if you are using Models Builder the variants property should already be strongly typed to a
ProductVariantCollectionfrom which you can iterate over for all the defined variants.If you aren't using Models Builder you can use something like
productNode.Value<ProductVariantCollection>("variants")instead to get the strongly types variant collection.Hope this helps
Matt
Matt,
Ultimately I used the .Value() method just like you would in Umbraco, I like the way Vendr treats everything just as Umbraco would, however, that does sometimes have me questioning if I am getting the data in the “right” manner.
Not that the way I did it is wrong but I am looking to streamline the fetching of data where ever possible.
Right now I have an extension method created that takes the child nodes and converts them to a list so I can put an index to them and compare pricing.
If you want this method for ideas or to use in a later version let me know.
I was thinking that if you had a strongly typed Product object that this could be a method on the object. Though given the nature of the way Umbraco and Vendr work together I’m not sure how you would relate a product document type to an object like that as it’s really up to each individual developer of how they want to treat their products.
Hey Kyle,
I'm always open to suggestions if there is a nicer way to do things, or if you want advise on the optimal way to do something by all means share your code and I can point out any pitfalls.
Ultimately, products being umbraco nodes means most "best practices" for performant node access hold true for Vendr too so following Umbraco best practice should lead to good Vendr best practice. Beyond that, we try to cache a lot so hopefully accessing most things shouldn't create any bottlenecks.
Matt
I will revisit this and implement it using the ProductVariantCollection most likely
I really need to get out of treating everything as IPublishedContent when stuff like this comes up and fine tune my casting a bit.
is working on a reply...