 |
|||||||||
|
|||||||||
|
|
Someone who read my blog decided that, in their complete lack of understanding of the problem, I had erroneously misrepresented the features (or lack thereof) in Silverlight. In short, they think that because I neglected to mention the Downloader component, that my assertions were wrong. Let's recap my assertions about Silverlight:
The Downloader component is not designed to allow me to consume Web Services or raw data from remote locations. If the original commentor on my blog (the one who thinks I am erroneous) had read the documentation in the SDK more clearly, they would have realized that the downloader component allows Silverlight applications to leave portions of themselves (such as XAML files, images, and videos) on the server and can be dynamically downloaded on-demand. The downloader component is actually pretty cool in that you can provide a progress bar while you download more stuff. In other words, if you click a button that says "Play Video", you can download that video on demand rather than sucking down the entire resource directory on the initial hit.
What the downloader component cannot do is hit a web service, make a remote method call on that web service using a SOAP envelope of any kind, and retrieve the results as XML that can then be turned into some kind of language construct like a class instance. I fully expect that when the mini-runtime version of Silverlight becomes available, they will probably have functionality like this made available - it would be foolishness not to include this ability.
However, my previous statements about Silverlight are still completely accurate. You cannot currently databind to model objects with Silverlight, and you cannot currently perform Smart Client type functions with Silverlight by hitting remote web services for data operations. This may change in the future, but that's how it stands right now.
Hopefully we're all now clear on what Silverlight can and cannot do. I don't just randomly throw things up on my blog, I do research before I post them. Before I made the assertion that you can't data bind with Silverlight on my blog, I had tried it a half-dozen ways using my own code, and I actually e-mailed someone who has been using WFE since before the public got ahold of it.
For what it's worth, I can corroborate everything you said on this post and
the previous. Everything you have said is completely accurate based on my
experience and research.
You said "WPF/E (Silverlight) HAS NO SUPPORT FOR BINDING TO MODELS, BINDING
TO DATA, OR EVEN CONNECTING TO NETWORK RESOURCES TO OBTAIN DATA."
There's a difference between obtaining DATA (e.g. actionable information in
structured format) then downloading a RESOURCE such as a XAML file, an
image, or a video.
I have attempted this, and when I try and use the Downloader component to
go anywhere but the source from which the WPFE application was downloaded,
my JavaScript security settings block it.
