You're crazy. ❤️

Really interesting !

Really nice! I would just display the rating as 5 stars, it's more visual than a digit.

What about locale-dependent reviews? As an German speaking i won't have reviews in e.g. Russian.
But as a multilingual person i may want to configure a whitelist of locales for reviews ...

Congratulations, awesome job! 👍

Follows some considerations I noticed:

• I think that a rating average is very interesting for product recommendations and filtering purposes
• Would be very useful to have some events for spam filtering, markup parsing and rating average calculation
• Can a review have both a guest reviewer and an user set? It seems like a modeling inconsistence

And now it looks like this:

Still have a bunch more stuff @stloyd suggested to do, but wanted to show this off.
Also, I agree with @marcospassos about adding an average rating to products (only considering approved reviews, I assume?), and I will add events.

As for reviewer, the user is always set for audit trail purposes, and so far there is no logic to decide whether guest reviews are allowed. Do we want to make that a setting for the core bundle?

One big issue I have here is handling the form submission, because the form is embedded on the product page.
If the form validation fails, I don't really know how to get back to the product page.. Ideally this would be an ajax form, but of course JS can't be relied on..

Any ideas?

@Richtermeister my question is from an architectural view. Currently, we can set both an user and a guest reviewer, right? It seems weird, once a guest reviewer is a user (an unregistered one). Then, to decide the review's authority, you created a macro. I think it's not a good place to put this logic, it should be transparent, because you may use it not only in the view layer. For example, let's suppose that I want to send a email to all users that wrote a review about a promotional product, as it is right now, I have to spread this business logic for every part where I need to reference the review's author.

@marcospassos So, you suggest we create ReviewInterface::getReviewerName() and ReviewInterface::getReviewerEmail() methods, which either access the underlying user or the guest reviewer?

I think adding this methods to the class Review will be an overload. Another option is add a relation between the Reviewerand the User. In that way, the reviewer is able to delegate the information retrieval to itself or to the related user, just forwarding the methods calls.

@Richtermeister I tend to agree with @marcospassos about the problem with Guess and User reviews. IMO there is no need to have Review model in CoreBundle it could be in the ReviewBundle, just remove user relation, and add this relation to the Reviewer instead (GuessReviewer should be renamed to that). So you could easly have some methods like:

class Reviewer implements ReviewerInterface
{
    private $id;

    private $name;

    private $email;

    private $user;

    private $createdAt;

    private $updatedAt;

    public function getId()
    {
        return $this->id;
    }

    public function getName()
    {
        if ($this->user instanceof UserInterface) {
             return $this->user->getFullname();
        }

        return $this->name;
    }

    public function getEmail()
    {
        if ($this->user instanceof UserInterface) {
             return $this->user->getEmail();
        }

        return $this->email;
    }
}

@stloyd Sounds good but it couples ReviewBundle & CoreBundle...

@pjedrzejewski This can be done in few ways, and I'm sure that at least one can do this stuff without coupling those two bundles together =)

Thanks for all the feedback guys. Going to take another run at this tonight.

@Richtermeister I'll submit a PR with Behat features to your repo.

its available in sylius now???

Closing in favor of #611.

@aniltc Sorry, I still have a bunch of stuff to clean up and change the way the reviewer is handled.. Will work on it this week.

is it available in sylius?

@aniltc not yet