|
|
Browse by Tags
All Tags » CSLA .NET;WPF (RSS)
Sorry, but there are no more tags available to filter with.
-
Another place where I was able to reduce business object code in CSLA .NET 3.5 was to effectively eliminate the GetIdValue() method. Prior to version 3.5, GetIdValue() was required, and you had to provide a unique value identifying your object. This value was used to implement Equals() and GetHashCode(), and was used as the ToString() value. This was good, because it enabled the concept of logical equality , where objects were equal to each other based on their id value. For better or worse, WPF doesn't support logical equality. They only support absolute equality - ideally implemented by comparing all properties of the two objects so two objects are only equal if all their properties are equal. A poor man's replacement is to use reference equality - which is much faster but is technically less accurate. The effective default in .NET is reference equality. CSLA .NET 3.5 no longer overrides Equals() or GetHashCode(), so it now uses the .NET default behavior. This makes WPF happy. This might break some people's existing code (though a poll on the forum indicates it is a non-issue for virtually everyone), because there is no longer any idea of logical equality unless you implement it yourself. The upside though, is that you no longer need to override GetIdValue(). I left the method in the framework for backward compatibilty, so if you do override it your code will continue to compile (though the value is now only used in a ToString() override). For more information go to www.lhotka.net . Read More...
|
-
I'm psyched! I finally figured out how to get the Csla.Wpf.CslaDataProvider control to support a Delete command that removes child items from a databound list object. As you might expect, the answer to the problem was staring me in the face the whole time - I just didn't see it. Isn't that the way things often work? ;) Since day one, CslaDataProvider has support the Save, Undo and AddNew commands (using XAML commanding), so it has been possible to create Save, Cancel and Add buttons on a form purely through XAML - no code-behind required at all. Now, with this new change it is also possible to implement a Remove button in a DataTemplate with no code-behind. The button can use the standard Delete command to tell the CslaDataProvider managing the BusinessListBase object to remove the child object bound to that row in the DataTemplate. The XAML looks like this: <DataTemplate x:Key="lbTemplate"> <Grid> <StackPanel Orientation="Horizontal"> <TextBlock>Id:</TextBlock> <TextBox Text="{Binding Path=Id, Converter={StaticResource IdentityConverter}, ValidatesOnDataErrors=True}" Width="100" /> <TextBlock>Name:</TextBlock> <TextBox Text="{Binding Path=Name, Converter={StaticResource IdentityConverter}, ValidatesOnDataErrors=True}" Width="250" /> <Button Command="ApplicationCommands.Delete" CommandParameter="{Binding}" CommandTarget="{Binding Source={StaticResource RoleList}, Path=CommandManager, BindsDirectlyToSource=True}" HorizontalAlignment="Left">Remove</Button> </StackPanel> </Grid> </DataTemplate> The key was realizing that the CommandParameter could be bound to the entire object that is represented by this DataTemplate - the individual row object. This revelation meant that the CslaDataProvider control can in fact remove that item because an equality comparison is possible. So ApplicationCommands.Delete passes the child object reference to the data provider, which removes the item from the databound list object and that's it! So this means you can now create a typical maintenance screen with no code behind the XAML. None. You have to write zero lines of VB/C#. Too cool!! And it means that even on a more complex screen you still don't need to write save/cancel/add new/remove code. That's a lot of code savings! Often all you need to write is code dealing with navigation from this screen to some other screen, perhaps some exception handling code (which I put in a base class) and some Read More...
|
-
Earlier this week I co-presented a session at ReMIX in Boston, with Anthony Handley, a fellow Magenicon . Anthony is a User Experience Specialist, and the two of us have been working on a WPF/Silverlight project (that also happens to use CSLA .NET of course :) ) and in this presentation we discussed our experiences using WPF from the perspectives of a developer and a designer. Here are the links to the video of the session. Real World Experiences Building Applications Using WPF and Silverlight Part 1 http://channel9.msdn.com/Showpost.aspx?postid=346810 Part 2 http://channel9.msdn.com/Showpost.aspx?postid=346812 Part 3 http://channel9.msdn.com/Showpost.aspx?postid=346815 Part 4 http://channel9.msdn.com/Showpost.aspx?postid=346818 For more information go to www.lhotka.net . Read More...
|
-
In CSLA .NET 3.0 I implemented Csla.Wpf.Validator. This control provides functionality similar to the Windows Forms ErrorProvider control, only in WPF. Of course the ErrorProvider relies on the standard IDataErrorInfo interface, which CSLA supports on behalf of your business objects, and so my Validator control used that same interface. While I was researching and designing the Validator control, I was in contact with the WPF product team. As a result, I had (shall we say) a "strong suspicion" that my control was a temporary stop-gap until Microsoft provided a more integrated solution. And that's fine - we needed something that worked, and Validator was the ticket. This blog post provides some good, detailed, insight into the real solution in .NET 3.5: Windows Presentation Foundation SDK : Data Validation in 3.5 A couple people have emailed me, asking what I think about this. My answer: I'm happy as can be! As I say, I knew Validator was temporary. WPF is a version 1.0 technology, and it is very clear that Microsoft will be evolving it rapidly over the next few years. And it is equally clear that WPF must evolve to catch up to, and hopefully exceed, Windows Forms. That means more robust data binding support, including an ErrorProvider equivalent. So to me, this just means that CSLA .NET 3.5 can drop the Validator control, because there's now a directly supported solution in .NET itself. While this will require changing XAML when moving from .NET 3.0 to 3.5, it is a worthwhile change to make. For more information go to www.lhotka.net . Read More...
|
-
I just got back from VS Live NY - which was a great show. It sold out, and the people attending were very engaged and fun to be with. I love crowds like that! In my all-day workshop on building distributed apps using objects I showed how to use WPF commanding to automatically enable/disable Save and Cancel buttons on a form by connecting them to a CslaDataProvider control. That's a really cool feature of WPF that I am leveraging with some of the new CSLA .NET 3.0 features. An attendee asked if it was possible to hide the Save button, not just disable it. I hadn't thought about that, and came up with some answer involving code. Josh Smith, who was also in the audience, has given this even further thought and sent me an email with a better, pure XAML, solution. Thank you Josh!! Here's the relevant bit of the email: During the presentation a fellow asked you how, in WPF, to hide a Button when it is disabled. The Button was disabled because its associated command could not execute, and he wanted to hide the Button instead of letting it sit in the UI disabled. The solution you gave him involved some code, which threw a red flag in my mind. IMO, this is the kind of thing you should use XAML to express, so that there are less "moving parts" in your app. Here's one way to implement that functionality with no code at all: <Button Command="Open" Content="_Open"> <Button.Style> <Style TargetType="Button"> <Style.Triggers> <Trigger Property="IsEnabled" Value="False"> <Setter Property="Visibility" Value="Collapsed" /> </Trigger> </Style.Triggers> </Style> </Button.Style> </Button> Depending on your layout, you might want to set Visibility to Hidden instead. For more information go to www.lhotka.net . Read More...
|
-
A CSLA .NET user, Aaron Nottestad, has been helping test 3.0 and ran into some issues when using the new WPF CslaDataProvider with editable objects. Thanks Aaron! As a result, I had to do some work with CslaDataProvider, so it can manage the object’s entire lifetime from create/fetch through to save/cancel. If it can’t manage the lifetime, especially the save, then it can’t get the new object that comes back as a result of save. And if it doesn’t get that new object, then neither does data binding, so the UI controls end up editing an old instance of the object. So the CslaDataProvider now has Save() and Cancel() methods that you can call to trigger saving or canceling of the business object. Also, as the object is created/fetched CslaDataProvider automatically calls BeginEdit() on the object. This behavior is all optional, and is controlled by the ManageObjectLifetime property of the CslaDataProvider control. So if you want this behavior, you have to set that property to True. If you leave it at False (the default), then you must manage everything through code – though honestly you can’t manage editable objects through code while using CslaDataProvider. So maybe I should make the default be True? Hmm. Anyway, this was easy enough to do and worked great. The resulting forms had exactly 4 lines of code – 2 to call Save() and 2 to call Cancel(). It occurred to me that there must be a way to avoid writing those 4 lines of boring code, and Aaron put me onto the RoutedCommand concept in XAML. A RoutedCommand allows a control like a button or menu item to invoke a method on another control – purely through XAML. There are many examples out there about how this works to create standard Copy/Paste menu items that run against the current TextBox control, and that sort of thing. But none that I found which routed a command to a data provider control. The reason turns out to be that the target of a command must be a UIElement, and data providers don’t inherit from that base class. Oops… I thought I was stuck, because I really do want to route the command to CslaDataProvider in this case. However, I figured out a solution. CslaDataProvider now has a read-only CommandManager property. This property exposes a “command manager” object which does inherit from UIElement and which does handle the Save and Undo routed commands. When it is created by CslaDataProvider, it is given a reference to the CslaDataProvider control, so it simply delegates all Save commands to the CslaDataProvider.Save() Read More...
|
|
|
|