I have also thought of similar ideas. However mine were more code centric,
not XAML.
For example if you want to create a DependecyProperty or RoutedEvent you
have to write a lot of code in a static language like
DependecyProperty.Register(...) and you end up with something like 20 lines
of code including all the property changed, coerce, validate handlers. This
can be a lot simpler in a dynamic language like ruby when you can have
approach similar to rails' active record: has_many: or belongs_to:
I think we should try to avoid going away from XAML, because this is our
common language with designers. They live in tools like Blend and even
Visual Studio is cumbersome for some of them. What we can have there is some
kind of ruby markup extension that will allow us to do dynamic dispatch or
something similar.
P.S.: You can check a simple "still buggy" tool I have developed DLR
Pad<http://www.codeplex.com/DlrPad>(XAML Pad with DLR scripting).
Regards,
Stefan
2008/7/10 Ivan Porto Carrero <ivan at flanders.co.nz>:
> 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 at rubyforge.org>http://rubyforge.org/mailman/listinfo/ironruby-core>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080710/f3e75c27/attachment.html>