|
|
Browse by Tags
All Tags » Silverlight (RSS)
-
As part of the CSLA Light project we created a unit testing engine for Silverlight and donated it to the community as UnitDriven . We now have our first community contribution to this open-source project, in the form of a really nice visual change. Here's the author's blog post on the topic: http://staxmanade.blogspot.com/2008/08/unitdrivens-ui-gets-minor-makeover.html Thank you Staxmanade! This is a really nice visual upgrade, and more importantly a major usability upgrade. I love it! The next release of the CSLA Light unit tests will be linked to the new version of UnitDriven, and having used it for just a day or so, I can say it is a big help. Read More...
|
-
I have put an updated pre-release online for download of both CSLA .NET 3.6 and CSLA Light 3.6. CSLA .NET CSLA Light We're now at the point of focusing primarily on stabilization and limiting new features. Changes at this point will be due to our testing and usage, and feedback we recieve from the community. This pre-release should be reasonably stable, on both the .NET and Silverlight platforms. Please give them a try and post in the forum with any issues you encounter. Thank you! Read More...
|
-
WPF has this cool concept called a data provider control. CSLA .NET includes a custom data provider control that enables nearly codeless forms (if you don't count XAML as code), by supporting the following functions purely through XAML: Create/Fetch an object Save an object Cancel changes to an object Add a new item to a list (if the object is a collection) Remove an item from a list (if the object is a collection) Silverlight doesn't have a data provider concept, nor does it have commanding . Which means that you need to write code behind the form for all of those actions. So in CSLA Light we're investigating the possibility of some sort of data provider control to fill in this gap. The idea is that you'd be able to declare a CslaDataProvider as a resource on your form and use it as a data source, and as a handler for the save/cancel/add/remove operations. This also means we need a way, through XAML, to route things like a button's Click event to methods on CslaDataProvider (because there's no commanding in Silverlight). At a prototype level what we've got is something like this. The CslaDataProvider goes in the Resources section just like it would in WPF: <UserControl.Resources> <csla:CslaDataProvider x:Key="MyData" ManageObjectLifetime="True" /> </UserControl.Resources> Some WPF concepts don't make sense. For example, IsAsynchronous is useless because in Silverlight it will be asynchronous . Others, like IsInitialLoadEnabled might make sense, we're not entirely sure yet. Your page XAML then uses this as a data source. But where WPF does some magic behind the scenes for data providers, Silverlight doesn't know about data providers. So you have to deal with this yourself when setting the DataContext: <Grid x:Name="LayoutRoot" DataContext="{Binding Source={StaticResource MyData}, Path=Data}"> The DataContext is set to use the Data property of the data provider, because that's where the actual business object is found. In WPF this indirection is hidden automatically, but in Silverlight you have to do it yourself. In the Form_Loaded() method in code behind you call your business object's factory method. But rather than handling the async callback yourself, you allow the data provider to handle it: private void Form_Loaded(...) { var dp = (CslaDataProvider)this.Resources["MyData"]; CustomerEdit.GetCustomer(123, dp.FetchCompleted); } I hope to eliminate even this bit of code behind (at least for parameterless create/fetch scenarios), but Read More...
|
-
In Part 1 of this series I discussed the overall architecture and structure of a CSLA Light application. In Part 2 I walked through the creation of a simple editable root business object that supports both the 3-tier and 4-tier mobile object models. In Part 3 I discussed the creation of the Silverlight UI. In this post I will discuss the configuration of the web/app server and the data portal. All Silverlight applications require a web server, because the Silverlight runtime is hosted in a web page, and the user has to get the web page from a web server (I'm sure there are exceptions to this rule - but in practicality, nearly all Silverlight apps will be downloaded from a web server). When using CSLA Light in a 3- or 4-tier client/server model, the CSLA Light client application will communicate with a .NET application server. That application server might be the same server from which the Silverlight app was downloaded, or a different server. It might be hosted in ASP.NET or WAS or a custom Windows Service. The CSLA Light data portal uses WCF as its network transport, and so the only requirement is that the server be reachable from the client using the Silverlight WCF implementation. CSLA .NET 3.6 includes a special data portal host designed to work with a CSLA Light client. Remember that the CSLA Light data portal is not only going across the network, but it is communicating between the .NET and Silverlight platforms. So while this data portal is functionally similar to the .NET data portal, it has to do some extra work thanks to the cross-platform nature of the scenario. Configuring the Server The simplest server configuration is to put the data portal host in the same virtual root as the Silverlight application itself, and that's what I've done in this example. When the Silverlight application was created, Visual Studio automatically created a host web application project. What I've done is added a WcfPortal.svc file, some web.config entries and a reference to Csla.dll to this project: The WcfPortal.svc file is a typical WCF service file: <% @ServiceHost Service="Csla.Server.Hosts.Silverlight.WcfPortal" %> It references the WcfPortal class that contains the data portal host designed to work with CSLA Light. Notice that it comes from the Csla.Server.Hosts.Silverlight namespace. The web project references Csla.dll, and of course also references Library.dll from the Library.Server project . Remember that Library.Server is a .NET Class Library project Read More...
|
-
In Part 1 of this series I discussed the overall architecture and structure of a CSLA Light application. In Part 2 I walked through the creation of a simple editable root business object that supports both the 3-tier and 4-tier mobile object models. In this post I want to cover the Silverlight UI. Following the theme of this walkthrough, the UI will be very simple so I can illustrate the basic requirements and concepts. At this point in time we're working on UI support for authorization, and I'll discuss it when we have something to show. UI XAML The XAML for the UI is not complex, but does have some interesting differences from typical WPF XAML: <UserControl x:Class="SimpleApp.Page" xmlns=" http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x= http://schemas.microsoft.com/winfx/2006/xaml xmlns:csla="clr-namespace:Csla.Wpf;assembly=Csla" Width="800" Height="600" Loaded="UserControl_Loaded"> <Grid x:Name="LayoutRoot" Background="Beige"> <StackPanel Margin="5,5,5,5"> <StackPanel Orientation="Horizontal" Margin="5,5,5,5"> <TextBlock Width="100" Text="Id" /> <TextBox Width="150" Text="{Binding Id, Mode=TwoWay}" /> <csla:PropertyStatus Property="Name" Source="{Binding}" /> </StackPanel> <StackPanel Orientation="Horizontal" Margin="5,5,5,5"> <TextBlock Width="100" Text="Name" /> <TextBox Width="150" Text="{Binding Name, Mode=TwoWay}" /> </StackPanel> <StackPanel Orientation="Horizontal" Margin="5,5,5,5"> <TextBlock Width="100" Text="Status" /> <TextBlock Width="150" Text="{Binding Status}" /> </StackPanel> <StackPanel Orientation="Horizontal" Margin="5,5,5,5"> <Button Width="50" HorizontalAlignment="Left" Margin="5,5,5,5" Click="Button_Click" Content="Save" /> <Button Width="50" HorizontalAlignment="Left" Margin="5,5,5,5" Click="Delete_Click" Content="Delete" /> </StackPanel> </StackPanel> </Grid> </UserControl> The primary difference is that the Mode=TwoWay expression is required to get two-way data binding. In WPF the default is two-way, and in Silverlight it appears to be one-way. Also, in WPF I would have created a Style for the StackPanel controls to pull the Margin property into a Resources block. While I was able to get a Style working for a TextBlock or TextBox, it would not work for StackPanel. Could be something I did, or a bug or missing feature in Silverlight... Certainly the XAML to do that from WPF doesn't Read More...
|
-
I've put another prerelease of CSLA Light (CSLA for Silverlight) and CSLA .NET 3.6 online at www.lhotka.net/cslalight/download.aspx . Check out the new identity base classes in Csla.Security and Csla.Silverlight.Security - they are pretty darn cool! Check out the new Validator UI control - I think that is really cool!! It won't keep that name, because we're merging the Authorizer functionality directly into that control, so the result will be a consolidated control that does both things - we don't have a name for it yet... I'm pretty sure the ClientContext and GlobalContext work right, but the unit tests don't show that - so I'd recommend viewing that functionality with suspicion. I know some of the security tests don't work. Authentication is still evolving and some of the test apps are lagging a bit behind. Please remember, these are very early preview builds. They are not stable. They are not complete. They may or may not work for you. They are not supported. We have found, in testing, that Silverlight Beta 2 is not entirely stable. And that WCF in Silverlight is particularly unstable . If you run the unit tests in Silverlight you'll probably find what we find - that they randomly fail sometimes. They'll run. They'll fail. Then they'll run again. With no discernable pattern. Quite frustrating, but I guess this is the nature of working on a beta platform. I have also put the sample app I've been blogging about at http://www.lhotka.net/files/cslalight/SimpleCslaLightAppvb-080803.zip . This sample app shows all the things I've talked about in my Part 1 and Part 2 posts, and I'll be coming out with more posts in the series in the next few days. Read More...
|
-
In Part 1 I discussed the high level architectural options offered by CSLA Light. In Part 2 I'll start walking through the implementation of the 3-tier mobile object model (which pretty much also covers the 4-tier mobile object model as well). I'll start with the center of the application: the business layer. As I discussed in Part 1 , the business layer spans Silverlight and .NET and defines mobile objects that are capable of moving between the Silverlight client and the .NET web/app server. (CSLA Light supports both C# and VB - and probably most other languages too - so the fact that this particular demo is in VB shouldn't be taken as an indication that anything only works with VB. Rather, I consciously switch between VB and C# for each demo I write, and it is VB's turn.) This is intended to be as simple a demo as I can create, and still show something useful. To that end, the demo has exactly one object, with three properties. Library.Client Setup The Library.Client project is a Silverlight Class Library. This means it compiles for the Silverlight runtime and can only contain code that will run on the Silverlight client. It is important to realize that when objects serialize and deserialize, they must have the exact same type name . This includes the assembly name, namespace and type name. The standard .NET way to represent an assembly qualified type name is something like: "MyNamespace.MyType, MyAssembly" Since the business objects in Library.Client must be compatible with those in Library.Server, both assemblies must compile to the same assembly name, and must use the same namespaces. To accomplish this, the project's properties must be changed so the Assembly name and Root namespace do not include the ".Client" part of the name: I've changed them both to "Library", so this will compile to Library.dll and the root namespace is Library. Library.Server Setup The same changes to the Assembly name and Root namespace are made to the .NET Class Library project, Library.Server: This project also builds a Library.dll with a root namespace of Library. If you sign either project, you must sign both projects , and you must use the same key. That way they end up with the same effective assembly name, even though they are on different runtimes. The end result is that a class in one project is serializable into and out of a class in the other project. CustomerEdit Class Declaration The CustomerEdit class exists in both the Library.Client and Library.Server projects, Read More...
|
-
In preparation for the next public release of CSLA Light (CSLA .NET for Silverlight), I'm going to do a series of posts describing the basic process of creating a CSLA Light application. This first post will provide a high-level overview of the project structure and some concepts. First, it is important to realize that CSLA Light will support three primary physical architectures: a 3-tier (or SOA) model, a 3-tier mobile objects model and a 4-tier mobile objects model. At all times CSLA Light follows the same n-layer logical architecture of CSLA .NET, where the application has the following layers: Presentation/UI Business Data Access Data Storage The primary goal of CSLA Light and CSLA .NET is to support the creation of the Business layer in such a way that the interface points to the Presentation/UI layer and to the Data Access layer are clearly defined. To a small degree, CSLA Light will assist in the creation of the Presentation/UI layer by providing some custom Silverlight controls that solve common issues and reduce UI code. Like CSLA .NET, CSLA Light is not an ORM and does not really care how you talk to your database. It simply defines a set of CRUD operators - locations where you should invoke your Data Access layer to retrieve and update data. 3-Tier or SOA Model If you use CSLA Light in a 3-tier (or SOA) model, your physical tiers are: Silverlight Service Database You can treat these as tiers, or as separate applications where you use SOA concepts for communication between the applications. That's really up to you. In this case the focus of CSLA Light is entirely on the Silverlight tier . In that Silverlight tier, you'll have the following logical layers: Presentation/UI Business Data Access/Service Facade To do this, you configure the CSLA Light data portal to run in local mode and it calls the DataPortal_XYZ methods right there in the Silverlight client tier. You implement the DataPortal_XYZ methods to invoke remote services in the Service tier. CSLA Light doesn't care what those services look like or how they are implemented. They could be asmx, WCF, RSS, JSON, RESTful, SOAP-based - it just doesn't matter. If you can call it from Silverlight, you can use it. The CSLA Light data portal is designed to be asynchronous, because any calls to remote services in Silverlight will be an asynchronous operation. In other words, the data portal is designed to support you as you call these remote services asynchronously. The only requirement is that by the Read More...
|
-
If you've tried to do any unit testing in Silverlight, you may have run into an interesting issue. Many times, unit tests expect exceptions. Tests are written to ensure that an exception occurs as expected. That's a standard concept in most unit testing frameworks for .NET. In Silverlight, there's an "expected CLR behavior" where the debugger will break on exceptions that are actually handled by user code - treating them like they aren't handled . See this thread for some more detail: http://silverlight.net/forums/p/20678/72377.aspx#72377 The result of this, is that you have to employ some ugly workarounds, or you need to press F5 for each of your tests where you expect an exception. We're running into this issue in a big way with CSLA Light (CSLA .NET for Silverlight), because we're creating lots and lots of unit tests, and a fair number of them are testing to make sure exceptions occur when we expect them. Of course our unit testing framework ( UnitDriven ) uses reflection to run each test method - just like MSTest or nunit - and so even though we are handling the exception in user code the debugger insists on breaking in the test methods themselves where the exceptions occur. Again, there are workarounds. They prevent you from using the debugger to walk through your tests - but at least they exist. The whole thing is really sad though - given that this is apparently intended behavior . Read More...
|
-
I have put a very early preview release of CSLA Light and CSLA .NET 3.6 online at www.lhotka.net/cslalight/download.aspx . There is no sample app at this point, so you'll have to look at the unit tests in cslalighttest and cslatest to figure out how to use the various features. Obviously this is very early code, but it is healthy to release early and often, so here we go :) One side-effect of our work with CSLA Light is that we discovered that testing asynchronous methods is really hard with nunit and MSTest, and impossible with the Silverlight unit test framework provided by Microsoft. And yet in Silverlight, async methods are commonly required, and for parity a number of async features are now also in CSLA .NET. And we need to have unit tests for them. To address this issue, we ended up creating our own Silverlight unit testing framework, and an add-on framework for nunit or MSTest. This allows us to write a common set of test code that runs in both Silverlight and .NET so we can test both, and establish that we have parity between them. Earier today, Justin split this testing framework out of CSLA and we put it up on CodePlex, calling it UnitDriven . The CSLA Light project and Magenic are donating the code to the community as an open-source project, because it can be used to build async unit tests for any app, not just for CSLA Light. Read More...
|
-
While most people use CSLA .NET because it provides support for data binding, validation, business rules and authorization, I personally think the coolest part of the framework is its support for mobile objects . This support is provided by the data portal, which provides both an abstract persistence model for business objects, as well as an implementation of mobile objects with location and network transparency. CSLA Light will also include a data portal that works in a manner similar to the one in CSLA .NET. In fact, the two are complimentary - the CSLA Light data portal talks to the CSLA .NET data portal, because the client is running Silverlight and the server is running .NET. This occurs when the CSLA Light data portal is running in "remote" mode - meaning it is talking to a remote data portal server. The CSLA Light data portal can also run in "local" mode, which means that the "data access" code runs on the Silverlight client. In reality, this probably means that your client-side code is directly calling some external service - an asmx web service, a WCF service, ADO.NET data services, etc. So the fact is that the data access is still on some server somewhere, but you aren't using the data portal to get from the client to that server. As in .NET, when using the data portal in local mode things are pretty simple. A call to the data portal to fetch an object simply results in a call to a DataPortal_Fetch() method in your object, and the object is running on the client in Silverlight. What you do in that DataPortal_Fetch() method is entirely up to you, as long as the object is populated with data by the time the call completes. When you use the remote data portal there are more options. Things are somewhat different from the existing .NET data portal. The following figure will help explain. The CSLA Light data portal interacts with a server (probably a web server, though it could be a Windows Server 2008 running WAS) through WCF. That server is running CSLA .NET 3.6, which includes data portal support to listen for CSLA Light data portal requests. Objects are serialized to/from CSLA Light using the MobileFormatter, which is a serializer included in both CSLA Light and CSLA .NET that provides a subset of the functionality provided by the BinaryFormatter (or NetDataContractSerializer), targeted at the CSLA scenario. On the web server, CSLA .NET 3.6 receives the inbound client request. Any objects sent from the client to the server are deserialized (including Read More...
|
-
With serialization largely out of the way - or at least under control - as described in a recent blog post, we've been able to put some focus on a couple other key areas. N-Level Undo The n-level undo functionality in CSLA .NET relies on reflection against private fields. Obviously that's not possible in Silverlight. Fortunately the serialization scheme we're using means that there's already a mechanism for trapping the values stored in the field manager. And there's the OnGetState()/OnSetState() methods that allow a business developer to trap/restore values in their private fields (if they choose). So UndoableBase had to be altered to use these techniques rather than using reflection. The end result is the same, which is what really matters. We opted not to replicate IEditableObject into CSLA Light. It is a .NET interface used by Windows Forms data binding, and is the source of never-ending pain thanks to all the edge cases and idiosyncrasies around this, seemingly simple, interface. Of course the interface isn't used by Silverlight (or WPF), and so isn't necessary. The effect of this choice is to simplify quite a bit of the n-level undo code, while at the same time preserving the shape of the pre-existing public interface for all objects. In other words, BeginEdit(), CancelEdit() and ApplyEdit() work as expected, but you can't use IEditableObject to get at its versions of those methods. Justin just ran into a strange issue with BusinessListBase, where an attempt to iterate through the items in the list caused a strange runtime exception from somewhere deep in the bowels of the Silverlight runtime. It appears there's some issue with a subclass of a collection iterating through its own items in a foreach loop. A for loop works fine however, so we have a workaround. Ultimately however, the ability to easily implement a Cancel button, including when using modal dialogs (which can be simulated in Silverlight) is supported Data Portal The data portal is coming along pretty well too. It supports a provider model, conceptually similar to the data portal in .NET. And we currently have two providers: local and WCF. One issue we're facing here is that Silverlight has no configuration subsystem comparable to System.Configuration. So there's no easy way to get configuration data from an "app.config" file or equivalent. At the moment I've come up with a code-based configuration scheme - but (unless Microsoft puts out a solution soon) we'll probably end up creating some Read More...
|
-
A couple people have suggested that I might be abandoning VB. Not so! My first love was Pascal - VAX Pascal actually, which was more like Modula II in many ways. What an awesome language! My next love was VAX Basic. Now that VB has structured exception handling in .NET, it has finally caught up to where VAX Basic was in the early 90's. No kidding. Of course after VAX Basic came VB. And after VB came .NET. I love .NET. I love .NET with VB and C#. C# is just VB with semi-colons, but VB is just C# without semi-colons too. I gave up on the silly language war thing a couple years ago, and am happy to let either or both language live or die by the hand of its users. The language thing was distracting me from truly enjoying .NET. When it comes to writing books, it is really important to remember that they fund CSLA .NET. As much as I love what I do, I've got kids that will go to college in the (scarily near) future, so I can't work for free. So when I write a book, I can't ignore that C# books outsell VB books around 3:1 (it used to be 2:1, but the market has continued to shift). I still think it is worth writing a VB edition to get that 25% of the market, but you must admit that it makes a lot of sense to go for the 75% first! It takes several weeks to port a book from one language to the other. The current plan for Expert 2008 Business Objects in C# is October (though I fear that may slip), and with the conversion time and publication schedule constraints, that pushes the VB edition into early 2009. Apress just hasn't put the VB book on their public release list yet, but that doesn't mean I don't plan to do that edition. When it comes to CSLA Light, I'm doing it in C# because of the 3:1 split, and so again am focusing on C# first. Whether I do a VB version of the framework or not depends on whether I decide to write a book on the creation and design of CSLA Light. I may or may not. If I don't write a book on the design of the actual framework, I won't port (and then maintain) the framework into a second language. It is a ridiculous amount of work to maintain CSLA .NET twice, and I really don't like the idea of maintaining CSLA Light twice too. You have no idea how much writing, testing and debugging everything twice slows down progress (and eliminates fun). As wonderful as Instant C# and Instant VB are, the dual effort is a continually increasing barrier to progress. I might write an ebook on using CSLA Light, in which case I'd leave the framework in C#, but create Read More...
|
-
We're nearly done with the final serialization implementation. At this point it is possible to clone objects on Silverlight and on .NET using the same MobileFormatter. By extension, this means that objects can be cloned from Silverlight to .NET and visa versa, though we don't have tests for that yet. (and there's a bunch of cleanup and detail work to be done for completeness - but the core engine is there and working) The approach we've taken is automatic for managed backing fields in a subclass of BusinessBase or ReadOnlyBase. It is also automatic for BusinessListBase, ReadOnlyListBase, etc. It is not automatic for custom criteria classes, but is automatic for SingleCriteria. The approach does allow for serialization of private backing fields, as long as you override a couple methods in your business class to get/set the field values. This is quite comparable to the PropertyBag scheme from VB6, and is conceptually similar to implementing ISerializable (though not the same due to some required features that aren't in Silverlight - there's a reason Microsoft didn't implement something like the BinaryFormatter). What this means is that when using only managed backing fields, you have to do no work at all. Your objects will just serialize. If you are using one or more private backing fields you need to do something like this: namespace MyApp { [Serializable] public class CustomerEdit : BusinessBase<CustomerEdit> { protected override void OnGetState(SerializationInfo info) { base.GetState(info); info.AddValue("MyApp.CustomerEdit._id", _id); info.AddValue("MyApp.CustomerEdit._name", _name); } protected override void OnSetState(SerializationInfo info) { base.SetState(info); _id = info.GetValue<int>("MyApp.CustomerEdit._id"; _name = info.GetValue<string>("MyApp.CustomerEdit._name"); } } } Assuming, of course, that you have two private backing fields, _id and _name. The one important restriction is that the types of all fields must be primitive types, or types that can be coerced using Csla.Utilities.CoerceValue() (which means the value can be converted to/from a string as required by the DataContractSerializer). Of course if you have a field value that can't be automatically converted to/from a string, you can do the conversion yourself in the OnGetState/OnSetState methods. This will get a little more complex when we implement UndoableBase (which is the next item on the list), because your overrides must differentiate between "NonSerialized" and Read More...
|
-
I spent some time over the past few days using my prototype Silverlight serializer to build a prototype Silverlight data portal. It is still fairly far from complete, but at least I've proved out the basic concept and uncovered some interesting side-effects of living in Silverlight. The good news is that the basic concept of the data portal works. Defining objects that physically move between the Silverlight client and a .NET web server is practical, and works in a manner similar to the pure .NET data portal. The bad news is that it can't work exactly like the pure .NET data portal, and the technique does require some manual effort when creating the business assemblies (yes, plural). The approach I'm taking involves having two business assemblies (VS projects) that share many of the same code files. Suppose you want to have a Person object move between the client and server. You need Person in a Silverlight class library and in a .NET class library . This means two projects are required, even if they have the same code file. Visual Studio makes this reasonable, because you can create the file in one project (say the Silverlight class library) and then Add Existing Item and use the Link feature to get that same file included into a .NET class library project. I also make the class be a partial class, so I can add extra code to the .NET class library implementation. The result is: BusinessLibrary.Client (Silverlight class library) -> Person.cs BusinessLibrary.Server (.NET class library) -> Person.cs (linked from BusinessLibrary.Client) -> Person.Server.cs One key thing is that both projects build a file called BusinessLibrary.dll . Also, because Person.cs is a shared file, it obviously has the same namespace. This is all very important, because the serializer requires that the fully qualified type name ("namespace.type,assembly") be the same on client and server. In my case it is "BusinessLibrary.Person,BusinessLibrary". The Person.Server.cs file contains the server-only parts of the Person class - it is just the rest of the partial class. The only catch here is that it can not define any fields because that would obviously confuse the serializer since those fields wouldn't exist on the client. Well, actually it could define fields as long as they were marked as NonSerialized. Of course you could also have a partial Person.Client.cs in the Silverlight class library - though I haven't found a need for that just yet. One thing I'm debating is whether the Read More...
|
|
|
|