Hi 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. Thougths? Thanks Ivan
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
