posted by aL_

posted by stevo_

There are more details about XAML2009 and System.Xaml.dll on my WindowsClient.Net blog.

aL_ - VS intellisense (and Blend intellisense) don't support all the next XAML2009 features yet, but will in the future. (See XAML2009 isn't everywhere yet...).  Mark Wilson-Thomas, soon to be on Channel 9, should cover some of the enhancements in VS 2010 for XAML, including intellisense for MarkupExtensions.

stevo_ - VS 2008 can't target .NET 4.0 applications, but VS 2010 can target 2.0, 3.0, 3.5, 4.0 applications!  Multitargeting...gotta love it!

Thanks, Rob Relyea

posted by Rob Relyea

posted by section31

There are many custom file formats that you could imagine that hold "XAML Data".  WPF uses BAML.  Baml2006Reader surfaces up objects, members & values.  Used in conjunction with the XamlObjectWriter, you can read BAML and have it create object graphs.

If you wanted to invent your own file format to replace XAML's XML format, you would build a new subclass of System.Xaml.XamlReader and System.Xaml.XamlWriter.

Thanks, Rob

posted by Rob Relyea

What about case sensitivity? could I have <something /> vs <Something /> ? what about intercepting how attributes are mapped to properties, so that for example I could have an attribute that would represent an elements 'markup name', so that I could say:

[MarkupName("xaml-rocks")]
public bool XamlRocks { get; set; }

and have:

<something xaml-rocks="true" /> (ideally with intellisense)

And if this is possible, presumably via a custom reader- how do I tell the ide to use this reader to understand MY xaml?

I know theres a lot of questions there and I'm being cheeky asking but if you could point me perhaps to a 'xaml community' ..

Cheers in advance.

posted by stevo_

posted by section31

posted by freefly

posted by aL_

The source code for that tool (XamlT.Pad) is here: http://robrelyea.com/demos/xamlT.Pad/XamlT.Pad.Beta1.zip. It requires .NET 4 Beta1 to run.

I'll be exploring some of the code in there on my blog over the next few days/weeks...but you don't need to wait for me.

Thanks, Rob

posted by Rob Relyea

Yes, using a XAML based dialect has some advantages:

• You don't need to write your own load/save code.
• VS has a XAML editor that will provide intellisense for your vocabulary.

If you want to be able to write down just a part of an object graph, that we can do, but stiching that into an existing XAML text document is an advanced scenario that Cider/Blend do a lot of work to support.  Likely you'd need to be more advanced in your usage of System.Xaml, perhaps maintaining a XamlDom and correlating that with the ObjectGraph and the text file -- like Cider/Blend do.  If you want to go do that, we hope that System.Xaml.dll helps you do that...and we'd love feedback for that scenario.

Thanks, Rob

posted by Rob Relyea

Custom Formats

If I wanted to build a new file format called .myFormat that looked like this:

StackPanel
    Button
    .Background Red
        Ok

Instead of the same XAML XML format:

<StackPanel>
    <Button Background="Red">Ok</Button>
</StackPanel>

I would build a XamlMyFormatReader that subclasses System.Xaml.XamlReader.
It would then need to parse the .myFormat file and do the necessary work to pass the appropriate XAML node stream on each call to XamlMyFormatReader.Read().

A user would then do something like this:

XamlMyFormatReader mfReader = new XamlMyFormatReader("page.myFormat");
StackPanel sp = (StackPanel)XamlServices.Load(mfReader);

Note: the Cider/Blend designer has no plans to support other XAML formats with intellisense, designer support.  So building your own text based format for XAML for WPF/Silverlight is likely not very useful.  There are other scenarios where this flexibility will be beneficial though.

Case Insensitive, Different Markup Names

Yes, you could write a custom XamlSchemaContext that would enable those scenarios...case insensitive searches, paying attention to an attribute that says a different name.  You would need to make XamlXmlReader use your custom schema context in order to work though.

Yes, it is possible...is it a good idea, I don't think so.

And, no, intellisense definitely wouldn't respect that.  The IDE/XAML Editor has no pluggability to take arbitrary XamlReaders.

Xaml Community

We don't have an official MSDN forum devoted to XAML.  Right now, I'd recommend commenting on my blog or posting questions to the WPF Forum in MSDN...

Thanks, Rob

posted by Rob Relyea

See "XAML2009 isn't everywhere yet" and ask questions on that post for questions about what is in .NET 4 or not.  VS support is not planned in VS10 timeframe.

Thanks, Rob

posted by Rob Relyea

posted by AndyC

Yes perhaps not a good idea, but it was based on the problem being markup first, its a shame you can't specify a designer xaml reader for a specific root type.

posted by stevo_

We would really like to use System.Xaml in web applications on the server side, but .Net 4.0 is not likely to be avaible on our production servers before at least two years.

In fact, we are in the process of writing our own XAML parser, and it seems such a waste of time regarding the great work you have already done in System.Xaml ...

If not, is there any chance that the System.Xaml source code should one day be released under an open source license like other parts of the .Net platform ?

Thanks for your advice.

posted by LaurentP

Thanks again..for the nice tool... looking forward to see the new code changes ...

posted by freefly

You aren't the first to request a .NET 3.x version of System.Xaml.dll.  Currently we have no plans to offer that, but I'd love to know what server side scenarios you'd like to use XAML for. 

Of course, you can use XamlReader.Load() from PresentationFramework.dll for .NET 3.x now...

We have no plans to release System.Xaml.dll individually under any open source license...whatever the rest of .NET does, we'll do.

Thanks, Rob

posted by Rob Relyea

v2 of our in-house web framework (used internally by several hundred developpers) has two important requirements :
- the applications must support both a Silverlight or a standard HTML front end, dependending on the channel used to access them (with a common declarative view model, but two different presentation templates)
- the server-side HTML control tree should be described in a much more strongly typed way than with traditional ASP.Net webform syntax (which is only about building a big string ...) if we want to be able to handle backward compatibility

The natural choice was thus to use a XAML syntax to describe a strongly typed control tree for our HTML rendering engine, and even to reuse all of the "logical tree optimization" notions offered by Silverlight & WPF : resources, styles, controls, templates, and dependency properties (knowledge & tools reuse).

Even if we reused the same concepts, in a client/server HTML world, the implementation of all these notions is very different than what it is in WPF. For example, the property system and the styles are much more complicated to handle (javascript & CSS generation), and have a slightly different meaning.

We first thought we would be able to use PresentationFramework.dll to load our XAML page descriptions, but AFAIK, there is no way for XamlReader.Load to initialize attached properties, styles ... without depending on the property system, binding expressions ... of WPF (objects derived from FrameworkElement), which does not fit our needs.

I really think there is a strong need in the community for a .Net 2.0 compatible version of System.Xaml.dll, as it could help speed up XAML adoption for a wider range of scenarios. I can see ISVs producing XAML-based tools also being stuck with a .Net 2.0 CLR on their clients machine for a while.

Thanks, Laurent.

posted by LaurentP

Very intersting scenario.  I occasionally ask the ASP.NET team why they don't use XAML...

XamlReader.Load in v3 can likely meet most of your needs.  An attached property doesn't need a DependencyProperty, it can work with just the static setter and getter methods. As long as you can build your XAML Vocabulary (set of elements/properties) with the right CLR shape, PresentationFramework.dll may be ok for you.

Thanks for the feedback.. we'll keep listening to feedback about this.  Our list of future work items is large...to take advantage of our new XAML infrastructure...

Thanks, Rob

posted by Rob Relyea

posted by swe

<meta http-equiv="something" />

Xaml won't like that because http-equiv cant possibly map to a cli? valid attribute, but I COULD intercept the member lookup and have an overload so my meta class may look something like this:

class Meta
{
  [MarkupName("http-equiv")]
  string HttpEquiv { get; set; }
}

This is also why I would love to plugin to the xaml viewer so that I could literally hand it a valid xhtml document and it would parse it happily.

The only things I'm thinking that may cause problems are how client markup (ie the rendered xhtml) namespaces will work, but I was thinking that the handling Type would be able to pick if it rendered the namespace back out in the output.

(does this sound like a valid scenario to mould xaml into (even as a prototype) or is this still a bad idea?)

posted by stevo_

You likely could build a set of types that represented the xhtml data, with the appropriate properties.
Using XmlnsDefinitionAttribute, you could map the xhtml namespace to your clr namespaces.

You could write a custom XamlSchemaContext to support case-insensitve lookup and support for "-" in a property name.

Seems less crazy than I thought before because you aren't trying to do this generally, but in order to consume a file type.

However, you should contrast this option with other XML to Object migration technologies like XML to LinQ and XmlSerialization...and Mike thinks there may be a HTML to LinQ on codeplex (or the like).

Thanks, Rob

posted by Rob Relyea

Markup extensions and attached properties would be used to control other concerns, for example you could have attached properties to identify cachability of page areas, or markup extensions to express client side bindings (evaluated by javascript).

I figured my biggest problem would be performance (aside from actually implementing such a concept), given that the source is completely translated into an object graph, 'evaluated' then rendered back to pure xhtml.. but I was wondering if you could create an object graph once for the page (perhaps even do some forms of persistence of the graph) and re-use the object graph over and over (making it much more like a template).

posted by stevo_