Hi all,

I'm working on a product showcase application managed using Model Admin in SilverStripe (which I this is a seriously great module!)

There's a set structure for how the items are categorised, which is very simple to set up with regards to their DataObjects.

Essentially there are 2 category levels - Top Category and Subcategory. Each product belongs to one or more Subcategory and each Subcategory belongs to one Top Category. There must not be any further levels of categories.

I am trying to figure out the best way of managing this system in the CMS. When I say the best way, I mean the cleanest and simplest way for my client.

I've played with different methods of managing categories. I've used ManyManyComplexTableFields which seems great for single level categories, but not for multi-level categories (or so it seems to me). Also there's this solution posted here http://silverstripe.org/general-questions/show/265149#post265149 - for unlimited levels of nested categories using self join, which isn't exactly what I'm after due to the strict 2-layer categories I need.

I was thinking one method would be to manage the Top Categories separately in ModelAdmin. Then, when assigning products to Subcategories, somehow dynamically create a ComplexTableField for each Top Category, showing the Subcategories and enabling the user to add more Subcategories and tick them. I hope I've explained this well enough!

So, do you guys think this is a good way of doing it? And, most importantly, is it possible? I haven't tried it, but is it possible to create dynamic fields in getCMSFields() using DataObject::get() to retrieve a list of all the Top Categories, create ManyManyComplexTableFields for each one, then assign all checked SubCategories to the product being editied??

Phew! Thanks for your help in advance!

Hi Tim,

here is the way I would do it:

Categories & Subcategories as PageTypes. This allows the client to see the structure in the tree, which I think is a lot clearer than trying to figure it out from model admin relationships. You can then set the static variable $allowed_children to ensure the structure that you want, so 'CategoryPage' would have allowed_children of 'SubcategoryPage' and SubcategoryPage would have allowed_children of 'none'.

Then you manage your products in model admin and use the multiselect field (module) on the SubcategoryPage to manage the Many_Many relationship to those products.

If you want some more detailed code examples let me know :)

Aram

Hi Aram,

That's a nice way of doing it, thank you!

If I am to use the site tree to represent categories and subcategories, it would be great to simplify the interface with things like disabling the draft functionality (which isn't really needed in this case), removing the automatic generation of 'Page not found', and removing all unwanted tabs (which I believe can be done with removeByName()).

I don't suppose this is a straightforward process, but if you have any ideas it would be a great help.

Well, I am not really sure why you would want to remove all that functionality? It all seems useful to me.

Forexample having draft functionality means ur client can hide some categories that they might not want to show all the time without having to delete them, for example 'Christmas Offers' etc.

I am assuming these categories will be viewable as pages showing their accociated products no? If they are then it seems as though you don't really need to remove much functionality at all, it should behave as a page with metadata, page title, menu title etc. the only thing you might want to remove is the content field.

Am I missing something?

No, you're quite right.

These categories will be shown as pages in the client, but not as HTML pages - I'm using a flash frontend for this one, so my templates will be outputting XML for the Flash to read. It's also installed on a local server - i.e. server and flash client all on a standalone kiosk machine. So stuff like metadata, behaviour etc isn't really needed for this application. I accept this is not exactly what SilverStripe was made for, but the discovery of ModelAdmin has made it more suitable and powerful, especially when we're talking about 500+ products.

If I do take the site tree route I shall pitch the Christmas Offers argument as an advantage of the drafts functionality though!

Thanks again Aram.

Ahh I see, makes more sense now. Then yea I guess you can just use removeFieldFromTab($TabName, $FieldName) and removeByName($Name) to remove the bits you dont need :)

Anyway glad I could help!