[Gtk-sharp-list] Serialization Compliance Problems

Marc Clifton webmaster@knowledgeautomation.com
Sun, 15 Aug 2004 17:57:09 -0400


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Probably the best way to handle this is to have the Window class
implement ISupportInitialize.&nbsp; Then, on the EndInit() call (which
MyXaml supports), the GTK# can make the appropriate constructor call
into gtk+.<br>
<br>
This solution is, BTW, a non-MyXaml specific suggestion.&nbsp; The
ISupportInitialize interface is designed specifically for this
purpose--to allow construction and order independent property setting,
then the "real work" is done in the EndInit() callback.&nbsp; MyXaml
supports it because many other .NET UI classes support and even require
that BeginInit() and/or EndInit() are called during property setting,
so that any action taken by those setters can be deferred until the
whole kit and kaboodle has been initialized.&nbsp; All MyXaml does is look
to see if the class being instantiated implements the
ISupportInitialize interface.<br>
<br>
Marc<br>
<br>
Todd Berman wrote:<br>
<blockquote cite="mid1092605774.3065.1.camel@localhost.localdomain"
 type="cite">
  <pre wrap="">The problem with this, is that there are some ctors that won't function
properly, as certain properties are only settable when the ctor is done.

Forexample, setting the WindowType in a new Gtk.Window is only possible
when you create it, so a default () ctor would not allow this to be
used.

There are other examples of this, where there are ctors that allow you
to modify things that are not changeable later in the objects lifecycle.

This is a gtk+ issue, that we are basically unable to workaround.

How would MyXAML handle cases such as this?

--Todd

On Sun, 2004-15-08 at 17:14 -0400, Marc Clifton wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello John,

Yes, the default constructors would appear to be trivial, but no it's 
not a deficiency in MyXaml.  As to other MyXaml supported by other 
toolkits, many toolkits by their very nature work well with MyXaml 
because they are implemented so as to support serialization.  In 
particular MyXaml works 100% with VG.net, a vector graphics engine and 
which serializes to MyXaml, and near 100% with other third party 
toolkits such as DevExpress, DevComponents and Infragistics.

There is nothing in the MyXaml core parser that is SWF specific.  What 
is required is only a compliance with some architectural guidelines 
which I have previously written about.  These guidelines aren't 
something that is MyXaml specific but applies to all XAML-like generic 
parsers, and I agree with you, that it doesn't seem like it would take 
too much work.  Doing so would actually be of benefit to GTK#, IMO, 
because it would bring GTK# more in line with the .NET architecture, and 
therefore would satisfy serialization requirements.

As it is now, without writing a custom parser to support GTK# classes, 
properties, methods and events, how would you go about implementing a 
front-end designer, for example?  It seems like by following some simple 
architectural guidelines in GTK#, one could avoid a lot of extra work by 
simplifying current serialization issues.

Marc

John Luke wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Hello,

Speaking only for myself, I think your review is incomplete.  Adding
default constructors would be trivial, but no-one had previously
requested it, and you yourself seem to indicate it is a deficiency of
MyXAML.  The other issues, I think you will find that you are
depending on many things that are SWF specific, I wonder what other
toolkits would fit that description without some effort.  I looked
(very briefly) but did not find a list of toolkits supported by
MyXAML.

In any manner, I think that .NET guideline support will have a
priority over this, unless someone takes an active role in doing so,
it doesn't seem to require too much work.


----- Original Message -----
From: Marc Clifton <a class="moz-txt-link-rfc2396E" href="mailto:webmaster@knowledgeautomation.com">&lt;webmaster@knowledgeautomation.com&gt;</a>
Date: Sun, 15 Aug 2004 13:59:25 -0400
Subject: [Gtk-sharp-list] Serialization Compliance Problems
To: <a class="moz-txt-link-abbreviated" href="mailto:gtk-sharp-list@ximian.com">gtk-sharp-list@ximian.com</a>

Hello all,

I have done a cursory review of using GTK# with MyXaml and I've found
it to be lacking some basic tennets of XAML-friendly classes.  I've
posted the review here:

<a class="moz-txt-link-freetext" href="http://myxaml.com/marcclifton/archive/2004/08/15/433.aspx">http://myxaml.com/marcclifton/archive/2004/08/15/433.aspx</a>

and I'm wondering if the GTK# group has any interest in making GTK#
compatible with serializing object graphs into XML using a generic
parser such as MyXaml.  Personally, I feel that this would be a
worthwhile endeavor.

Regards,

Marc Clifton
_______________________________________________ Gtk-sharp-list
maillist - <a class="moz-txt-link-abbreviated" href="mailto:Gtk-sharp-list@lists.ximian.com">Gtk-sharp-list@lists.ximian.com</a>
<a class="moz-txt-link-freetext" href="http://lists.ximian.com/mailman/listinfo/gtk-sharp-list">http://lists.ximian.com/mailman/listinfo/gtk-sharp-list</a>


 

      </pre>
    </blockquote>
    <pre wrap="">_______________________________________________
Gtk-sharp-list maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:Gtk-sharp-list@lists.ximian.com">Gtk-sharp-list@lists.ximian.com</a>
<a class="moz-txt-link-freetext" href="http://lists.ximian.com/mailman/listinfo/gtk-sharp-list">http://lists.ximian.com/mailman/listinfo/gtk-sharp-list</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->


  </pre>
</blockquote>
<br>
</body>
</html>