LA.NET [EN]

Apr 29

I decided spending 1 or 2 hours looking at how we could build and encapsulate controls with Silverlight and Javascript (nothing too fancy). It was a great exercise since it helped  me understand a little more about the limitations of the current version of Silverlight. Unfortunately, 1 or 2 hours weren”t enough to build a really cool framework. However, it was more than sufficient to get a small proof of concept showing that it is possible to build a framework where you have Javascript classes that are capable of injecting xaml and intercepting the events generated by those elements. When I started thinking about this, I had the following objectives:

  • the controls should be able to inject XAML into a Canvas (or another) object specified as its parent element;
  • the controls should encapsulate all the logic for making its transition beween states (this means that it should handle mouse enter/leave events, etc);
  • the controls should fire events that can be handled by the page programmer;
  • I wanted to reuse ASP.NET AJAX  for getting OO goodies.

If you take some time to look at the code, you”ll notice several things:

  • I”ve only built a control (a button) base on the button code written by Bryant Likes. I”m not a designer, so I really don”t have the skills to reproduce the looks of the remaining standard controls :(;
  • I”ve built a base class that is responsible for getting the XAML and inserting it into the parent canvas.
  • Each derived class should override the method that generates XAML
  • There are 2 methods which are called in important times on  the lifetime of the created objects (_internalHierarchyCreated is called after the createFromXaml method has been called and _internalHierarchyAddedToControl is called after the controls have been added to the child collection of the parent element)
  • You can see that I change the text shown by the textbox of one of the buttons before adding it to the control hierarchy and that”s where I set up the event handlers(take a peek at the _internalHierachyCreated method)
  • There”s a global class that is responsible for mapping each event on a specific method of the instance responsible for that event. Each control must register himself with the class to handle the necessary events for it to work properly. When I build this class, the idea was to hook up the events directly with the “static” methods. Unfortunately, Silverlight can only handle simple method names (ie, if you to set up an event with javascript:LA.Silverlight.SilverlightEventManager.dispatchLeftMouseDownEvent, it simply won”t call that method – that”s why i created the top __XXX methods).

Now that I”ve ended my available time for playing with Silverlight controls, i think that my architecture could have been improved a lot (in fact,now that I”ve finished,i really think that it kind of sucks :)). Here are some of the things I”d do if I could start over:

  • I”d create the classes as controls (instead of simple classes);
  • I”d create a canvas element that would be usable as top control;
  • I”d probably think hard to get a list of “XAML” elements that would be wrapped by Javascript classes;
  • I”d simplify event handling code. The current demo has lots  of code that could be simplified (for instance, instead of performing a pre-registration of the control with the global SilverlightEventManager object, i”d refactor that class so that it would perform event registration in  a single step);
  • I”d add xml-script support for these elements.

As a final note, I really hope that this code is obsolete by tomorrow (or by the end of MIX). If that doesn”t happen, then we”ll have lots and lots of work trying to build WPF/e controls…

4 comments so far

  1. Mike
    12:26 am - 4-30-2007

    I”m doing exactly this work as well right now. One thing I haven”t figured out is how to get a good design time experience. I can”t get a wpfe control to render using a ControlDesigner. Any ideas?

  2. Luis Abreu
    8:15 am - 4-30-2007

    Hello Mike.

    i”m developing only client side components (ie, javascript wrappers). if you”re goingo from the server side, then i think that designers are the way to go. i think that you have several approaches here, though i haven”tr tried any. for instance, you can use the designer to inject the top control? i think that the strategy depends on the way you”re generating your controls (for instance, how do you insert the silverlight control on the page…)

  3. Garbin
    10:02 am - 4-30-2007

    Hi,

    in order to register event handlers, one approach is to assign the handler to a global-scoped variable. In this way, you have created a global method that can be referenced in XAML.

    Btw, this is the approach used in the “WPFE-Pad” sample to create a Button control.

  4. Luis Abreu
    10:25 am - 4-30-2007

    Hello Garbin.

    yeas, you can do that…by using something like that, you should end up with less code that the sample i”ve wrote. but it still sucks because of the fact that you”ll have to “translate” all the events to unique method names which are mapped back to instance methods. that”s why i don”t like having events exposed as strings…

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>