Implementation of EntityCollectionView

Jan 29, 2010 at 4:03 PM
Edited Feb 2, 2010 at 2:51 AM

Hi,

Colin wrote that he'll potentially look into implementing a public EntityCollectionView for the WCF RIA Services Contrib project.

What scenarios is such an EntityCollectionView intended for and shall exactly be composed of?

Regards,
Kasimier

 

Feb 2, 2010 at 12:53 AM
Edited Feb 10, 2010 at 1:56 AM

Hi,

(this is a copy from the Silverlight forum)

In order to push the discussion with Colin & interested parties forward I published the bit of my CustomEntityCollectionView & Co. stuff at:

http://goodiesforria.svn.sourceforge.net/viewvc/goodiesforria/trunk/Casimodo/

You can download the code with a Subversion client (e.g. http://tortoisesvn.tigris.org) from:

https://goodiesforria.svn.sourceforge.net/svnroot/goodiesforria

The code comes under the MIT license and is intended for my personal library and amusement, plus potentially intended to be put into the WCF RIA Services Contrib project of Colin, if he finds something useful for him in my code. I already feel the pain of supporting a subset of my library in a different repository, but coders love pain, right?

[edited]

No, I love it, because it has the same effect as throwing any other code into the public domain: it makes me feel much more responsible wrt my code, so I'll put an additional lovely effort to keep it fine.

[/edited]

I'll add a 'SimpleExampleDataSource' tomorrow in order to demonstrate how this can be put together in order to build something similar to the DDS but purely directed for MVVM usage.

Regards and don't let yourself get down by the damn cold weather (I almost fell on my nose on my way home today),

Kasimier

Feb 2, 2010 at 5:16 PM

OK, the 'SimpleExampleDataSource' is now available in the repository.

Regards,
Kasimier

Feb 8, 2010 at 5:43 PM

- Added tests for ICollectionView and IEditableCollectionView using System.Windows.Data.PagedCollectionView as reference implementation.
- Refactoring, bug-fixing and enhancement.

Regards,

Kasimier

Feb 10, 2010 at 12:20 AM
Edited Feb 10, 2010 at 12:56 AM

I'm trying to elaborate on my own question: "What scenarios is such an EntityCollectionView intended for and shall exactly be composed of?"

While trying to anchor more functionality related to the removal of entities in my CustomEntityCollectionView (and CustomEntityCollection), I noticed that it's quite unclear what the expected behavior shall be. I always handled removal of entities seperately, i.e. *deletion* of existent entities (different from cancelling newly added entities) was handled seperately via a mechanism outside the realm of the CustomEntityCollectionView.
Same with IRevertibleChangeTracking which - in the CustomEntityCollection - seems only to make sense if applied to the scope of the currently existent items in the view/collection.
I hope this makes sense.

Hmm, I'll try to explain further:

AFAIK, if one has an existing entity (i.e. fetched from the server) in the EntitiySet, and one performs a Remove() on that entity, then it is marked for deletion and is tried to be deleted during the next SubmitChanges() transaction of the DomainContext. If one performs RejectChanges() then the 'deleted' mark is erased. All fine.

In contrast, if one does a Remove() in the context of a CustomEntity-CollectionView/-Collection then what shall this mean?
A CustomEntity-CollectionView/Collection is actually a view/collection over an EntitySet. Do we want the removed entities in this context to be 'deleted' or just removed from the view/collection?
Further, if items are removed from the view/collection and then an RejectChanges() on the collection is performed, shall those removed items magically reappear in the view/collection? I currently don't think so.

I noticed that I can control the behavior wrt deletion in my EntitySourceAdapter (currently either EntitySetSourceAdapter or SharedEntitySetSourceAdapter) in order to inject the behavior I want. But I currently don't know whether it's practical to anchor such real 'deletion' of entities there at all or not.

Input and ideas are appreciated.
Maybe good ol' Colin will be ready to provide some input when he's finished with his plan to discuss the issue with the people at the next MIX.
Until then a bit of poke: c'mon brother Colin, you don't need MIXies in order to let your thoughts pour into the keyboard wrt experimental and fun-to-code thingies like this ;-) - still np if not.

Regards,
Kasimier Buchcik

Feb 10, 2010 at 1:25 AM
Edited Feb 10, 2010 at 1:42 AM

I would also like to express another reason for the existence of my CustomEntityCollection and EntitySourceAdapter:

In the future, I would like to be able to put together my entity collections and adapters in a pipeline/decorator way:

I.e. a pipeline of collections could be defined like the following:
1) EntitySet
2)  --> (Shared)EntitySetAdapter
3)    --> LoadedEntityCollection (used by a 'SimpleEntityDataSource' [similar to a DDS] in order to load entities from the server)
4)      --> CollectionEntitySourceAdapter - not implemented yet
5)        --> CustomEntityCollection (here I can define local filters/sorting/grouping)
6)            --> repeat (4-5) until you get bored (i.e. define as many adapters --> collections as you want)
7)                 --> CustomEntityCollectionView (the view that is finally used for display in e.g. XAML)

This means that - in the future - I would like to be able to add as many CustomEntityCollection(s) I want on top of another (i.e.  add to the pipeline; i.e. add decorators) in order to define specific behaviors at specific points in the pipeline - and I think that would be fine, because it also rhimes with pipeline, so it must be fine and that's what we sing in the chorus line.


Regards, read carefully and don't get confused,
Kasimier Buchcik

Coordinator
Feb 18, 2010 at 5:00 AM

I think there are two main scenarios that are trying to be covered:

1) To create something exactly like the PagedCollectionView that is strongly typed and supports adding and deleting from a base EntitySet or EntityCollection
2) To create something which has all of the abilities of the DDS but in a non-XAML format.

SLAdapter on the RIA Services forum has some interesting comments here about wanting to support GroupDescriptor/FilterDescriptor/SortDescriptor which after further thought seems to indicate a completely different class of object. It isn't really a CollectionView, it is like the DDS but in a non-XAML format. I am having trouble coming up with a good name for it.

Coordinator
Feb 18, 2010 at 5:06 AM
Casimodo72 wrote:

I'm trying to elaborate on my own question: "What scenarios is such an EntityCollectionView intended for and shall exactly be composed of?"

While trying to anchor more functionality related to the removal of entities in my CustomEntityCollectionView (and CustomEntityCollection), I noticed that it's quite unclear what the expected behavior shall be. I always handled removal of entities seperately, i.e. *deletion* of existent entities (different from cancelling newly added entities) was handled seperately via a mechanism outside the realm of the CustomEntityCollectionView.
Same with IRevertibleChangeTracking which - in the CustomEntityCollection - seems only to make sense if applied to the scope of the currently existent items in the view/collection.
I hope this makes sense.

My feeling is that the PagedCollectionView is the baseline for setting rules. However, my plan is to reuse the original RIA Services code as much as possible so however the DDS does it will probably be the rule.

Mar 23, 2010 at 11:50 PM
Edited Mar 23, 2010 at 11:51 PM

- Added initial support for FilterDescriptor/FilterDescriptorCollection, because I tend to think that this together with the SortDescriptor thingy will eventually be exposed as an interface by MS - similar to the ICollectionView.SortDescriptions/GroupDescriptions. IOW: I think it is important to have it.

- Added initial support for filter properties which are properties annotated with an attribute which corresponds to the FilterDescriptor. Such filter properties are intended for the VM in order to replace the FilterDescriptor definitions via XAML, plus allow for easy binding.

The whole story of supporting an Open-Source subset of my tiny Entity thingies is slowing me down too much, so I'll publish all the related stuff in the near future. Although I'm not confident with some parts of this code, it will be much easier for me than trying to support two different repositories.

By the way: I tried today using the DDS as the underlying engine for my stuff. It works, but I would have to drop all the nice extra features which are relying on full control over the IPagedCollectionView/IEditableCollectionView/ICollectionVIew. I don't want to do that. So I'll stick to my own implementation and will work on it in my spare time. Actually an interesting hobby I threw myself into :-)

Regards,

Kasimier Buchcik

 

 

Coordinator
Mar 24, 2010 at 1:29 AM

Cool. One of the things added to SL4 which I couldn't discuss before is the ICollectionViewFactory interface. You may want to take a look at it. I was also thinking about wrapping the DDS so interesting you have looked at it.  I have someone else that may be looking at doing something in this space but I am waiting for confirmation that he can. I will keep you updated.

Mar 31, 2010 at 3:37 AM

Some links to ICollectionViewFactory:

http://bea.stollnitz.com/blog/index.php?s=collectionviewfactory (lovely)

http://msdn.microsoft.com/en-us/library/system.componentmodel.icollectionviewfactory(VS.96).aspx

But I'm not getting it yet. Where is the connection between ICollectionViewFactory and the DDS (if there there is meant to be any) and how is this useful for us?

Could you elaborate on this?

Regards,

Kasimier Buchcik