One step beyond Silverlight
After WPF, I said myself 'waoh!', that must be huge to provide the same graphical quality for the web apps, the same flexibility. I just would like to go on throwing the new type of user xp in the user's face ! It's however necessary to keep in mind some design considerations. Whereas the .xbap pages are fully written on WPF and CSharp, the Silverlight plug-ins are clother to applets which enhance classical web pages. Let's discover my first Silverlight app: The GuidMarket is born.
[They are fresh my Guids! They are fresh!]
The application concept
The application is designed with a main xaml page and a whole of pages that are dynamically loaded according to the user actions such as a click on a Guid package or the load of the 'vista like' window. The business functionalities, extremely simple obviously, are provided by a local xml web service. To date, the plateform does not allow direct access to external features, that means one ore more local web services must be a bridge by consuming the external resources and send back streams to the client app.
However another way can be used: the Silverlight downloader object that enables sending requests to web services whether they accept using the GET method. The problem is to parse the xml stream returned that is 'normally' done by using the Atlas ScriptManager web control. The XmlHttpRequest should be an alternative to solve dynamic loadings...
function
LoadXamlStream(uriStream, callback, args)
{
var __downloader = _host.createobject("downloader");
__downloader.completed = "BLOCKED SCRIPTOnComplete";
if(callback != null)
{
_callback = callback;
_callbackArgs = args;
}
__downloader.open("GET", uriStream, true);
__downloader.send();
}
function OnCompleted(sender, args)
{
var __content = _host.findName("_content");
var __canvas = _host.CreateFromXaml(sender.responseText);
__content.children.Add(__canvas);
if(_callback != null) _callback(_callbackArgs);
}
Technical considerations
After my multiple investigations on WPF, I was very astonished about the features provided by the Silverlight plateform. Only one layout type, the Canvas element; the common controls such as buttons, hyperlinks, checkboxes, radio buttons do not exist. The least button needs designer qualities to avoid being grotesque. The absence of ControlTemplate elements also needs to reconsider how to design applications when you come from WPF.
Other important features are missing as the BitmapEffects elements that penalize the design of the apps and cause the proliferation of pictures what is desappointing according to me. I suppose the missing features will be caught up with the next CTP...I tried with the GuidMarket app to minimize the using of pictures and I preferred to use the provided routines massively. In addition with the background elements, only the Purchase button and the button that closes the window are designed with pictures.
Atlasians, win a free platinum Guid
The most important difficulty for the application design is the dynamic loading of the xaml stream using the downloader object and the data loading via the xml web service where the streams are returned asynchronously.
The loading cycle starts with the main xaml page following by the 5 next pages that I synchronise by multiple callbacks. This manual synchronisation is very tiresome and avoid losing streams of the first four pages !! Should the combinaison of Atlas and Silverlight enable dynamic loading of streams in a more flexible way ?
To go further
The most plug-ins developed on the plateform use xml web services to provide business mechanisms and functionalities. The idea is that the web services could become providers of xaml fragments in order to enable the client apps to load graphical elements dynamically, to respond some user actions without refreshing the page.
So, does this kind of web service replace the missing ControlTemplate elements in another way ?!?
Download the GuidMarket sources (Silverlight feb CTP)
On an original idea of Raskal (lol)
On a concept of WoZoI