This project is read-only.

IContentQuery API is confusing

Topics: Core
Feb 16, 2013 at 12:58 PM
This has bugged me for a long time: from an API-consuming standpoint how IContentQuery is built up is very confusing to me.
  1. The base IContentQuery doesn't contain anything really useful, just ForPart<TPart>() where TPart shouldn't be a ContentPart but IContent. This is very confusing as one could write ForPart<ContentItem>(), what indeed works (this is from DefaultContentManager what rather looks like an abuse of the API: query.ForPart<ContentItem>()). Why not call the type argument TContent and the method just For then?
  2. Similarly confusingly named is the type param of IContentQuery<TPart>.
  3. To make the confusion bigger ContentQueryExtensions.Query<TPart>() requires a TPart.
  4. It seems to me that all of the methods of IContentQuery<TPart> except for List() and Slice() should really be on IContentQuery.
  5. Why is WithQueryHintsFor() on IContentQuery<TPart, TRecord>? I see no reason (can't stress enough: from an API-consuming point of view) why I have to query for a part and record when I have to know nothing else about the type of the content items queried than just their name. This makes the following workaround necessary: query.Where<CommonPartRecord>(r => true).WithQueryHintsFor("MyType").
  6. Similarly I don't see why WithQueryHints() is on IContentQuery<TPart, TRecord>. When specifying query hints this way of course you know which parts and/or records build up the content type but why the unnecessary step for first querying for a record?
What do you think?