Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Data Model Questions /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Dataobjects vs Pages?

Go to End

5 Posts   1760 Views


Community Member, 75 Posts

4 March 2010 at 11:19am

Edited: 04/03/2010 11:25am

Hi guys,

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?


Community Member, 279 Posts

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.


Community Member, 75 Posts

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?


Community Member, 78 Posts

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.



Community Member, 75 Posts

25 May 2010 at 11:00am

[Like this!]

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.