multiple category heiarchy "views"

I want the user to be able to select a button to control which of those categories is displayed. For example 2 wheel vehicles.

Isn's this a category index?

I want the user to be able to select a button to control which of those categories is displayed. For example 2 wheel vehicles.

This would essentially give the user different "views" of the category hierarchy

Every category can override what list templates are used.

What I can understand from your comment is that you are building multiple types section. And you are doing it right. You do not mix types in categories, you do not user multiple categories select.

You want to make every category like a section but within one section. I kept in mind this scenario when developed Cobalt so it should work perfectly well.

1. Do not allow to root submission in type submission parameters

2. Limit every tipe by categories or category node in type submission parameters.

So now we are sure every type goes to its own categories.

Now templates. You may create one universal temple or different templates for every section. That depends. If there is situation when few different types may be on one page like search result you have to have universal records list template on all categories.

But I would disable it.

1. Set filter mode as record mode in section parameters

2. Set records mode category and its node or category. No matter.

Now we are sure there will not be any search in section root. We will search only when we open category, and it means only particular type.

Create templates for every type you need and set this template in category parameters.

But if you want to search through all categories in section root then you may set filter mode through all section and create list template that would handle all types.

These are my quick thought about your project.

Hi Sergey. Thanks for the thoughts. You have built a ton of functionality into Cobalt and I've used it for a number of things already.

I'm not doing a good job of explaining so I'll add a picture to demonstrate this further. In the attached group, there are 3 views of one big hierarchy - red (B, C, G, H, I), green (A, C, F, I), and orange (A, D, E, J, K). I want the user to select a button that will let them see the entire hierarchy or just one of the 3 views as a way of customizing the category hierarchy to the type of user. The record listing would consist of records only from the view that was selected. The results of filters and searches would also be limited to the selected view. All records within a category would be the same type. You can see from the picture that some categories will show up in more than one view.

Maybe there is a different way to achieve the same result. Essentially the same result would be obtainable if a category could have multiple parents. The the 3 "views" would be categories right under the section. I'm trying to avoid anything that would change the data model or require major code changes though.

Ok , now I see. I have to say that probably it will not work with Cobalt. The way you group categories into views is hard to implement in Cobalt.

Essentially the same result would be obtainable if a category could have multiple parents.

Essentially the same result would be obtainable if a category could have multiple parents.

I have to say that probably it will not work with Cobalt. The way you group categories into views is hard to implement in Cobalt.

Isn't it the planned Cross-Categories feature? I think, it was removed from backend tab. Is it still a planned feature for C9?

Is it still a planned feature for C9?

Not even in Co9

Maybe there is a different way to achieve the same result.

Maybe a client-side JS solution like the popular Isotope ?

It has nothing to do with isotope. Although it would be nice to have one record list template with this script.

And this should give you any view and combination of views you want.

not really. Eg I have 100 articles. First page loads 20. Еhen I reorder. It most probably that correct articles are around 80 that was not loaded. That means that before rearrange articles, I have to reload new 20 articles depending on new order.

This should done with Ajax.