Hi. You mean "Razor" saying "C#", don't you? Then e.g.:

var count = Library.NodeById(5164).MemberLooks.Where("Category.ToUpper().Contains(@0)", cat.ToUpper()).Count();

Hi, well i havent used razor before but if it works ill try it. What you posted however doesnt seem to work. what namespaces should be referenced for it to work?

Hi. What error are you reported?

Perhaps the 'MemberLooks' children should be accessed via camel-case:

var sectionRoot = Library.NodeById(5164);
var filteredMemberLooks = sectionRoot.memberLooks.Where("category.ToUpper().Contains(@0)", category.ToUpper());
var filteredMemberLooksCount = filteredMemberLooks.Count()

As a side note, when comparing strings in this manner you most likely should always use 'string.ToUpperInvariant', to avoid culture sensitivity in matches - not sure Umbraco 5 supports it, though.

I don't think so - as far as i remember dynamic properties in umbraco are case-insensitive.

You can also try to rewrite it without child-plural syntax, sort of:

Library.NodeById(5164).Children.Where("NodeTypeAlias = @0 and Category.ToUpper().Contains(@1)", "memberLook", cat.ToUpper()).Count()

Oh, 'AND' support? How counter-intuitive!

When I started with v5 I instinctively tried '&&' and '||' (as one would expect to work, given the C# and Linq-style environment), neither of which worked.

I won't believe this works until I see it, though. (;

Update:

Part 4 of the Razor walkthrough states that boolean logic works in the standard ampersand and pipe form:

Using string comparisons and boolean logic (|| [or], && [and]) - also shows how to nest strings

@Model.Children.Where("menuType == \"Top Menu\ || menuType == \"Bottom Menu\"")

There isn't an example on that page using text-based equivalents 'and' and 'or'.

Also note that Part 3 of the Razor walkthrough mentions that:

Warning: the property access is case sensitive. Make sure you check your case.

Granted, this is in the 'Xml Properties' section, but one would expect conventions to be followed consistently.

That's dynamic LINQ statement parsed in the runtime - they support both "&&" and "and" tokens if I'm not wrong.

I know what it is, I'm saying the format is counter-intuitive.

Yeah, I've just checked it - I was wrong talking about case-insensitivityness though not completely. It's actually case-sensitive but not to the case of the first letter of a property name. I thought so since actually have never got a reason to alter letter cases other than one of the first letter.

is working on a reply...