Shine on Silverlight and Windows with XAML Extensible Application Markup Language, or XAML, lies at the heart of Microsoft's rich-client strategy. The user interface for both Windows Presentation Foundation (WPF) and Silverlight, which is mostly a subset of WPF, is typically defined in XAML. It is, therefore, something Windows developers will have to get to grips with …
Don't deploy XAML/Silverlight applications. By doing so you're not writing for the Web anymore -- you're writing for *Windows*. XAML and Silverlight are Microsoft's strategy for moving computing off the web and back to the desktop. Instead of writing for XAML and Silverlight, go find a nice AJAX toolkit and write true portable web apps. Yes, it might take a little more time, but look at how much death and destruction the "ease" of Visual Basic caused. Don't fall into that trap again.
If
<Rectangle Height="20" Width="50" >
<Rectangle.Fill>
<SolidColorBrush Color="Gold" />
</Rectangle.Fill>
</Rectangle>
is identical to:
<Rectangle Height="20" Width="50" Fill="Gold" />
this means you could do
<Rectangle Height="20" Width="50" Fill="Silver" >
<Rectangle.Fill>
<SolidColorBrush Color="Gold" />
</Rectangle.Fill>
</Rectangle>
hmm. Maybe that gives you a "whitegold" colour?
<sarcasm>
nice spec.
</sarcasm>
hold on, should that be
<voice type="sarcasm" words="nice spec"/>
who knows?
I think Ryanair used Silverlight on their website for the destinations map, they are already as expensive as other airlines, but with more restrictions, it was enough to cause me to walk away from the purchase.
Ah well, their choice, but I don't even have silverlight on my Windows PCs so it looks kind of dumb to me.
Try taking a look at OpenLaszlo.org . Even if it's been referred to as "going out on a twig" within the hallowed pages of the Reg, you'll find it's a real pleasure to program in - and capable of generating either DHTML/Flash from the same source code. (i.e. for ALL of the web). Basically, it's just better thought out without jumping through unnecessary architectural hoops to impress the management and justify a massive rise. Good stuff.
As if elements and attributes wasn't enough we now have properties.
When are they going to introduce methods and collections?
By then it will be so big we'll get a specialist set just for the data and another set for the interpreter. Now how will we link the two? - I've got it - XODBC.
At least we'll be able to kill of XSL (or is that XYL - oh hang about XYZ? ABC? do-re-me? fireball-XL5?)
<head explodes="true" />
or should that be
<head>
</explodes="true">
</head>
or maybe
<head>
<head.explodes>
</headexplodesvalue="true">
</head.explodes>
</head>
or even
if recordset("head") = "explodes" then response.write ("goodbye world")
@nobby
You're right, you could set a property twice, once as an attribute and once as a property element.
If you do, you get an error:
(in your example) "The property Fill is set more than once"
This is messy. On the other hand, if the spec did not allow the shortcut attribute properties, XAML would be considerably more verbose.
Tim
> Microsoft calls it "a system for representing structured information," which is about as generic as you can get,
That's what XML is for.
>reveals [...] that although XML is "a common format for XAML... any physical representation may be used." [1]
Indeed, that's true of XML too. But this makes me suspicious...
> It turns out that XAML has an uneasy relationship with XML. [...] but validating them as XAML is not easy. Microsoft explained back in 2006 why it could not develop a satisfactory XML schema for WPF. [2]
My suspicion grows. The fact that their example with Rectangle/Rectangle.Fill/SolidColorBrush/etc. can be expressed in multiple different ways, and that makes things tough to validate, just enhances my suspicion. [3]
And then we've got this example
> <Rectangle Height="20" Width="50" Fill="{StaticResource MyGradientBrush}" />
where the attribute Fill ain't what XML is for, so it makes validation harder [4]
[1] + [2] + [3] + [4] = the conclusion that MS, have carefully broken so many browsing standards, are trying to break XML. They've probably got their own 'physical representation' somewhere ready to produce when XML starts cracking.
I don't like XML so much, but this is not pretty.
...will rule.
From the article this XAML sounds like the usual unworkable MS bloatware - and it sounds like they are getting worse and worse.
I mean - c'mon - how can *anyone* break XML.
<quote>
It turns out that XAML has an uneasy relationship with XML. All the XAML documents you are likely to see are valid XML, but validating them as XAML is not easy. Microsoft explained back in 2006 why it could not develop a satisfactory XML schema for WPF.
</quote>
This level of incompetence would be almost heroic if it wasn't so sad.
I predict that the FireFox XUL stuff will be far superior. To look at it just add the FireFTP add-on to FireFox and see how great it looks.
And you can just load XUL files straight into the browser to get widgets and stuff. And it all works from Javascript.
Check out:
http://en.wikipedia.org/wiki/XUL
At least we know that it will work properly.
" Instead of writing for XAML and Silverlight, go find a nice AJAX toolkit and write true portable web apps."
...errrrmmm, AJAX is mainly derived from a Microsoft standard developed in conjunction with others but it is still an MS invention with MS notions of correctness.
Kinda try to get yer facts straight, kid.
I generally share your suspicion towards MS trying to break other things here. Whether it is XML they are after i don't know, but i tend to think not.
Why i reply is, your point [4] about attribute content is IMHO not valid from that example. Please have a look at XPath and SVG and you will see attributes are more than simple one-word identifiers even in W3C bred languages.
eg XPath: id("foo")/child::para[position()=5] (can go into an attribute in its entirety, provided proper quotes escaping)
more related, svg: <rect fill="url(#MyGradient)" />
At first the SVG way to locate a "Static Resource" looks more proper than that XAML example, but fact remains it uses a function call which returns a complex object. Like this, it's locating a static object, but you could as well have your own functions called in attributes doing mad things.
The other point about allowing "properties" declared by XML element subtree and/or XML attribute - Well, not nice, but it weren't too bad if there was one clear, simple and +/-set-in-stone spec defining which takes priority. Having it cause an error is just silly.
re XPath you're quite right. I'd completely forgotten about that usage. But, why bother? XPath/XSLT was designed to be readable and writable by people, so it had to be reasonably legible (I understand that earlier versions of these (or just xpath??) tried to express it all in XML but abandoned that approach for readability). How much of XAML as XML are we going to be directly interacting with - probably little at first, none when the tools mature. I may be wrong in this, if so please correct me, but assuming I'm not then where is XML used? Storing it? Space doesn't matter, and compress it if it does. Processing it? Use an appropriate format, whatever you wish. Writing it if we actually need to? Again, use an appropriate format - like a proper language and *not* XML (how hard is it to write some lex/yacc [*] anyway to do the necessary translation. Trivial).
And claiming that twisting XML was done for readability - I don't believe it. I can't find the ref but MS admitted that it tried to make SOAP XML syntax so unwieldy that you had to use their tools instead.
And as for the dot syntax <Rectangle.Fill>, that's deliberate abuse of XML. It has to be.
Just as a thought, and please note that I became familiar with XML before namespaces were introduced properly and I've not had cause to use them, could this not have been done with namespaces, eg.
<root xmlns:XAML_FILL="..."> ... <XAML_FILL:Rectangle> ...
Could this be made to work? If so it would preserve XML behaviour and give MS what they want.
And by the way, this is going to be a problem in general:
<Button Content="Click me" Grid.Row="1" Grid.Column="0" />
That's because the Content bit is an attribute and is thus subject to attribute normalisation, so all leading and trailing whitespaces are stripped, and any whitespaces within are collapsed to a single whitespace. Could this be part of the plan? Well, MSXML has this bug whereby whitespace normalisation is *not* done. Thus breaking the standard. Maybe it's been fixed in the last 2 years, I doubt it.
I still am suspicious.
[*] probably lex.net and yacc# these days.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
