QueryableDomainServiceCollectionView and TreeListView

[Rob Conley]

Just curious about something.

When I want to display new data, I set the QueryableDomainServiceCollectionView backing the TreeListView to null. This triggers a GET on the MVVM VM property and the data is reloaded. I then often times automatically expand one first level item on demand by setting IsExpanded to true in the view model (after the first level is finished loading).

I was very confused that sometimes second-level processing was not occurring after a reload. I deduced that it was only when certain actions led to asking for the same information that had originally been loaded into the TreeListView (before nulling it out). The problem was that while the first and second level data was there, the second-level data wasn't being searched and highlighted as no even was triggered saying that it was done loading.

Turns out, the QueryableDomainServiceCollectionView is apparently using the data it already had from the previous load and thus the second-level data was not being fetched from the database and triggering load events.

Just wondering if this should be expected. After setting the QueryableDomainServiceCollectionView to null I would expect the first level information to be gone and certainly the data that was loaded programmatically "on demand" should be gone to. But, it's all there. Very smart of it, actually, just unexpected. I mean, I really don't want it to "remember" the second level data, but I can't think of any harm done.

Should all of this be expected? Thanks.

-Rob

[Rossen Hristov]

Hello,

In fact the QDSCV does almost nothing -- it is WCF RIA Services that do everything.

The QDSCV has two important things -- the Load method and the AutoLoad property.

When you call the QDSCV.Load() method manually, the QDSCV will simply call the DomainContext.Load(query) method and send a request to the server. When data comes back it will fill itself with the entities that came from the server.

When the AutoLoad property is true, every change that somehow affects the EntityQuery will trigger a load from the server, i.e. just like calling the Load method manually. Those changes include filtering, sorting and paging.

The QDSCV can only contain one kind of entities, i.e. one entity set. If you want to load related entities, you can do this either with other QDSCV's or by using the Include attribute.

The main point here is that the QDSCV does absolutely nothing beyond building an EntityQuery<T> based on the current filtering, sorting and paging criteria and then simply calling the DomainContext.Load method. All of the job is actually done by WCF RIA Services.

All the best,
Rossen Hristov
the Telerik team

[Rob Conley]

I am loading the second-level on demand, building a collection of the same time as the 1st level, and adding it to the base collection.

I was just surprised to see that my "load on demand" second-level items were being "remembered" when I reload the first level. I guess RIA is doing this when it returns cached first-level data. I hope I can count on this always being the case.

[Rossen Hristov]

Hello,

If you attach to the LoadingData event, you can change the LoadBehavior through the event args. Maybe this is what could be making the difference.

Regards,
Rossen Hristov
the Telerik team

[Rob Conley]

Thanks; I was wondering how that might be done.