Confused with the model philosophy

pstjean · October 19, 2011, 4:06pm

Perhaps this is going to sounds stupid, but I have difficulty to understand how the model node and link should be integrated with an existing datamodel. In the documentation, it says that my data class that supposed to be a node only have to inherited from GraphLinksModelData.

For example, supposed that in my datamodel I have a class called Person an another one called Relation. If Person and Relation already inherit from another Base class, I can’t inherited from GraphLinksModelData and GraphLinksModelLink… Is this how it’s supposed to work?

Or should I specify instead something like that GraphLinksModelData(Of Person, String)?

Ps.: Sorry for the poor english, that’s not my first language.

walter · October 19, 2011, 4:24pm

You don’t need to inherit from GraphLinksModelNodeData and GraphLinksModelLinkData.
They are just there for your convenience.
However the more that you do implement, the better the experience will be.

You’ll want to be implementing real .NET properties.

If any of the properties might change dynamically, you’ll want to implement INotifyPropertyChanged .

If you want to support undo/redo in GoXam, you’ll want to use ModelChangedEventArgs instead of PropertyChangedEventArgs when raising the PropertyChanged event.

If you use collections, you’ll want to use collections that implement INotifyCollectionChanged.

If you’re on WPF and want to support the clipboard, you’ll want to make it Serializable.

PS: not to worry, your English is fine, and English isn’t my first language either.

pstjean · October 19, 2011, 4:29pm

The thing is, even if I want to inherit from GraphLinksModelNodeData/GraphLinksModelLinkData, I can’t, because my data classes already inherit from other base classes. But even if I could, I’m not sure if I want to mix data properties with UI properties.

walter · October 19, 2011, 4:34pm

I was just trying to say that you don’t need to inherit from our …NodeData classes. You can use you own classes, but the more features that you implement that are standard in WPF/Silverlight applications, the better your experience will be.

If nothing else, you’ll need to specify some of the model properties whose names end with “…Path”, or you’ll need to override the corresponding model methods if the needed information isn’t available as a .NET property.

pstjean · October 20, 2011, 9:52am

I know what I will do. To benefit of all the features of the GraphLinksModelNodeData, I will create a class inheriting from that it and encapsulate my nodeData inside. I will only bind the key property to my nodeData key path property. I don’t know why i didn’t thought to that before. Well, thank for your clarification Walter, really helpful.

walter · October 20, 2011, 9:57am

That can work, but for all of the reasons I listed earlier in this topic, I’m not sure that you’ll get the best result.

It depends on how much you can change the implementation of your existing classes, if you need particular WPF/Silverlight data-binding features.

You can probably get the results you want by overriding the model methods such as FindKeyForNode if setting NodeKeyPath is not feasible.