3461 Posts in 1065 Topics by 740 members
|Go to End|
4 March 2010 at 11:19am Last edited: 4 March 2010 11:25am
I'm restructuring a site to incorporate some online ordering facilities for 1000+ products.
I'm just after some advise as setting up the product class to extend pages vs. dataobject.
What are the pros/cons, and what would you guys consider best practise?
7 March 2010 at 2:35am
I would define that many products as DataObjects.
All Page objects are displayed in the backendÂ´s site tree. Now Inagine a site tree with a thousand entries.
A product is not a page on its own. It has in fact a details view, which you have to make by yourself. For a SiverStripe pro this is done within 1 hour.
24 May 2010 at 11:29am
I just wanted to confirm, with more information, that dataobjects is the best method to implement this solution.
I'm working on a Silverstripe site that currently has 1600+ products. Each product has been implemented as a page, as the product detail view is a new page. Each product can also have related products, which the content administrator selects from the CMS.
Is there any benefit to changing this structure so that products are dataobjects instead of pages? I've read posts where developers have advised that if an object is to have its own URL, then it should be a page and not a dataobject?
24 May 2010 at 8:12pm
Hi. This really depends on your requirements, and there is no right and wrong way. Some design choices meet some requirements better, other choices may meet other requirements different.
The general advantage of the product as a page is that is has all the page behaviour, out of the box. This includes products that are versioned, products automatically having a URL, you can look at differences between current and old versions, permissions behaviours out of the box, etc. There are advantages to this structure. There are also disadvantages, such as a potentially very large site tree, which may or may not be a problem. E.g. if the products are hierarchically organised, it may not be a problem. But if the number of products is going to grow to 100000, it may become untenable.
DataObjects give you more potential flexibility, but you may have to do more work to get the behaviour you want. You can write a controller that surfaces each product with a URL segment. If you have a very large set, or a set with little inherent structure, then DataObjects are usually a better way to go, and there are things like ModelAdmin that assist in giving you an interface to work with those objects, as well as third party modules like DataObjectManager, designed for this purpose. Bear in mind that quite a bit of Page's functionality comes from decorators, like Versioned, which you can apply to DataObjects. Again, it's flexibility and control, at the cost of more effort (in my experience, anyway)
If your site is already implemented using pages, you probably only want to undertake moving to a DataObject model if there is a clear advantage to doing so. e.g. if performance were unusable with pages for some reason, or it looks like it might not scale to a much larger product set if that is planned. There is a cost/benefit calculation behind this.
25 May 2010 at 11:00am
Thanks Mark - great reply, and you've brought forward points for me to consider for future Silverstripe implementations - thank you. You've included business-decisions issues which are fundamental in my current example.
In this case, the clients like working with the product pages in the SiteTree, there's a 4-level deep categorization hierarchy for the products, and they do require versioning as part of their workflow, so I will leave the products using the Page model.
|Go to Top|