One modification to my original proposal. In fact, the OnCollectionChanged method should be virtual instead of abstract, with an empty default implementation. This is taking into consideration that it will only be of importance when change notification is desired. People not interested in change notification won't want to bother with it.
Yes, please take a look at my blog post. You will see that my PersistentObservableList<T> and PersistentObservableBag<T> classes both contain an OnCollectionChanged method as described above (PersistentObservableSet<T> has one that's slightly different, but it could be refactored). The solution I created has been working fine for NH 1.2 through 2.0. The problem is in NH 2.1, as described in my original post, since collection methods are being explicitly implemented. Figuring out which (non-virtual) methods to override has already been a process of hacking. Adding my OnCollectionChanged() method to AbstractPersistentCollection would be great since this kind of override hacking with every new NH version would no longer be necessary. Well, if you want to consider different implementations, the only significant variation I can think of is a separate OnCollectionXXX() method for each modification type. The upside of that would be to rid you of the NotifyCollectionChangedAction enum, which you might consider WPF-specific. The downside is that overriding all those methods is much more verbose than overriding just one, but acceptable nonetheless since they would be in a dedicated subclass anyway. Another option would be to find/make another GUI-neatral enum with more-or-less the same values as what's in NotifyCollectionChangedAction. BTW, yes, I did log into JIRA just today for uploading a unit test, although for an issue not related to the current thread. Do you want me to create an JIRA issue regarding this request as well? On Nov 26, 10:23 pm, Stephen Bohlen <[EMAIL PROTECTED]> wrote: > HappyNomad: > > Oh, and have you logged this with the NHibernate JIRA yet--? > (http://jira.nhibernate.org) > > On Wed, Nov 26, 2008 at 10:22 AM, Stephen Bohlen <[EMAIL PROTECTED]> wrote: > > HappyNomad: > > > I will take a look @ the blog post you mention in your initial post and see > > what we can consider doing that will support the GOAL you have of ensuring > > that there is a way to observe changes to collections. The implementation > > may (in the end) be something different than specifically what you are > > proposing, but the intent of what you are after seems reasonable (to me). > > > And for the record, I have to credit Gustavo for chiming-in > > on UI-neutrality being a cornerstone of any implementation to address this > > need. [?] > > On Wed, Nov 26, 2008 at 10:15 AM, HappyNomad <[EMAIL PROTECTED]>wrote: > > >> Stephen, we are definitely in agreement here. Your point about making > >> the solution UI-neutral is a great one. And in fact the idea I > >> already have in mind, to include my OnCollectionChanged() method, is > >> in fact UI-neutral. In my original post I just offered to take it one > >> step further by also implementing INotifyCollectionChanged. But if > >> that isn't UI-neutral then I will gladly accept refraining from taking > >> it that far. > > >> On Nov 26, 10:03 pm, "Stephen Bohlen" <[EMAIL PROTECTED]> wrote: > >> > Actually, if you look really closely you will see that... > > >> > 1) yes, .NET 3.5 supports these interfaces for change notification > >> > 2) under 3.5 there are DIFFERENT notification interfaces that you need > >> to > >> > implement to properly participate in WPF than in winforms (the source of > >> my > >> > statement that several of these are 'UI specific' > > >> > If you are building your own UI in a technology of your own design, then > >> you > >> > can choose which of the notification interfaces you are interested in > >> > implementing in your objects and (presumably) your own UI technology > >> would > >> > be able to similarly 'choose' which of these events to subscribe to. > >> But if > >> > you are choosing WPF vs. WinForms, you DO have a different set of > >> interfaces > >> > that your objects must implement in order to 'participate' in the rest > >> of > >> > the UI environment that you have chosen. > > >> > If you look very closely at the docs (even for 3.5) you will actually > >> see > >> > that while (of course) all of these interfaces are in the end 'just .NET > >> 3.5 > >> > interfaces', the ones your objects need to implement actually DO change > >> > depending on which UI platform you are targeting with them. Again, I > >> direct > >> > you to Rocky's latest CSLA treatise where he explores at length the > >> (subtle) > >> > differences between the change-event-notification models in WPF, > >> winforms, > >> > and even Silverlight. > > >> > Without getting of on a wild tangent here, I would just restate my > >> opinion > >> > that the answer (in my mind) is to ensure that the right extensibility > >> > points and overridable behaviours are provided for so that anyone can > >> > intercept and wire up any specific needed eventing points as they might > >> need > >> > to support ANY change-notification-model they my see fit to choose > >> (which, I > >> > think, is sort of what you were advocating in the first place, no?) > > >> > On Wed, Nov 26, 2008 at 9:54 AM, HappyNomad <[EMAIL PROTECTED]> > >> wrote: > > >> > > I would like to point out that NH 2.1 itself targets .NET 3.5. And > >> > > INotifyCollectionChanged is part of .NET 3.5. INotifyPropertyChanged > >> > > and INotifyCollectionChanged is a general mechanism in .NET for making > >> > > objects observable. It is NOT part of a "specific UI model". Sure, > >> > > WPF uses these interfaces, but it could be used for other GUI > >> > > frameworks as well. It could even be used for non-GUI frameworks > >> > > which observe the domain model. > > >> > > In any case, the bare minimum I am asking at the moment is add this > >> > > template method to AbstractPersistentCollection: > >> > > protected abstract void OnCollectionChanged > >> > > ( NotifyCollectionChangedAction action, object changedItem, int > >> > > index ); > >> > > and then call it from all of its subclasses, whenever the collection's > >> > > contents are modified. This wouldn't be adding observability per se > >> > > (although it's not far from it I admit). > > >> > > On Nov 26, 9:33 pm, "Gustavo Ringel" <[EMAIL PROTECTED]> > >> wrote: > >> > > > I think the task of the persistence layer is not to be bindable to > >> an > >> > > > specific UI model...or to inform about something to an specific UI > >> model. > >> > > > So for sure it is not part of the core. > >> > > > It may be an extension to put in the contributions... > > >> > > > Gustavo. > > >> > > > On Wed, Nov 26, 2008 at 4:29 PM, Fabio Maulo <[EMAIL PROTECTED]> > >> > > wrote: > >> > > > > 2008/11/26 HappyNomad <[EMAIL PROTECTED]> > > >> > > > >> NH 2.1 targets .NET 3.5, and > >> > > > >> observability is a fundamental feature of .NET 3.x, so I think > >> the > >> > > > >> best way to solve this problem is to incorporate observability > >> into > >> > > > >> the NH core. > > >> > > > > Sure... and sure we will add INotifyProperyChanged, and a base > >> class to > >> > > > > work with lazy-loading and INotifyCollectionChanged and probably > >> > > > > IBindingList implementation. > >> > > > > Be sure about that. > >> > > > > -- > >> > > > > Fabio Maulo > > > > 32A.png > < 1KViewDownload
