This project is read-only.

Onyx vs. Caliburn

Apr 9, 2009 at 11:29 AM
Edited Apr 9, 2009 at 11:31 AM
It would be very nice to compare Onyx and Caliburn. Looks like them both positioned itself s as WPF/Silverlight application frameworks with respect to MVVM pattern.
Apr 10, 2009 at 3:52 PM
They don't really compete (at least yet... Onyx is still Alpha and I'm still determining where the project will go, but I don't see much need in duplicating work from other projects).  Instead, they are compatible and would make a good team.  The same can be set for Prism. Onyx is focused on a specific portion of the M-V-VM pattern... providing services to the VM for interacting with the View in a decoupled manner.  It solves many of the implementation problems you run into when writing M-V-VM whether using your own framework, or an existing framework such as Caliburn and Prism.  In fact, I'm considering adding some samples that show how Onyx can fit in with both of these frameworks.

You can expect to see this topic documented in much more depth in some fashion in the future.
Apr 10, 2009 at 4:10 PM
Sounds great, thanks a lot! Looking forward to some samples and docs.

For example it would be awesome to see how could be solved with Onyx this particular issue "bind the selected items in a multi-select ListBox to a collection in the ViewModel" :)
Apr 10, 2009 at 4:30 PM
Let me break that one down with the ways I'd solve it (this was recently discussed by the WPF Disciples, BTW), in order of preference:

1.  Have the "items" in the ViewModel expose a Selected or similar boolean property that would be used to databind to the ListBoxItem.IsSelected property in the View. Sometimes it might be difficult to add such a property to the "items" in the ViewModel.

2.  Use an attached behavior.  I did this in an article I wrote for CodeProject.  I'm ashamed to publish this info here, as I rushed the CP article, and it's really not good.  However, it does illustrate how this is done, so:  Note that this was written early in my WPF learning, so be careful with anything you find in the code there.  This solution works nicely and requires no modification to the ViewModel "items".

3.  Use a service interface and Onyx to get the selected items.  I've considered implementing such a service, but since this is the last solution I'd use personally, I've been reluctant to do so.  This is one case in which I'd prefer the selection state to be exposed by the ViewModel, rather than use a service to query the selection state.

Currently, the focus in Onyx is mostly on implementing services, but I have been considering adding some behaviors as well.  If I do, the Selection.SelectedItems attached behavior from the CodeProject article would be a certain candidate for inclusion.  I know Prism doesn't offer a solution for this one, and it's been quite a while since I've looked at Caliburn.  Does Caliburn offer a solution here?
May 8, 2009 at 10:02 PM

Thanks for detailed answer. Actually options 1 and 2 are enough for me. The reason why I was asking about this sample with selected items is just because you mentioned about it in the introduction and I was thinking: "Is there something special that Onyx could offer to solve this popular issue in more elegant way?".

As for Caliburn - it doesn't offer special solution here too (well, at least I've not found it :). Anyway we are still have options 1 and 2.

I've looked briefly into sample project from Onyx's source code and I think that in general I've got the idea of Onyx (for example dialog boxes and focus). So far I was trying to avoid using code-behind files at all (using data templates as views everywhere) and all was good until I've not faced with need to set keyboard focus. Eventually I've found the way to accomplish what I want, but suspecting that for open/save dialogs there will be another contest for me. That's why I'm looked at Onyx and trying to realize how much this framework will suits me (i.e. "environment without code-behind files") OR how far should I step back and start using code-behind files to be able leverage Onyx power (particularly with keyboard focus and dialog boxes).

Also a bit of wiki documentation about provided services "out of the box" could be very handy for newcomers like me, since in the Onyx.Windows namespace there are pretty much interesting stuff.

May 8, 2009 at 11:54 PM

The idea behind Onyx is to provide that last bit of needed functionality necessary to really be able to eliminate the codebehind.  It will take some effort to implement services when they aren't provided by Onyx, but it shouldn't be too bad.  For instance, it is quite possible to create a service that would allow you to get the "View" of a child element in the same fashion that is used within the focus logic.  This View instance could then provide the necessary service for tracking selection.  Again, I'd probably go one of the other two routes, but the point is to illustrate that services really can provide you with pretty much ANY functionality that you'd use the codebehind for.

You're right, Onyx needs documentation (and not just Wiki).  I need to stabilize the API a bit before I go to far with that, though.  Getting close, I just need to iron out some issues with making Onyx IoC friendly.

May 9, 2009 at 4:43 PM

Thank you. Looking forward to the future of this project.