DLRScript is a SilverLight 2.0 sample using the DLR. It lets you use DLR-based languages in the Script tag of a normal HTML (or .aspx, or .jsp or .php, etc.) page.
DLRScript News Feed
Wednesday, September 10, 2008
I just wanted to point out to the world that my Open Source
The major difference is I am one guy (doing too much sidework that my personal projects are suffering) versus the huge Google regime. I’m also not as far as long from a compatibility perspective that I would like to be.
Once I’m done tech reviewing John Papa’s book I need to devote some more quality time to this...
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.
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.
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.
[I really should stay out of these discussions... I really should, but I can’t resist.]
The other day I saw an article on Composition over Inheritance (I forget where I saw it). The article did a good job of explaining what "composition" is. This is my simplistic understanding (which means that someone will probably come in and tell me I have
it ALL wrong... what else is new?): "composition" means essentially wrapping objects instead of direct inheritance (so instead of inheriting from X you instead have a private instance of X in your class that you use, but you create your own interface possibly
something that looks totally different from the "wrapped" class).
I only really have one concern in all this; at least with what I have read (and not necessarily the last article I read on this subject). The advice almost comes across as "thou shalt avoid inheritance (if you can)." The implication is that inheritance is
something bad. Now I understand that inheritance can complicate things in a unit testing scenario (be it TDD or POUT).
The problem is that implication that inheritance is bad. I think it might be better to discuss some things I recently did in the DLRScript source code. I recently used composition to build a compatible XMLHttpRequest object in my DLRScript environment (no,
it’s in the unreleased bits which will be released as soon as I can test it properly... I was hoping for a JQuery compatibility, but it looks like that ain’t happening this iteration). I wrapped the SilverLight HttpWebRequest object. This let me create a Mozilla/Safari-compatible
XmlHttpRequest object that has no extra features other than what those objects contain.
That said I also have some code I have had in place for some time that also works well. This code inherits from the SilverLight HtmlDocument, and creates a document object that is more in line with what we are used to seeing in client script in the browser.
the actual method names) which is already available in the HtmlElement (for instance) to get/set values of individual style properties. In this case having a few dangling methods doesn’t really hurt because I already need 90% of what is already there. I do
have to override a few methods since I need to emit DomElements (my inherited form of the HtmlElement) from getElementById instead of an HtmlElement.
My point is this. Think. Think! THINK!!! THINK!! Don’t just blindly follow a rule. Look at your code. Take control of it. Make it do what you want it to do. Make sure that it makes sense. and if someone else is going to be using it, ask
someone else if they think what you are doing makes sense. And then DOCUMENT IT!! At least provide an example of how to use it.
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
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).
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.
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">
2: function doSomething()
4: // Code found here
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
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
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
jsapi.alert("Hi JScript here");
jsapi.alert("Hi Python here")
$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).
While I'm on the subject of Object Models, I had some discussions with
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?
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.
code -- which exposes some objects to DLRScript)
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
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:
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)
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.
[You know I hate making announcements... It seems like my expectations are always higher than what actually happens. I've announced stuff before that I thought was somewhat impressive -- maybe not though-- with like zero interest]
This weekend I created a new project over at CodePlex called "DLRScript." I put this ominous description - "DLRScript is a SilverLight 2.0 sample using the DLR. It is based on the DLRConsole found in the sample
in the SilverLight 2.0 SDK, but with a new advanced twist (check back here for more info later... I want to be the first to do this which is why I'm mum on the subject) "
So let me tell you the background. I recently was pondering the new upcoming beta of SilverLight 2.0 (something I have been waiting impatiently for a year). I started thinking about some of my past demos and playing around with it. You see I have been
playing with some of the DLR languages. I have to say that I really like Python (I wish I was better with it), and Ruby is very intriguing to me as well.
I started thinking about how with SilverLight 2.0 we could actually add new languages that could be put into a script tag. So I built it..
A picture is worth 1,000 words
Here's whit it looks like-
1: <script type="DLRPython">
2: def clickHandler():
3: DomHelper.alert("Hello from Python")
4: eh = DomHelper.createEventHandler("clickHandler")
5: document.GetElementByID("clickMe").AttachEvent("onclick", eh)
If you look closely I have a custom object called DomHelper. The reason that exists is that I am currently having problems adding namespaces (but I can easily add variables to the script environment). DomHelper knows how to do a couple things. Send Alerts,
and Create An Event Handler from a method name (there are others, but I need to work on them).
That "document" variable is not the standard DOM document, but a reference to the SilverLight environment's HtmlPage.Document. Right now I am having problems with setting the property values of DOM Element (I will be fixing that soon).
Ruby both client-side and server-side.
Some caveats (it's an alpha what do you want?)
- You need to have the SilverLight 1.1 Alpha Refresh (from September) installed.
- The project is a VS2008 project so you'll need that and the VS2008 Tools for Silverlight alpha (I think this came out in December)
- I have exactly 1 DLR language working: Python.
- I will try to get Ruby working shortly.
- I have code in place for DLRJScript, but it doesn't work (I'm getting an initialization error).
- I don't have the files to try VBx.
- Everything will change after Mix and the release of the beta (unless someone from MS wants to give me a pre-release <wink />)
- The code is a mess right now, so consideer it a rough prototype (that works)
- Get ALL existing DLR Languages working (the one I haven't mentioned yet is IronScheme... are there others?)
- Be able to fully traverse the DOM (this may be working... I just may need to figure out how to get it working... a gold star to anyone who figures it out before me)
- Be able to load modules from the file system (setting a the source attribute for a DLR Language)
- Come up with a sane way to compress a python (or other language) script (maybe there already is a way that I don't know about). Python appears to be a little more chatty (and being able to minimize the download)
The project will be available to download shortly...
DLRScript News Feed