I'm currently scoping out Umbraco as the potential platform for a website I'm working on. The client essentially wants an e-commerce site, except, instead of the normal shopping cart/checkout functions, they want logged in users to be able to add items to 'scrapbooks', which they can have more than one of, with different names. When they are happy with the scrapbook, it needs to be able to do some quote calculations and then submit the results to a Salesforce system, rather than taking payment. They also want a custom recommendation engine where you can pick one product, and find similar ones.
I've looked at some e-commerce solutions, but because the checkout is such a core part of these, it seems they would require quite a hack-job to replace them. So now instead, I'm looking at using Umbraco for the product catalogue, and building the other functionality onto it.
I'm not looking for a complete guide on how to do this or anything, but I am wondering if someone can let me know if Umbraco is even a good choice for doing all this? I'm slowly getting my head round how it works, but haven't quite got enough insight to see how I can integrate it with my own code yet. For example, presumably I would need to create a new doctype to hold product information, but is there an easy way of hydrating a 'Product' model in my MVC project so I can add behaviour to these models?
These are the sorts of questions I'm facing currently. Can anyone give me a nudge in the right direction?
Thanks Matthieu. If you don't mind me asking, how are you hydrating your custom models, or mapping your data from custom tables to Umbraco objects? Are you using Ditto?
So... pull the appropriate document items out of Umbraco, then manually map them to your 'real' entities so you can do your thing with them? Is that right?
Just trying to get my head around the right sort of approach here! :)
All of my "shopping items" are actual doc types within Umbraco, to create a cart feature I have a custom cart table (which in your case could be scrapbooks/items) that stores the doc type NodeId, current Session ID/Or logged in User Id.
When the user actually wants to process the order, I just Query the cart table, retrieve all items and process them into "bookings" and "booking items" tables.
If the actually items themselves, as in items that can be added to a scrapbook need to be content manageable/editable and generally updated by the client. Then your best bet is to stick with storing them as Doc Types within Umbraco.
Then a custom cart functionality, similar to what I suggested above, depending on whether you want users to sign-up for an account before they build a scrapbook, you can make good use out of Umbraco's built-in membership system which piggybacks of the .Net membership
Thanks for the information, useful stuff there. The reason I ask about using the doctype models to hydrate other entities is so you can take a rich domain approach and add behaviour to those entities. For example in my prototype for the product recommendation system (which doesn't use Umbraco), I've added methods so that products know how to compare themselves to other products and produce a similarity score, which can be then used to rank the products by similarity. With your approach, I guess I would need another class to actually do the comparisons and rank them.
However that being said Umbraco also has ways of linking entities via relations. I've also made use of Umbraco Tags before to display related articles.
This might be too primitive for what you're looking for
Is Umbraco a good choice for building this project (web store with a difference)?
I'm currently scoping out Umbraco as the potential platform for a website I'm working on. The client essentially wants an e-commerce site, except, instead of the normal shopping cart/checkout functions, they want logged in users to be able to add items to 'scrapbooks', which they can have more than one of, with different names. When they are happy with the scrapbook, it needs to be able to do some quote calculations and then submit the results to a Salesforce system, rather than taking payment. They also want a custom recommendation engine where you can pick one product, and find similar ones.
I've looked at some e-commerce solutions, but because the checkout is such a core part of these, it seems they would require quite a hack-job to replace them. So now instead, I'm looking at using Umbraco for the product catalogue, and building the other functionality onto it.
I'm not looking for a complete guide on how to do this or anything, but I am wondering if someone can let me know if Umbraco is even a good choice for doing all this? I'm slowly getting my head round how it works, but haven't quite got enough insight to see how I can integrate it with my own code yet. For example, presumably I would need to create a new doctype to hold product information, but is there an easy way of hydrating a 'Product' model in my MVC project so I can add behaviour to these models?
These are the sorts of questions I'm facing currently. Can anyone give me a nudge in the right direction?
Working on a similar project (non-standard Ecommerce) and I'll have to say the Umbraco is definitely a good choice.
Like you, I've decided to opt to "Build from scratch" as the off-the-shelf products would've required a fair amount of hacky work.
I'm even using data provided by custom tables in my DB. PetaPoco classes and a strongly typed MVC solution will be your friends
Thanks Matthieu. If you don't mind me asking, how are you hydrating your custom models, or mapping your data from custom tables to Umbraco objects? Are you using Ditto?
I had to write all manual mappings, I only found out about Ditto afterwards!! :(
So... pull the appropriate document items out of Umbraco, then manually map them to your 'real' entities so you can do your thing with them? Is that right?
Just trying to get my head around the right sort of approach here! :)
All of my "shopping items" are actual doc types within Umbraco, to create a cart feature I have a custom cart table (which in your case could be scrapbooks/items) that stores the doc type NodeId, current Session ID/Or logged in User Id.
When the user actually wants to process the order, I just Query the cart table, retrieve all items and process them into "bookings" and "booking items" tables.
If the actually items themselves, as in items that can be added to a scrapbook need to be content manageable/editable and generally updated by the client. Then your best bet is to stick with storing them as Doc Types within Umbraco.
Then a custom cart functionality, similar to what I suggested above, depending on whether you want users to sign-up for an account before they build a scrapbook, you can make good use out of Umbraco's built-in membership system which piggybacks of the .Net membership
Thanks for the information, useful stuff there. The reason I ask about using the doctype models to hydrate other entities is so you can take a rich domain approach and add behaviour to those entities. For example in my prototype for the product recommendation system (which doesn't use Umbraco), I've added methods so that products know how to compare themselves to other products and produce a similarity score, which can be then used to rank the products by similarity. With your approach, I guess I would need another class to actually do the comparisons and rank them.
Yes, You would have to re-write those methods.
However that being said Umbraco also has ways of linking entities via relations. I've also made use of Umbraco Tags before to display related articles.
This might be too primitive for what you're looking for
is working on a reply...