Hi
I would like to enquire as to the future roadmap w.r.t support for other mobile platforms like Android and iOS for building CSLA.NET solutions that run on devices like iPhones, iPads etc. With the future of the Mono platform now being in flux with Novell having fired the Mono team, is there still going to be a focus on getting this running on Mono support platforms? Should we rather consider switching over to building a HTML 5 solution to target these kinds of cross platform devices?
Thanks
There's no way to provide a solid answer to this question until the events surrounding Attachmate and the new Xamarin company finish unfolding.
I do plan to release CSLA 4.2 in the near future, including the now unsupported MonoTouch and Mono for Android code we created. The actual Mono support remains unaffected by any of this, and is useful by itself because it allows the use of CSLA 4 on Linux and OS X.
In a few months we'll know more about the fate of Mono for iOS/Android, and I'll reevaluate my strategy at that time.
Hi Rocky,
I was wondering about CSLA and Blackberry. Most of my customers employ armies of people carrying company provided Blackberrys. The companies are very interested in providing their employees with real-time access to their custom line-of-business applications. I have been following the rumours that RIM is working on Silverlight support on the Blackberry but I've heard nothing official so far. Have you investigated bringing CSLA to the Blackberry?
CSLA requires .NET (or an open source equivalent like Mono). To my knowledge there is no .NET (of any sort) that runs on Blackberry?
That said, I've been thinking about the "core value" of CSLA lately, especially in light of the hype around HTML 5 (H5). What if H5 somehow breaks the trend set by HTML 1-4 and becomes a consistent programming model for smart client development? I know this is a long shot, but this is what the hype is all about.
So what is the value proposition of CSLA in a world where the client-side programming model and language is H5/JavaScript, and the server-side programming model is C#/.NET?
(and keep in mind, I'm not talking about web pages here, I'm talking about a real smart client app written in H5)
Right away you can see that the same business layer code written in C# won't be useful in the client app. So the "reuse the same business layer" benefit of CSLA evaporates instantly.
But there's still the idea of objects encapsulating business, validation, and authorization rules. Were there a csla.js (or something), you could write your business layer in js, using some form of framework support similar to the .NET rules engine in CSLA 4. Of course you'd also need to write the code in .NET for the server - but at least you'd have a somewhat similar conceptual model to use while writing the code twice.
Along with the rules engine, there would have to be the idea of a broken rules collection, isvalid, isdirty, and other metastate tracking.
There's also the data portal. There are js libraries that abstract AJAX (lots of them actually). But I don't know if there are any that can transfer entire object graphs intact, including the metastate that would be involved.
Finally, there's that old, dusty "mcsla" project that used the now-defunct "Oslo" technology from Microsoft. Basically the idea of a high level domain specific language (for the CSLA domain) that you can use to describe (code) business types, such that the real C# or js code is created dynamically at runtime based on the "code" in that high level language.
The summary of all this rambling, is that if there's no consistent runtime, platform, base class library support, or language between the client and server parts of an app, then life sucks and software becomes expensive to create.
Yet another reason I am doubtful that H5 will conquer the world. (although the node.js project might help - because it allows js to run on the server - kind of solving the problem in reverse)
Copyright (c) Marimer LLC