I am trying to understand the use of XAML instead using it as markup in creating WPF and silverlight applications. Where else could i use XAML. Please provider all the possible uses of XAML.
Could XAML be used as regular XML to provider mapping and related stuff?
Please provider some links where i could learn about XAML.
Thanks.
This writeup can be helpful: http://www.davidpoll.com/2010/07/25/to-xaml-with-love-an-experiment-with-xaml-serialization-in-silverlight/. This article describes a way on how XAML can be used as a serialization format not just for a user-interface, but also for other CLR objects.
XAML is used as the serialization mechanism for workflows in Windows Workflow Foundation (WF), see for example http://www.codeproject.com/KB/WF/XAML_WF.aspx
XAML's a fairly efficient XML serialization format with hooks for namespaces and markup extensions. You don't have to use it purely for WPF applications; as long as the types you're serializing have parameterless constructors you can represent just about any .NET reference type in XAML.
If you're not using markup extensions, it's not really a huge leap past ordinary XML serialization. But the incremental improvements that it offers are useful enough, and the fact that it's a format supported by VS and WPF and Blend certainly doesn't hurt.
Related
I have been looking at some components Microsoft use for VS2012, attempting to learn and use there approaches to extensible component design. Despite being able to decompile the C#, I cannot seem to find any way of looking at the XAML mark-up, is this possible?
Note. I have attempted using Snoop but this does not seem to be able to provide the relevant XAML.
Thanks for your time.
You could use a commercial Reflector with BAML Viewer to convert BAML resource of assembly to XAML.
Also you could use a free dotPeek decompiler. Since 1.1 version it has a feature to view BAML resources without any additional plug-ins.
At last you could use a open source ILSpy decompiler to solve the same problem.
I am trying to set the document of FlowDocumentReader at design-time but cannot figure out how to do it in a pure declarative way. There is no design-time attribute for Document and using DataContext does not work (for obvious reasons I think). What is the best way to this:
in a declarative way (preferred)
in a mostly declarative way with some helper code (less preferred)
using only code (least preferred)
The declarative design-time is important since we are using sketchflow to mockup an application screen where the user can see the (paragraph and character) styles and navigate through the document using these styles.
All suggestions are welcome.
Thanks, Marc
As far as I know, XAML is only used in WPF and Silverlight, isn't it?
Thanks.
No, it is also used in Windows Workflow Foundation:
Using Workflow Markup
XAML is also the basis for XPS.
It is also used in Office 2007+ *x formats
You can use it for whatever you like (beginning with .NET 4.0 if I'm not mistaken, didn't try it in 3.5).
However, if you do so, please also use the other good things .NET has to offer, such as "INotifyPropertyChanged" and dependency properties. Otherwise whatever you create will be a less - than - optimal solution.
There is a huge mistake I often see people make when they say, "XAML is UI markup." It's not. You can have XAML with no UI whatsoever. XAML is, in essence, an XML object graph. It is markup for creating classes. It provides the parser with instructions on how to generate instances of types and set properties on those types. This is extremely useful for creating UI in WPF and Silverlight but can also extend to sample data, view models, and other constructs. As mentioned here, it is also used in Workflow and other areas.
I've been very happily using the Model-View-ViewModel (MVVM) pattern in WPF and Silverlight apps in combination with C#. Declarative XAML markup and data binding are invaluable - I just can't live without them. But, this talk by Harry Pierson on dynamic languages got me excited about learning a dynamic language, and I'd like to try one out in a new project. I've been enjoying reading IronPython In Action, and it does contain a few WPF examples - but only with imperative-style code.
What are your thoughts on using IronPython or IronRuby at the ViewModel and Model layers in MVVM apps (compared to C#)? Which features of make them attractive (or unattractive)? I'm interested in fundamental advantages/limitations (e.g. AOP, duck typing, monkey patching, static type limitations, etc) and practical ones alike (e.g. performance, no current IronPython Studio for v2, etc). Will any limitations improve with C# 4.0?
Thanks,
David
Shay is right, but only for Silverlight and I've not used Silverlight and IronRuby. You can bind and use commands with pure IronRuby and WPF. I'm assuming this also applies to IronPython as they both use ICustomTypeDescriptor. there is a caveat, you'll need a DLR build more recent than IronRuby 0.9 for events.
To create an IronRuby command, you need to implement events. See this SO question for more Implementing and Interface in IronRuby that includes CLR Events
As for creating an IronRuby object that can participate in binding, the deal is a an attr reader/writer needs to be used for the DLR to see it as a property.
class Bindable
attr :some_property, true
end
I've got a few Gists about it. A Command Example, A simple ViewModel Example with Binding And the XML Builder based xaml library used in the examples. These worked for me.
There are limitations. XamlLoader can't see IronRuby classes from the CLR. This means your views are REALLY dumb (zero code-behind), or they come from a C# dll. It also means that you can't create custom or user controls that have any code behind without going to C#.
While I don't have a fully baked MVVM app in IronRuby/WPF, I think all the pieces are in place and I'm getting there.
I can say that writing WPF with IronRuby is pretty cool, and if you invest a little time metaprogramming your environment, it can be awesome.
However, there are the downsides - data binding doesn't work with IronRuby objects (you must use CLR objects for that - look at my blog post for the workaround), but this should improve on .Net 4.
Pay attention that IronRuby is expected to go RTM only in November.
Having said all that, I do recommend you check it out. You might fall for it like I have :)
Shay.
I've blogged about my experiences trying out IronPython and MVVM with WPF here. It was surprisingly easy to get going.
What would be a good aproach to localize a MVVM based WPF allication that can change its language at runtime? Of course I could create a string property in the ViewModel for each and every string that is displayed somewhere in the View but that seems rather tedious to me. Is there a common approach/best practice for this?
Here's an excellent article about WPF localization. It deals with the Microsoft-supported localization technique, and a few alternative ones
I wouldn't recommend the "official" solution for localization... it's really a pain to use, it modifies you XAML (adds x:Uid attributes to every element that can be localized), and there are no good tools from MS to make it an easy solution. Good old resx localization is much easier to use, and integrates quite well with WPF with just a few tricks (namely, markup extensions and/or attached properties). Also, you can easily change the interface language at runtime thanks to the binding system.
WPF has a lot of support for localization. Perhaps you can leverage that? Unfortunately I think that changing the user interface language at run-time is somewhat difficult and you probably need to come up with your own scheme.
Also, as the view-model is UI agnostic I don't think storing user interface strings in the view-model is a good solution. These belong to the view.
Instead of having user interface strings in your view model, you can store them in the assembly's resources and access them directly from XAML, using x:Static:
<TextBlock Text="{x:Static props:Resources.MyLabel}"/>
The props namespace should refer to your assembly's Properties namespace:
xmlns:props="clr-namespace:My.Assembly.Properties"
You can use a Custom Markup Extension to lookup localized values and update them when the UI Culture changes.
Here's an example of how this might work:
<Label x:Name="lblResxHelloWorldMarkupExtension1Value"
Content="{res:Res Id=HelloWorld,Default=Hello#}"
Margin="{res:Res Id=HelloWorldMargin,Default=10}"
Width="{res:Res Id=HelloWorldWidth,
ResourceSet=WpfClickOnce.MyFormRes, Default=50}" />
This example is taken from the excellent WPF Localization Guidance authored by Rick Strahl and Michele Leroux Bustamante here: http://wpflocalization.codeplex.com/. Download the guide from this site where this technique is described in detail in document form and with a sample application.
Another nice advantage of this approach is that it works in the designer.
If you are almost interested on this topic you can have a look at my library that I'm developing on codeplex.
LocalizationLibrary: http://localizationlibrary.codeplex.com/
Here's a couple of articles that could be of interest:
Localizing WPF Applications using Locbaml
WPF Runtime Localization
Simple WPF Localization