[MonoDevelop] Stetic code generator

[Lluis Sanchez]

El dv 30 de 06 del 2006 a les 09:52 +0200, en/na Juan Cristóbal Olivares
va escriure:
> I have been thinking about a better way to generate code from the
> stetic XML. 
> 
> The actual schema is something like this:
> 
> Visual Designer
>  ||
> <==>
>  ||
> XML
>  ||
>  =>
>  ||
> Code Generation
>  ||
>  =>
>  ||
> Source Code
> 
> But there are some issues with the generated code:
> 
> 1.- The widgets are not intances of our class (Gtk.Window) and we need
> to cast (from and to) the widgets, not checking types with the
> compiller 

You can use the "Bind to Field" button to create fields for the widgets,
which have the real type, so no need to cast.

> 2.- The signal handlers are connected on execution time (not compiller
> check)

ok, but is this a real problem?

> 3.- No code completion for the widgets (same reason)

You get code completion for bound fields.

> 
> So, the opposite option is to generate all the widgets as instances,
> but then the problem is to parse the source file (model of VS.NET
> 2002/2003)
> 
> But there's other way, taking an approach similar to the VS.NET 2005.
> It's to create a partial class. So, for example, if we create a visual
> interface (stetic) for this class: 
> 
> public class MyWindow : Gtk.Window
> 
> we can change it to a partial class (currently supported my both mcs
> and gmcs):
> 
> public partial class MyWindow : GtkWindow
> 
> and create other file (like MyWindow.Generated.cs ) with the same
> partial class, implementing all the widgets of the visual design. 
> 
> With this, all the issues are solved and there's no need to parse the
> source file because the visual designer is always based on the xml
> file (just like the actual behavior). 
> 
> But, oops.. ok the problem is that this is only supported for C#
> (because of the 'partial' keyword)... uhm... so it should be better to
> have the code in a hidden #region? (I like partial)...
> 
> Ideas?

Using partial classes is probably a better solution, but given the
current status of .NET 2.0 in Mono and the existing priorities in
MonoDevelop, I think the current code generation model is good enough
for most of our current needs.

Lluis.