7938 Posts in 1466 Topics by 943 members
|Go to End|
16 March 2010 at 11:16am
I need to develop a site containing 1000s of products organized into categories/subcategories/sub-subcategories and brands. This is not an e-commerce site. On the front-end, the user should be able to click on brands in the menu, select a particular brand and see the products within that brand arranged into categories. Simultaneously, the user should be able to go to products in the menu, select a particular category/subcategory and see all products belonging to that category/subcategory (possibly arranged into different brands). Each product will have a list of properties and multiple images associated with it.
Is DOM the best way to organize products into categories/subcategories/sub-subcategories and brands?
Can someone please provide some guidance as the best way to use DOM on this project?
16 March 2010 at 12:34pm
I would probably set up a ModelAdmin for category, and have a many_many DOM to manage products associated with each.
16 March 2010 at 1:43pm
Thank you UncleCheese.
This sounds too advanced for me.
How do you go about setting up a ModelAdmin for category/subcategories/... and do I need one for brands also? How would you set up the many_many DOM then?
Each product needs its own unique URL so I assume they would need to be created as separate pages (page type 'Product' for instance).
Brands and Products (broken into categories/subcategories/...) would need to appear on the site's main menu (and dropdown submenus). So I would imagine that I would need to create pages/subpages/subsubpages for Brands and Products (broken into categories/subcategories/...).
Can you please guide me in the right direction?
Thank you in advance.
16 March 2010 at 1:53pm
If you have 1000 products, then I don't recommend that everyone has its own page. You should just create a product holder controller that has an action like:
public function show()
return array (
'Product' => DataObject::get_by_id("Product", $this->urlParams['ID']);
<% control Product %>
<% end_control %>
Then you could access the product with /your-product-holder/show/123
Something like that is better practice than creating a page for something that really isn't a page.
16 March 2010 at 3:38pm
Each product is an actual page and would need to have a SEO friendly URL, such as http://domain-name/products/product-name(or product-code). A product may even have sub-URLs, such as http://domain-name/products/product-name/specifications. I am planning to use SS 2.4 beta for hierarchical URLs. Can I not use individual pages for products then?
How would the Model Admin and many_many DOM work? Can you please give me some instructions?
16 March 2010 at 4:41pm
If you want SEO friendly urls, just create a slug instead of using an ID. You can put something in your onBeforeWrite() function like:
$this->Slug = SiteTree::generateURLSegment($this->Title);
After checking uniqueness, of course..
Then just set up your controller to look for the slug instead of the ID. A little extra work, but well worth it, IMO.. 1,000 entries in the site tree is enough to give me nightmares. Ugh.
You can read the tutorial on DataObject relationships in the docs. I think it's tutorial #5.. You can replace all the examples using ComplexTableFields with DataObjectManager. They take the same arguments. Basically you just want something like:
And then you can add, edit delete, and even reorder products and just check off those that are associated with the category.
16 March 2010 at 4:53pm
Thank you UncleCheese.
To avoid having 1000 products as individual pages in the site tree, do you still recommend that I use ModelAdmin (as on http://doc.silverstripe.org/doku.php?id=modeladmin) to manage products/categories/brands in a separate section of the SS admin and not under "Site Content"?
There's so much to learn about ModelAdmin and DOM. I don't know where to start. Do you know of examples, similar to my scenario, where ModelAdmin and DOM are used together?
|Go to Top|