[Ironruby-core] WPF philosophy

Ivan Porto Carrero ivan at flanders.co.nz
Wed Jul 9 22:19:28 EDT 2008


I don't really know if this is an appropriate discussion but here it goes.

Ruby and Xaml at first sight a DSL is very appropriate to get rid of the xml
syntax. I'm all for that :) However the price you pay is that at that moment
only developers can change the design of the application. Blend will happily
refuse to load it for example which makes it a bad idea for projects that
are developed by a designer and a developer IMHO. What I do see happening is
and what I'll use in my chapter is smallish additions, control instantiation
and code generation dsl's at functional places in the application.
With a DSL you also loose skinning support and the lot. I would be very
happy to be proven wrong though :).
There are a lot of other places where DSL's really work like setting up
timers, threads and those things.

Furthermore because xaml controls exist in the statically typed part of the
.NET universe it's pretty hard to have controls written in Dynamic
languages.  I started the Dynamic script control that allows you to inject a
DLR based control in a XAML tree. I didn't have time to fully fix it but it
does work to a certain degree. One of the problems I have there is that I
could not get to the controls inside the dyn script control anymore, the
reason is unknown to me at this time. I put that on the back burner for now
as I have to make more progress on my book but intend to fully finish that
control when my book is finished if nobody else has done one by then or you
tell me you will have something like that when IR goes 1.0.  I think it
would be great to be able to use DLR controls with similar paradigms as
their CLR cousins.

Then another avenue I've been thinking about is a couple of rake tasks that
will take a control tree and spit out the CLR based control with stub event
handlers etc so that a designer can still change it but the real
implementation of the event handlers occurs in a monkey patched version of
that control. This should give you the best of both worlds because you don't
need to venture into C# while retaining full tooling support. A downside to
this approach is that you will always have a compilation step after you make
a change to the design of a control.  This is the approach the guys of
rucola (a rails like framework for rubycocoa) are taking with interface
builder. While blend is no interface builder there are some similarities.

A last approach I have in mind but I tend to think that this is a bad one :)
A XAML template engine. I think its a bad idea because you lose everything
designer support, databinding and dsl niceness.

As a conclusion I think I would probably favor a mixture of approach 1-3
with approach 3 being the predominant one and approach 1-2 when needed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080710/3a93d719/attachment.html>

More information about the Ironruby-core mailing list