Partager via

Going flex to Silverlight: The basics (easy stuff first).

  • Article

Introduction

This is going to probably annoy some, and signal mixed messages but overall the approach I am taking is to provide a context driven learning path on how to go from Adobe Flex coding to Microsoft Silverlight. I really don't want these posts to be fuel for the "Flash Killer" BBQ's as that's counter-productive, it's intended to be more focused on helping folks whom are curious about Silverlight (for whatever reason they chose) and are about to embark on the ramp-up in learning about it.

It's important no matter what bloodline you come from to be at least aware of the basics of Silverlight, what it has to offer going forward and lastly how easy it may make life for you (depending on your project / context).

In light of this, I'll be doing a lot of these "If only I knew" style posts, as one thing I learnt very fast coming over to the Microsoft feeding tank was how easy life really is for the average .NET developer and Silverlight is no different.

Hopefully this won't be turned into a "Flex vs Silverlight" piece but more of a way to empower Adobe Flex developers to gain an understanding of Silverlight through a more context driven discussion (e.g. "You know how you do x in Flex right? well in Silverlight they do it this way")

Namespaces

Typically in MXML to load in controls within your project, you would do something along the lines of this:

<mx:Application xmlns:appCntrls="com.mossyblog.controls.*"/>

<appCntrls:MyButton/>

Essentially, appCntrls:MyButton is a pointer to a file in the com/mossyblog/controls/MyButton.as (or mxml) but done so through tag based approach. It's actually quite useful in doing this as you're effectively creating your own XML vocab along with custom properties (attributes) and in Flex can even go further by nesting tags within tags (similar to DOM in essence)

Life in Silverlight is really no different, except when you make namespace declaration you're also telling the CLR where to compile the end result (DLL) , which is an interesting thing to note. As within Adobe Flex typically to do this you'd start to look into strategies around mx:Modules or Runtime Shared Libraries, which can be extremely powerful when used appropriately.

In Silverlight, to do this you simply type:

<app:MainView xmlns:app="clr-namespace:com.mossyblog.controls;assembly=MyBinDir/com.mossyblog.controls.dll">

There's more to this, but I'll discuss this another time (i.e. what does Assembly mean along with the specifics of clr-namespace)

Note: In Adobe Flex generally the xmlns (default) points to a URI path which is consistent globally (In essence this points to the framework manifest file which in turn points to the components and their respective name / path pairs within), same deal in Silverlight only it's "https://schemas.microsoft.com/client/2007" which gives the compiler the core framework reference pointer locations (will expand on this in future posts).

GEOM / Graphic Tags.

Inside Adobe Flex your entire tag based approach to life is driven from components that have a specific purpose (Usually not so much around Assets but more so in specific Navigation/Layout/Form style controls etc). In that you would rarely ever see the tag <Line> as what purpose would this serve in Flex? You could easily write a .AS file called Line.as which inside that uses the LineTo style approach to life (i.e. render a line using the drawing API + Flash.Geom Objects). That or you would typically use bitmap assets to handle a lot of the creative elements, but overall you have a lot of possibilities in Adobe Flex to handle this but are usually kept inside the actual components themselves.

In Silverlight, you're using the XAML language itself and what this means is that whenever you have a vector based asset inside your application, you in turn will see tags that outline what that "asset" is made-up off  in terms of properties and semantically marked up description (i.e. you'll hear the words brush thrown around a lot for example).

eg:
<Line x:Name="HeaderTextLine" Opacity="0" X1="25" Y1="62" X2="635" Y2="62" StrokeThickness="4">

The overall point is that you're combining the drawing tag elements with future form/layout components and default controls as they eventually come. It can be somewhat of an initial shock as coming from a Adobe Flex environment you're typically used to seeing specific tags like Accordion, Button and so on only (also custom tags like <MyForm> etc). Silverlight offers you the same approach as this, but the important piece out of all of this to understand is that with XAML all assets are marked-up in an XML format (except if you prefer to use bitmap of course).

Basic stuff right? (Let me know if that did not make sense).

However, you really don't need to be to worried about the specifics of hand-coding these tags, as Expression Blend for example takes over that burden and automagically spits this out into inline code for you (yay!). This is good thing as if you're a code nutter like me, you can wrap these pieces into composite components, which house the XAML code within (just like you'd make your own MXML component out of the Adobe Flex Framework primitives etc).

Next Post.. Code-behinds and XAML

P.S
If there is a part of Silverlight you want me to cover in this "How to" approach, please leave comments as I'll do it! :)

Comments