Updating Wishlists

Greetings,

I was wondering if it was possible to automatically update a wishlist when someone purchases something off of it.  I think the answer is no since there is no way to identify that specific user's item(s) but thought I'd throw it out there just to see before I start creating a way.  Thanks.

Kindest Regards,
Chad Johnson

chajo10 wrote:

I'm sure you can with custom coding.

chajo10 wrote:

Why not?  A wish list item is just a type of ShoppingCartItem (based on ShoppingCartTypeId )

\src\Libraries\Nop.Core\Domain\Orders\ShoppingCartItem.cs

just check for matching ProductVariantId

New York wrote:

1.)  Yes, some custom coding can do it.

2.)  You do realize that matching by ProductVariantId isn't going to quite work?  You need to match by CustomerId somehow, not by ProductVariantId.  Anyone could order the same ProductVariant and you would mistake it as someone ordering it off of that person's list.  At the moment, I've added a column to the row to identify the original Wishlist's CustomerId so I can properly identify whose list the item came from.

Sorry if that seemed harsh but it seemed kind of crazy to try and match on something that could return multiple wishlists.  I just wanted to test the waters out and see if someone had already done such a thing.

You can create a plugin that consumes OrderPlacedEvent.

For example:

  public class OrderPlacedEventConsumer : IConsumer<OrderPlacedEvent>
  {
      public void HandleEvent(OrderPlacedEvent eventMessage)
      {
        var order = eventMessage.Order;
        
        // update the customer's wishlist based on the order placed        
        [...]
      }  
  }

See the plugins: Nop.Plugin.SMS.Clickatell and Nop.Plugin.SMS.Verizon for HandleEvent examples.

.

chajo10 wrote:

Your thinking SQL Joins.  You need to think nopC object model.   (And learn Linq - Let EF do the work for you :)
The order has the customer info.

e.g. if you use mb's suggestion regarding OrderPlacedEvent, then you loop thru order's items

foreach (var pv in  order.OrderProductVariants)

and find matching ProductVariant in the wishlist

   order.Customer.ShoppingCartItems
      .Where(sci => sci.ShoppingCartType == ShoppingCartType.Wishlist
                            && sci.ProductVariantId == pv.productVariantId)


(yes, it does seem a bit odd: the customer's cart has both ShoppingCart type items and Wishlist type items)

New York wrote:

...  Linq/EF does the same joins your saying SQL would do.  Run SQL Profiler and you'll see exactly what I mean (you'd be surprised at the SQL statements EF creates).  Either way, it is a headache performance wise to search in that manner, hence why I worked out a way around it by just tying in an extra field to maintain where the item in the user's cart came from (0 if just adding directly to cart, CustomerId of person's wishlist otherwise).  EF is great to a certain degree but sometimes it creates more headaches than necessary.

Btw, what makes you think I don't understand Linq/EF?  That's kind of a presumptious opinion that slightly irks me for some reason.  I've used Linq and EF for quite a while and am aware of how useful it is, as well as what EF's limitations are.

No reason to be irked.  I was just pointing out a way that works.  Yes, I'm aware of EF to SQL underneath, and yes, it's not always pretty and does not perform optimally; in the above case, though, the cart data is probably cached.  Personally, I think you get a bigger headache trying to work around it - figuring out how, adding new fields, etc.  And, when it comes time to upgrade to new nopC, you'll have to diff/merge code.

How do you figure it is a bigger headache with my workaround?  You're searching through 3 tables to match data whereas my workaround uses one.  Yes, there are issues when upgrading, but that same issue is present should I follow your example as well.  The merge wouldn't be that horrible since I added only one field that can be left blank, so only the Core, Services, and Web need dealt with.  The Web would need dealt with in your case.

Aside from that, this functionality would be the furthest thing from my concerns should I upgrade due that I've heavily modified several pieces of Nop to work with the project I'm currently on.  This isn't even the tip of the iceberg, lol.

Anyways, I do have a working piece currently with my solution.  I may go back and create a Plugin though since that does seperate things out a bit more.

It just dawned on me, I may have forgot one piece of information.  I'm not so concerned when a user is updating their own wishlist, it's more of a user ordering stuff out of other people's wishlist.  That is the case I'm trying to catch.  My apologies for not explaining that better earlier.

Many thanks to mb for your suggestion.  I went back and changed my implementation into a plugin.  I'm pretty happy with it thus far and it functions perfectly.  Thanks for that suggestion.