Silverlight 2.0

DLRScript 0.55 released for Silverlight2 Beta2

Jay Kimble — Thu, 24 Jul 2008 20:12:15 GMT

[UPDATE: I forgot to add the link to the project - http://www.codeplex.com/dlrscript/]

It took a bit of time for this release. In the end I had to take everything a step back (as well as there are probably a few "mid thoughts" in here as the release of SL2 Beta 2 caught me a bit by surprise... actually the changes to the DLR caught me more by surprise).

The step back is that we no longer get script code lines when there are issues. I’ll try to bring this feature back, but right now if it breaks, you’ll know it via an alert with a .NET error.

Future direction
I need some feedback on this. I’ve been thinking about scrapping any attempt at jscript compatibility and am thinking more about ecma3 support (DLRJScript has an ecma3 mode). The benefit there is that I could start focusing on building a better set of client-side APIs instead of a more compatible one. That said, I’m not sure how qualified I am at coming up with a "better" set of client-side APIs.

I do want some feedback though. Let me know what you think: jkimble-at-gmail.com.

Tampa User eXperience (TUX) User Group is coming September 10th, 2008…

Jay Kimble — Fri, 18 Jul 2008 03:35:18 GMT

I am proud to announce that I and a couple other guys are starting User Group that revolves around User Experience (or UX) in the MS tools eco-system. The other guys are Shawn Cady, Perry Panagopoulos, and Bill Reiss (MVP) [Bill always gets his MVP props].

I could give you all their backgrounds, but I’ll make them do it at the first meeting. I’m sure Papa Fish (aka www.devfish.net) the local MS Dev Evangelist (my Blog Father) Joe Healy will be around (at least for the first meeting).

TUX' Focus
Our focus will be on the "now" of Ajax and how it integrates with ASP.NET (in all its various forms), and the "future" of Silverlight2, and anything in between (like adding Silverlight2 controls to Ajax sites, etc); we’ll not be stuck in just Web either... we’ll probably do some WPF as well. We’ll also be dealing with some of those more abstract things that you need to get better at (like how to be a better designer, creating good user experiences, etc.), and we will do our best to keep this group "devsigner-friendly" (devsigner is a developer who is also a designer).

We have a lot of really creative ideas to make this fun and useful to you today as well as with an eye for the future (but I don’t want to blow them all)... We will definitely keep this interactive and will try to help you solve your problems as well (at least we’ll be around to chat with you before and afterward).

First Talk: Intro To MS Ajax Scripting
The first person to present will be me. I will be pulling a talk out of my paid pile which means that you have probably never seen me give this talk (unless you work at one of the companies I gave it at)... this is very special and will never be repeated (well, maybe). This talk is one that I have yet to see anyone give (for free). It’s an introduction to the MS Ajax scripting framework. Oftentimes you see a demo where someone shows you how to build an Ajax Extender control where a JavaScript is thrown in, but rarely (I’ve never seen it done) does someone talk to you about building the script behavior which is used to create the Server-Side Extender (I will in fact be doing just this). You will leave this talk with the knowledge of how to do it. As is often the case when I talk about JavaScript, I’ll end with a Script# demo which will make your life a lot easier (so we’ll build the last demo in C# which will be compiled to MS Ajax-style JavaScript); this big demo is a selection grid behavior that I built for my employer to replace a commercial grid component that we were using; you’ll definitely have a use for it.

Bonus
We’ll have Pizza provided by Answers Systems, so just get there after work... you don’t need to eat first.

AND!!!! Bill Reiss (MVP) has graciously given us an MSDN Premium Subscription (used to be MSDN Universal) to give away, so don’t miss it.

Where/When will it be?
We will be holding these events at my workplace: Answers Systems in Oldsmar, FL. Better directions than this will follow in the near future (we will have a web site soon), but it’s right next to (West of) the Oldsmar Fleamarket on Tampa Rd (aka Hillsborough Ave). We plan to open the doors at 6:30pm with the activities starting at 7:00pm.

Can’t make it, but you really wanted to see my session?
<sarcasm>So you are in my fan club (Eric Wise, I know that’s you since you maintain some of my stellar code), but you live in another state (like say the cold state of Ohio... where it’s 40 degrees Fahrenheit in August) so there is no way you could see this session by me, but you really, really want to see it, but the plane ticket is so expensive.</sarcasm>

Well, we plan on videoing our sessions and making them available online (as long as the speaker is OK with it, and I am... SO this is the LAST time I’ll be able to charge for this session... unless I revamp it which I will).

Afterwards...
I’m not Joe Healy so I can’t pick up the tab, but there is a Starbucks down the street that many of my colleagues and I like to frequent (Stimulants... I need a good stimulant not a depressant... but we could be talked into depressants), so don’t be surprised if we all end up somewhere afterwards or maybe somewhere else...

RSVP
If you plan on coming please drop me a line via the contact form on this site. We need this to help us figure out how much Pizza to buy.

PS
In October (the 2nd Wednesday), Bill will be doing a Silverlight2 talk (He’s a Silverlight MVP and a soon-to-be Silverlight book author). It will be more of an intro, but he plans on really giving a nice overview from both the diesgn standpoint and the development standpoint.

And, yes, we actually have a a list of things we’re thinking about for November... nothing definitive (yet), but we plan on being way ahead of the game (as best as we can).

Types of Silverlight2 apps

Jay Kimble — Mon, 07 Jul 2008 21:03:02 GMT

I want to go on record for a prediction. I believe when the dust settles with Silverlight2 (SL2, hereafter), we will have 2 major types of apps. To me this is fairly obvious, but if all you did was look at SL2 tutorials you would get a different view altogether. You see all the tutorials that exist out there show you what I think is the preferred way: a single application that lives in the browser as a plugin.

I also see another SL2 type of app: the SL2 enhanced Ajax App. Seriously, there will be those who will use some of the fancy SL2 controls (and I’m talking about the third party ones that will be developed) to bring their Ajax apps into a new domain. So from a plumbing perspective they will stick with the familiar page model we have today. I think the draw of Ajax is strong and I would rather this not happen because it is my view that the SL2 framework is way better than classic DHTML/Ajax/Web2.0. There are those who will say, "I can’t leave the rich experience of JS on the client." (phooey... just code in DLR JScript instead if you want JavaScript).

BTW, I also see a third model. The old model built with a single Sl2 applet on each page. I think this will be a minor idea, but I see it coming.

-----------

On another note, I’ll be putting up a few SL2 posts. I have been doing a fair bit of work with it in the last month or so. It definitely involves a slightly different mentality than classic web apps.

My SL2 prototype actually uses a REST service built with MS MVC and with the MVC Contrib project’s Restful feature. I will write some on this in the not too distant future. I have really grown to like REST (and building a service the way I have is really great for quick prototyping).

I’m actually starting to chew on Databinding (and doing CRUD operations on the data), so in time I’ll be writing about some of that stuff too.

--------------

Additionally, I am also working on starting a .NET UX user group here in Tampa Bay. I’m working with a couple of the local personalities to bring together a really good group. The group would focus on MS Ajax (and other Ajax Frameworks with ASP.NET and MS MVC) and Silverlight2 based apps. I can’t wait. It’s really exciting!

Papa to write Silverlight2 book

Jay Kimble — Fri, 16 May 2008 17:38:19 GMT

My buddy JP (John Papa) is writing a Silverlight2 book. See his blog here and here for more info. JP is known for his DataPoints column in MSDN magazine (and he is an MV, a former co-worker, and former co-blogger... SO, I read his blog).

I found this out a day after I visited the Manning site and purchased to EAP Silverlight2 books. I wish I had known I would have seen what I could do to purchase an early release of JP’s book.

Needless to say I expect John’s book to be really good. I know that he’s an awesome communicator, and has been heavily in this whole XAML space for a while.

I won’t write about my newly-purchased Manning books yet (especially since this is a post where I push John’s book).

Silverlight2 Programming: The Designer Rule

Jay Kimble — Tue, 13 May 2008 16:04:43 GMT

I’m starting a new series on Silverlight2. I am currently building a little SL2 prototype, and as I am learning things I thought I would write them down here.

The first rule deals with working with Designers. It is stated as such.

"Prefer XAML code to CLR/DLR code when it comes building interfaces"

Note the word "prefer" here. That word means "usually", "normally", or "unless there is an exception."

This is best explained by some C# code I saw the other day. It looked something like this:

        1: string ElementX = @"<div class='twocolumndiv'><span class='singlecolumn'>{0}</span><span class='singlecolumn'>{1}</span>";
  

The problem with the above code is that you’ve embedded it into your code. It’s effectively buried. If someone else needs to change this template to say add a field or to make changes in any manner, they are scanning the code looking for this (provided they know where to look); this will be the cause of much swearing and maligning of your name.

To make matters worse, if you have a web designer you have effectively removed their visibility to this code (maybe this point is made a little sharply; I know some web designers who would be scanning the code as well, but they wouldn’t be happy).

So how does this relate to SilverLight 2? Simple, you should try to avoid instantiate controls on your Silverlight views (pages??) that a designer has no visibility to (in other words, using a UserControl that has an associated XAML is fine, but instantiating a new UserControl and throwing a new layout and a bunch of text boxes should be done with great care... you should know why you did it that way).

DLRScript update

Jay Kimble — Thu, 24 Apr 2008 15:46:22 GMT

I have begun working on DLRJScript-JavaScript compatibility. I was actually successful running my first externally created JavaScript -- EcmaUnit 0.4 (which is a small JS testing framework). I did have to make a couple modifications.

I’m becoming aware of the size of this job though. I’m currently porting a Mozilla-compatible XmlHttpRequest object which I think will work with all the major Ajax frameworks. I’m not sure which Ajax Framework I’ll actually target as the first on to run. I could stick with the man and make it work with the MS Ajax client library, I could go with Prototype that so many people swear by or I could use something else (JQuery is looking rather interesting to me in this regard). The biggest thing I require though is either an extensive sample project or a test suite itself. This makes it easier to see if my JavaScript replacement is working OK or not. Once I have a reasonable compatibility (one or more frameworks working fairly good with minimal issues) then I’ll move over to making the various languages capable of communicating with one another (so I can loadup JQuery and then use it, clientside, from Iron Ruby).

In case you forget why you might want to do this, it’s simple really; DLRJscript is faster (because it’s compiled) then traditional JavaScript (which is interpreted).

DLRScript 0.5 Notes...

Jay Kimble — Mon, 14 Apr 2008 18:33:12 GMT

As you may or may not have seen, over the weekend I released a new version of my DLRScript project. It’s coming along. It adds 3 things: File loading via the src attribute, better exception reporting for DLRJScript(it shows you what line of script code failed), and improved DLRJScript performance.

File Loading
I could probably write a bunch on this (and probably should in another article). Basically I am dynamically loading content (script files) from the server. I also extended HTML a bit in that you can now use the same script tag to load a script from the server and to write additional code that will load after the script has loaded. It looks like this:

        1: <script type="DLRJScript" src="/somefile-on-the-server.js">   1:     2:     function doSomething()   3:     {   4:         // Code found here   5:     }</script>
  

JS Performance
Because of the new way I am creating the JScript engine, I get JScript code to compile, so the code that executes is faster than standard interpreted Client-Side JavaScript. I did a simple test which is within my project over on CodePlex. The test simply adds 15 <hr /> elements to a hidden div. It records the time before and after the routine. First run in the DLRJScript results in about the same speed as standard client=side JavaScript. The second run results takes about 1/2 the time and the third trip is even faster (the 4th-6th attempt takes about the same amount of time as the 3rd run, so I figure that’s as fast as it gets). I’m not sure if this implies that the DLR optimizes code even more after subsequent runs of code or not (I know the .NET spec supposedly will optimize code after it has been run a few times).

Anyway, my test is not scientific in case you are wonder. There could be additional processes on my box that may make the results vary. Everything is a very crude approximation. I did run the client-side version several times to see as well with about the same results.

The Future
Ok, my plan is to get my DLRJScript to be more compatible with standard client-side JavaScript using DOM2. Right now I know I’m not even at DOM1 spec. I will be testing various libraries to see if I can get them to run with my implementation. It may result in a faster way to run JavaScript in the browser. Also, since the code is really running within the SilverLight plugin, the script code should be standardized and run the same in every browser (well, at least in theory).

DLRScript Update

Jay Kimble — Tue, 18 Mar 2008 13:36:00 GMT

In the next week or so I will be releasing a new version of my DLRScript. It will have external file sourcing/loading via the src attribute (I have that working right now). I would release it today except for 1 issue.

what is in the file is this

//JS:
jsapi.alert("Hi JScript here");

#Python
jsapi.alert("Hi Python here")

#Ruby
$jsapi.alert("Hi, I'm Ruby and YOU are NOT!")

Here's the issue. I think I discovered a bug (in my code). When you try to launch multiple alert boxes you get 1 of them and errors for the rest. Which makes sense to me (as you the user need to click the button on one of the Alerts. I will correct this.

I also discovered another subtle little issue that I want to account for. The problem is that since we are moving code Asynchronously there are multiple threads involved. My current development executes code as it gets code back, but it should execute this stuff in the order it appears on the page (I'll be correcting that one too)

Probably the next week or so, and then I'll be moving forward on my other ideas (most notably the Object Model).

Ruby DOM??

While I'm on the subject of Object Models, I had some discussions with some friends to see if I should duplicate client-JavaScript's DOM model or if I should create something else.

The wisdom from both seemed to be that duplicating client-JS' DOM for JScript and Python would be good, but you Ruby guys would something that is Rubyish (no, not rubish... I said Rubyish). I was wondering if I might get a Ruby programmer to help me understand what that means (cause neither of my friends can answer that question).

So here is the question. If you had the ability to write Ruby code as a client language (and you can with DLRScript) what would the framework look like?

DLRScript... Now With Added Ruby!

Jay Kimble — Thu, 13 Mar 2008 14:35:00 GMT

Just a quick announcement. My DLRScript (use DLR Languages in Script Tags via Silverlight 2) project just released a new version with a new language: Ruby.

I'm really excited to have this working. As I get time watch for more improvements.

DLRScript release 0.2.2a

Jay Kimble — Tue, 04 Mar 2008 21:58:00 GMT

I skipped blogging about the last release mainly because I have been busy trying to find work (as well as preparing for a training I'm doing this month). Anyway, I thought I should put out a little update, so my readers know that I have made a new release.

New Language!

If you've seen the download page you will notice that I have a new language, and no, it's not the language I wanted to add. It's not Ruby. I figured out how to get DLR JScript (and I'm calling it that so as to not confuse it with JavaScript the client-side code -- which exposes some objects to DLRScript)

Object Cleanup

With the last release I cleaned up a little code, and renamed the DomHelper object to jsapi. I'm still not 100% thrilled with that name, but for now it works. Basically this object exposes certain DOM functionalities to DLRScript languages as well as exposes a couple JavaScript (client-side) functions/features like alert, confirm, prompt, and eval (although the latter still seems to be working a little strangely). I will be adding setTimeout/clearTimeout once I have the time. They are there, but not very usable (or useful). You can probably use setTimeout, but won't be able to stop it, and only against client-side (non-DLR) JavaScript functions. At some point I'll make it possible to hook up your DLRScript language's functions to setTimeout/clearTimeout

I also felt like I should respect the camel-case of aspect of JavaScript, so I switched the functions to camel-case (first character is lowercase then the first char of each "word" is uppercase).

Additional Object abstraction

I normally wouldn't do this, but I needed to do this so I could begin to introduce a few streamlined properties. Here's the objects:

HtmlObject
- HtmlDocument
- HtmlElement

You can probably guess that HtmlObject is a parent to the other two (and you would be correct). One of the things I introduced was a cross-browser "text" property for all objects returned from a getElementById (or the document object).

This also let me enable a number of pieces of functionality you would fully expect (stuff like attaching/detaching events, adding/removing new elements/attributes, reading/setting properties/tag attribute/styles, etc.

I will eventually start beefing this up so that you don't have to resort to using the function to read a property (or to read a style)

What's next?

Well, I really, really, really(!!) want to get IronRuby working. I'm hoping that after Mix08 that should be a little easier to do. Once I do that then I think I'll do a little bit of work on the object model, and will start looking at adding things like communications support. I also NEED to get the script tags to load DLR scripts from the web server (and more importantly cache them!)

I also want to test inter-language communication... maybe Python is better at a task then say Ruby (not sure, so don't be shooting me over the comment), but you want to create more of a DSL (which Ruby is stellar at)... You could potentially write some functions in Python and use them from Ruby.

So basically I have my work cut out for me... Oh yeah, the DLRScript Project is here. It comes with a couple sample files for you.