I have the following simplified example that I am trying to get working. I want to implement it like this to make it more maintainable as the list of exluded document types will grow to the extent that it doesn't seem right to have a long list of 'or' checks in the where clause if it can be helped.
var excludedDoctypes = new[] { "StaffMember", "StaffCategory" };
var items = node.Children.Where("!excludedDoctypes.Contains(NodeTypeAlias) && Visible").Where("Level <= 4");
Any ideas why this does not have the desired affect or am I just missing something really obvious?
I don't think Contains has been implemented in Umbraco's "dynamic" implementation of LINQ (ie. where the query is a string), hence the reason it won't work.
However, this should work:
var items = CurrentModel.GetChildrenAsList.Items.Where(x => !excludedDoctypes.Contains(x.NodeTypeAlias));
The reason is that CurrentModel is a strongly typed (DynamicNode) version of "Model" and hence you can perform standard LINQ to Objects queries.
Excluding Document Types in Where Clause
I have the following simplified example that I am trying to get working. I want to implement it like this to make it more maintainable as the list of exluded document types will grow to the extent that it doesn't seem right to have a long list of 'or' checks in the where clause if it can be helped.
Any ideas why this does not have the desired affect or am I just missing something really obvious?
TIA
Hmm perhaps an XPath is easier here. Here is an example where you can say which doc types are allowed:http://our.umbraco.org/forum/developers/api-questions/18933-Query-multiple-websites?p=2#comment74400. Probably easy to change so you can say which ones aren't allowed.
I use it for DAMP too: http://damp.codeplex.com/SourceControl/changeset/view/81602#1765791
Jeroen
I don't think Contains has been implemented in Umbraco's "dynamic" implementation of LINQ (ie. where the query is a string), hence the reason it won't work.
However, this should work:
The reason is that CurrentModel is a strongly typed (DynamicNode) version of "Model" and hence you can perform standard LINQ to Objects queries.
Yet another possible way I suppose:
is working on a reply...