Working examples

[bujma]

We would like to start using the CSLA .NET. We started with the book "Expert C# 2008 Business Objects" and would like to explore the concepts in some working examples but currently we are not able to find any that's working (e.g. for the stable version 5.5.2). Where can I get some reference to sources of working WPF applications as complex as ProjectTracker (PT) is or more (views, viewmodels, data access layer, data portal) until PT WPF is fixed? (I assume CSLA .NET 5.5.2 is working, just PT WPF is not.) Thanks much.

[rockfordlhotka]

I hear you!

The problem is time. I've been working on CSLA 6, just doing some bug fixes and high priority updates to CSLA 5 for quite some time - and you are right, I haven't had time to update the CSLA 5 samples accordingly.

What I really need is more folks contributing to the project overall, and the samples specifically.

I'll be honest, I don't anticipate having time to go back and work on CSLA 5 samples, as I'm working on the CSLA 6 release and sample updates, and that's consuming the time I have available.

[rockfordlhotka]

I'm afraid I don't have a great answer, sorry.

You can look at the Using CSLA 4 book, which includes content on WPF. Unfortunately that content is from CSLA 4, and so is somewhat out of date - though WPF hasn't changed in any meaningful way since then. So all the content about data binding and so forth remains consistent.

The big thing is that CSLA 5 (and even more, CSLA 6) embraces dependency injection, and that optionally can have a big impact on how you build a WPF app (in general, not just with CSLA).

CSLA 5+ also supports async/await, especially the data portal. That is also a big shift, though not at a UI/WPF level, but it is way simpler to use than the old Begin/End/callback async approach used in CSLA 4.

The (free) Using CSLA 2019 Overview book doesn't address any specific UI, but does provide some context and info about the CSLA 5 data portal and coding model.

[rockfordlhotka]

In terms of a CSLA 6 timeframe, I think we're just wrapping up the last couple known issues, and I've been working on all the more basic samples to get them updated to CSLA 6. My plan then, is to work on ProjectTracker - hopefully toward the end of March.

[bujma]

Thanks much for your answers.

I've learned a lot from "Expert C# 2008 Business Objects", still a lot remains unexplored 😃. I will go through the CSLA 2019 Overview too as you suggest.

Regarding mentioned features (DI, async/await in data portal): I already use them in my BOs made by "cloning" and modifying v5.x sources of PT: I can create a new item, edit existing one loaded from mock in-memory DB. And there it ends, just on saving, where the error "Object is still being edited..." appears. The same way as in PT itself, where the ProjectEdit.EditLevel=2 immediately after creation, before any change is made...

I am looking forward the CSLA 6 release, good luck.

[rockfordlhotka]

EditLevel defaults to 0. It is increased by calls to BeginEdit.

In WPF that's not automatic (the UI framework doesn't do it), though some controls might (especially datagrid controls).

The Csla.Xaml.ViewModel has an option to automatically manage object lifetime. If this is turned on (maybe by default?) it will call BeginEdit on your behalf, with the intent of making it easy to implement Cancel and Save buttons. The ViewModel will call CancelEdit and ApplyEdit respectively as the cancel/save operations are invoked.

For the EditLevel on the root to end up at 2 means that BeginEdit has been called on the root object twice, with no intervening cancel/apply call.

Could there be an explicit BeginEdit call in the UI code? Or somehow there's a nested ViewModel?

[bujma]

Yes, I found all that info in the book, thanks for summing up here, now I know I understand it well and where to focus. I just thought the PT in the v5.x branch (and using the almost latest CSLA 5.5.1) will work "as is" as the main sample.

Yes, ManageObjectLifetime is true by default.

EditLevel (in the PT) is raised first time in ProjectGetter(: ViewModel).OnModelChanged and second time in ProjectEdit(: ViewModelLocalEdit).OnModelChanged, in both cases in base.OnModelChanged(oldValue, newValue); call on the first line.

csla/Samples/ProjectTracker/ProjectTracker.Ui.WPF/ViewModels/ProjectEdit.cs

Lines 27 to 31 in dfaf152

	protected override void OnModelChanged(ProjectTracker.Library.ProjectEdit oldValue, ProjectTracker.Library.ProjectEdit newValue)
	{
	base.OnModelChanged(oldValue, newValue);
	OnPropertyChanged(nameof(ProjectEditViewModel));
	}

csla/Samples/ProjectTracker/ProjectTracker.Ui.WPF/ViewModels/ProjectEdit.cs

Lines 69 to 74 in dfaf152

	protected override void OnModelChanged(ProjectTracker.Library.ProjectEdit oldValue, ProjectTracker.Library.ProjectEdit newValue)
	{
	base.OnModelChanged(oldValue, newValue);
	Model.Resources.CollectionChanged += (o, e) => OnPropertyChanged(nameof(ProjectResourceList));
	OnPropertyChanged(nameof(ProjectResourceList));
	}

After realizing that, I set ManageObjectLifetime to false in the ProjectGetter's constructors, since its ViewModel superclass is not meant to be edited and saved (I understand it this way) but the ViewModelLocalEdit superclass of ProjectEdit is.

Result: EditLevel is raised just once in ProjectEdit.OnModelChanged, SaveAsync executes without an error.
I just wonder if it is the right fix or just my workaround.

Note: While debugging I was inspecting the EditLevel of the newValue and Model in both OnModelChangeds multiple times and to my surprise it (the EditLevel) was increasing without executing any additional code to a value of 3 to 6, sometimes more, depending on the way I inspected it.