|
|
Browse by Tags
All Tags » CSLA .NET;Microsoft .NET (RSS)
Sorry, but there are no more tags available to filter with.
-
I rather expected this - a bit of confusion around .NET versions and related CSLA .NET versions. Microsoft started the whole thing by calling .NET 2.5 version 3.0. Oops, did I say that out loud? :) But it is true. From a .NET programming perspective, 3.0 is purely additive over 2.0. Thus it is really hard to see why it is a major version. Especially when .NET 3.5 has a much bigger impact on day-to-day use of .NET, but is just a point release... If anything, this should have been .NET 4.0, but it isn't and so now we're all royally stuck in the land of confusion. Nothing to do but make the best of it. I know several people and organizations who ignored .NET 3.0, but are now looking to move to .NET 3.5. Effectively "skipping" 3.0, though the reality is that their move to 3.5 is also a move to 3.0. Personally I think that's smart - they saved themselves a year of pain by not trying to use .NET 3.0 with the limited tools available, and can now move to 3.0/3.5 with Visual Studio 2008 - so they have decent tool support for the technology. When it comes to CSLA .NET, here's my take on it: CSLA .NET 1.5.3 - latest version for .NET 1.x CSLA .NET 2.1.4 - effectively obsolete CSLA .NET 3.0.3 - latest version for .NET 2.0 and .NET 3.0 CSLA .NET 3.5.0 - in-progress version supporting .NET 3.5 At this time I do not anticipate being able to make CSLA 3.5 work without .NET 3.5, primarily due to use of new compiler features as well as LINQ and features in .NET 2.0a and 3.0a (aka .NET 2.0 SP1 and 3.0 SP1). For more information go to www.lhotka.net . Read More...
|
-
I posted previously about an issue where the WCF NetDataContractSerializer was unable to serialize a SecurityException object. Microsoft provided some insight. It turns out that the constructor of the SerializationException object doesn't set the Action property to anything valid. Before you can serialize a SerializationException with NDCS you must explicitly set the Action property to a valid SecurityAction. This does mean that NDCS is not compatible with the BinaryFormatter in this case, but at least there's a workaround/solution. I've now updated CSLA .NET 3.0 to explicitly set the Action property any time a SecurityException is thrown, thus allowing the WCF data portal channel to return valid details about the nature of any exception. For more information go to www.lhotka.net . Read More...
|
-
I am building a WPF UI for my ProjectTracker CSLA .NET sample app. On the whole this is going pretty well, and I anticipate being done within the next couple days. I’ve found and fixed a couple bugs in CSLA – one in BusinessListBase that’s been there forever, and one in ValidationPanel that caused a null reference exception. While I fixed that last one, I optimized the code a bit, which does seem to make the control a bit faster. But one thing I spent a ridiculous amount of time on was the simple process of getting a ComboBox control to bind to one data source to get its list of items, and to the business object property for the key value. Google turned up a number of search results, none of which really addressed this particular scenario – which seems odd to me given how common a scenario it is… In ProjectTracker, a person (resource) can be assigned to a project. If they are, they are given a role on that project. The Role property is numeric – a key into a name/value list, and a foreign key into the Roles table in the database. In Windows Forms and Web Forms the UI handles translating this numeric value to a human-readable value through ComboBox controls, and obviously WPF can do the same thing. The trick is in figuring out the XAML to make it happen. Here’s the ComboBox XAML: <ComboBox ItemsSource="{Binding Source={StaticResource RoleList}}" DisplayMemberPath="Value" SelectedValuePath="Key" SelectedValue="{Binding Path=Role}" Width="150" /> Let’s break this down. The ItemsSource property specifies the data source for the data that will populate the display of the control. In my case it is referencing a data provider control defined like this: <Page.Resources> <csla:CslaDataProvider x:Key="RoleList" ObjectType="{x:Type PTracker:RoleList}" FactoryMethod="GetList" IsAsynchronous="False" /> </Page.Resources> This data provider control loads a name/value list object called RoleList (that inherits from Csla.NameValueListBase). The child objects in this collection expose properties Key and Value. You can see how the ComboBox uses the DisplayMemberPath to specify that the Value property from the name/value list should be displayed to the user, and the SelectedValuePath specifies that the Key value from the list should be used to select the current item (the Key value is not displayed to the user). Then notice that the SelectedValue property is used to bind to the main business object. This binding statement sets a path to a property on the Read More...
|
-
I’ve been spending a lot of time in WPF-land over the past few weeks, and thought I’d share some of what I’ve learned. I haven’t been learning styles or UI layout stuff – Microsoft says that’s the job of the turtleneck-wearing, metrosexual GQ crowd, so I’ll just roll with that. Instead, I’ve been learning how to write data source provider controls, and implement Windows Forms-like behaviors similar to the ErrorProvider and my Csla.Windows.ReadWriteAuthorization control. You know, manly programming J The data source provider control is, perhaps, the easiest thing I’ve done. Like ASP.NET, WPF likes to use a data control concept. And like ASP.NET, the WPF data provider controls are easy to create, because they don’t actually do all that much at runtime. (I do want to say thank you to Abed Mohammed for helping to debug some issues with the CslaDataProvider control!) I’m sure, as designer support for data provider controls matures in tools like Visual Studio and Expression Blend, that life will get far more complex. Certainly the Visual Studio designer support for Csla.Web.CslaDataProvider has been the single most time consuming part of CSLA .NET , though I was able to create the runtime support in an afternoon… What I have today, is a Csla.Wpf.CslaDataProvider control that works similar to the ObjectDataProvider. The primary difference is that CslaDataProvider understands how to call Shared/static factory methods to get your objects, rather than calling a constructor method. The result is that you can create/fetch CSLA .NET business objects directly from your XAML. The really cool part of this, is that CslaDataProvider supports asynchronous loading of the data. To be fair, the hard work is done by the WPF base class, DataSourceProvider. Even so, supporting async is optional, and requires a bit of extra work in the control – work that is worth it though. If you construct a form that has multiple DataContext objects for different parts of the form, loading all of them async should give some nice performance benefits overall. On the other hand, if your form is bound to a single business object the value isn’t clear at all. Though the data load is async, the form won’t actually display until all the async loads are complete, so for a single data source on a form my guess is that async is actually counter-productive. The validation/ErrorProvider support is based on some work Paul Stovell published on the web. I conceptually based my work on similar concepts, and have Read More...
|
-
I have a custom data source control as part of my CSLA .NET framework. It is somewhat like ObjectDataSource, but works with objects that are created through factory methods rather than default constructors (and some other variations). All is pretty well with this control, except one issue: it fails when adding a CslaDataSource control to a page as a new data source from a DetailsView or other control. In other words, you add a DetailsView to the page, then tell that control you want it to bind to a new data source and it brings up a wizard, where you pick CslaDataSource so a new one is added to the page. The problem I’m getting is a VERY odd exception: Csla.Web.CslaDataSource can not be cast to Csla.Web.CslaDataSource. Yes, that’s right – the type can’t be cast to itself. I believe this is because the wizard is loading its own copy of Csla.dll into memory, separate from the one used by the web forms designer. Or something like that. This even confuses the debugger – it can’t show details about the type because it says the type is loaded into two different GUIDs. I don’t know what the GUIDs represent (appdomains, versions?), but it is obviously not good. This is very weird, and after hours of time on this, I’m quite stumped. Any help, clues, pointers or ideas are VERY welcome! Thanks! Rocky For more information go to www.lhotka.net . Read More...
|
-
Here's an issue from Windows Forms that appears to have crept into WPF as well – along with a solution (thanks to Sam Bent and Kevin Moore from the WPF team): Consider a class with a property that enforces a business rule - such as that the value must be all upper case: public class Test : INotifyPropertyChanged { public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged; // ... private string _data; public string Data { get { return _data; } set { _data = value.ToUpper(); OnNotifyPropertyChanged("Data"); } } } Bind this to a TextBox and type in a lower-case value. The user continues to see the lower-case value on the screen, even though the object obviously has an upper-case value. The PropertyChanged event is blissfully ignored by WPF data binding. I believe this is the same "optimization" as in Windows Forms, where the assumption is that since the value was put into the object by data binding that it can’t be different from what's on the screen - so no refresh is needed. Obviously that is a unfortunate viewpoint, as it totally ignores the idea than an object might be used to centralize business logic or behavior... In Windows Forms the solution to this issue is relatively simple: handle an event from the BindingSource and force the BindingSource to refresh the value. Bill McCarthy wrapped this solution into an extender control , which I included in CSLA .NET, making the workaround relatively painless. In WPF the solution is slightly different, but also relatively painless. It turns out that this optimization doesn’t occur if an IValueConverter is associated with the binding, and if the binding’s UpdateSourceTrigger is not PropertyChanged. For the TextBox control the UpdateSourceTrigger is LostFocus, so it is good by default, but you’ll want to be aware of this property for other control types. An IValueConverter object’s purpose is to format and parse the value as it flows to and from the target control and source data object. In my case however, I don’t want to convert the value at all, I just want to defeat this unfortunate “optimization”. What’s needed is an identity converter : a converter that does no conversion. namespace Csla.Wpf { public class IdentityConverter : IValueConverter { #region IValueConverter Members public object Convert( object value, Type targetType, object parameter, System.Globalization.CultureInfo culture) { return value; } public object ConvertBack( object value, Type targetType, object parameter, System.Globalization.CultureInfo Read More...
|
|
|
|