Trying to add a rating to my product using the episerver.common.rating.ratinghandler but getting an exception.
I can see that new Rating expects a IRateableEntity but implementing this interface on my product dont do the trick. I suspect i need to connect my product to the EntityBase somehow. Anoyone got an idea on how to do this?
My code so far:
Product = class inheriting from ProductContent. And i've added impolementation of IRateableEntity interface as well.
var rate = new Rating(product, new GuestAuthor(string.Empty), 2);
The exception i get is on code is from the last code line and the stack trace is:
Object reference not set to an instance of an object -
at EPiServer.Common.Rating.RatingValidator.ValidateRate(IRating rating, String argumentName)
at EPiServer.Common.Rating.RatingHandler.Rate(IRating rating)
I know the RatingHandler is obsolete and won’t be supported after EPiServer 8 but since there is no documentation of what to user instead I don’t have much choice but to use it.
You are correct that Common Framework is obsolete and will be removed soon (Actually the version of Commerce without Common Framework is under testing right now and should be released very soon). So we highly recommend to stay away from it.
For rating and comment issue, I think most of Commerce implementations are using third party solutions, other than Common Framework. We have a plan of releasing a package for that, but I can't say about exact timeframe.
From your code I think you just want the aggrated result, instead of who voted and value of each voting? You can simply add a metafield for that product and do some simple calculation. It should not be ver complex to implement.
Thanks for the answer.
Yes, it would be relatively easy to implement this with custom code but we wanted to use the build in functionality. We do actually need the info about who did the voting as well but i guess we need to do it our self.
What about existing commerce sites that use the Common Framework? I sure hope you'll supply an alternative and a tool for converting existing Common Framework functionality?
I want to clarify a bit, the part that will be removed is the dependency of Commerce on Common Framework, along with any wrapped classes/extension methods. You will need to update your code if it's using those wrappers. They'll be gone.
But if you're using "pure" Common Framework and want to keep it then that's an option. You'll be able to keep the settings, assemblies and database - although you'll not be able to move to Azure with Common Framework attached. We recommend to stay away from CommonFramework, but it's not something we forcibly do.
There were discussions about the replacement of CommonFramework and we think that the number of sites which are actually using Common Framework is low, and we have no plan for a "replacement package" for CommonFramework - as we decided to focus our resources to move forward. Some features which have been asked such as comment, rating,... are under considerations and might be made available in separated package - although I can't make any promise at this point.
This'll be a crucial feature of the project I'm working on at the moment. So if we implement rating/reviews with the current Common framework (and make it work, somehow), that'll just be removed in a patch or two from now?
What exact parts will be removed along with the Common framework, and what will stay? What will be auto-migrated into some new, built in thing? What will not? Will developers have to migrate things manually to third party tools? Will there come some new replacement in the future?
I'd say you should seriously get out some official information to all developers using your products about these future changes, as they might just make or break projects all over. The only thing that's gonna happen if you do not, is that developers using your products will be insanely frustrated, while end customers loose faith in the entire EPiServer platform they have invested in. And by that I do not want buzzwords such as "Next up, we're doing COMMERCE, and after that MARKETING!" - I want proper technical terms and implications.
Us developers not knowing anything about the future of the product will cause you problems in the end. It is in your business interest to tell us what the exact plans for up and coming big changes are, so we can predict projects and tell customers what's gonna happen, instead of someone not reading this very thread ending up in a dark hole with an unhappy customer because they have to migrate all Review/Rating-data to some third party solution after having marketed the fact that "This is built in, so we can do this easily!" to the end customer.
Edit: Ok, some questions are probably answered in the post you wrote at the same time as I did mine. Points staying the same, though.