Gerald Bauer
2005-03-11 18:45:03 UTC
Hello,
Marc Clifton writes:
I am releasing a preview of MyXaml 2.0 so people can get a sneak peek
at what is coming down the road. After evaluating the MyXaml 1.0,
taking into consideration customer feedback, and looking at how to
position MyXaml 2.0 for future endeavors, I have reworked the code
base with several architectural and implementation changes.
Please note, this is a preview version. Do not replace MyXaml 1.0
with this preview version, as there are several features of MyXaml 1.0
that have not yet been migrated over to 2.0.
Creation Of A Core Parser
Several of my customers have requested that MyXaml not be coupled to
the System.Windows.Forms namespace. Separating the parser from the
presentation layer makes a lot of sense. With 2.0, you can use the
parser in contexts that do not require a presentation layer. You can
also apply the parser to different presentation implementations-web
and compact framework, for example.
Plug-In Extenders
The System.Windows.Forms namespace must of course still be supported.
Issues such as SuspendLayout and ResumeLayout, working with data
binding, image lists, etc., will be implemented using the new extender
feature. I haven't yet migrated all of the .NET 1.1 ""helpers" from
MyXaml 1.0 to 2.0, but you can see an example of supporting the
Suspend/ResumeLayout method calls for SWF by using an extender. The
extender feature will also be used to manage any implementation
differences/improvements found in 2.0 and support for inline code.
The extender feature is also going to be relied on to help work with
third party toolkits that aren't declarative-friendly. By using a
combination of extender and component abstraction, it should be
possible to overcome all of the problems present in these third party
toolkits. The idea is to then offer different extenders for different
toolkits. For example, there are five or six flavors of docking
managers out there. The goal of the plug-in extender framework is to
be able to use the same markup source, plugging in the specific
docking manager extender for the third party toolkit you're using in
the application. This helps to reduce "vendor lock" and even more
importantly, problems that arise when a vendor releases a new version
that breaks existing implementation. The declarative aspects of your
application should be immune to these breaking changes. Instead, only
an update to the extender plug-in needs to be made.
Exceptions
MyXaml 2.0, rather than using Trace statements to indicate errors, now
throws exceptions. In the preview release, there are 27 different
exceptions that the parser generates. While I'm not particularly fond
of exceptions, many of customers (and admittedly I too) have wasted a
lot of time tracking down object graph problems which is only noted by
a trace message buried deep in the instantiation process.
Unit Testing
Have 27 different exceptions doesn't help if you don't test those
exceptions. MyXaml 2.0 includes over 90 unit tests. These tests
validate the parser's functionality, exception generation, and
provides simple but useful examples of the features and object graphs
that can be constructed. The unit tests require the Advanced Unit
Test (AUT) tool, one of my other open source projects.
Code Path Coverage
The main property setter method presently contains 56 different valid
code paths (by valid, I mean code paths that don't result in an
exception). In addition to the unit tests, there is a test fixture
dedicated to ensuring that each of these code paths is exercised (this
is another reason for the AUT requirement as the test tool).
Documentation
I must admit a certain frustration with other open source projects and
the lack of code documentation. MyXaml is small but complicated, and
I have gone through the code with a fine toothed comb and documented
every field, property, class, and method in this release. The result
is a very nice nDoc generated CHM file. This file and the code
documentation should be of great value to people who need to
understand the working of the parser, especially when a third party
assembly is causing difficulties in a declarative context.
Old Features, New Features
MyXaml 1.0 supported the compound property syntax found in Microsoft's
XAML. This support has been eliminated. As to new features, this
release includes support for nested class instantiation (see the unit
tests) and assignment to properties whose type is Type--a useful feature.
Licensing
Customers that have purchased a MyXaml 1.0 license can upgrade to
MyXaml 2.0 without additional licensing.
Feedback
Your feedback is desired! I'd like to see markup examples that should
work but don't--either they throw an exception or they generate
unexpected results. Also, let me know what you think of the extender
architecture--it's very simple. Is this a good approach? If anyone
is interested in developing an extender for a particular third party
toolkit (docking managers come to mind), let me know!
Conclusion
As you can see, a lot of thought and care is being put into this
release. Many people ask, "why use MyXaml instead of XAML?" I think
you can see from the above discussion that declarative programming
isn't just about vector graphics and object graphs. It requires an
architecture that supports what people are trying to do
declaratively--work in different environments, offer customization for
application specific needs, and address real world issues such as
complex third party toolkits, all in a well documented and rigorously
tested open source framework. That's the MyXaml difference.
Download the preview version of MyXaml 2.0 here.
Source: http://myxaml.com/marcclifton/archive/2005/03/11/1717.aspx
- Gerald
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com
Marc Clifton writes:
I am releasing a preview of MyXaml 2.0 so people can get a sneak peek
at what is coming down the road. After evaluating the MyXaml 1.0,
taking into consideration customer feedback, and looking at how to
position MyXaml 2.0 for future endeavors, I have reworked the code
base with several architectural and implementation changes.
Please note, this is a preview version. Do not replace MyXaml 1.0
with this preview version, as there are several features of MyXaml 1.0
that have not yet been migrated over to 2.0.
Creation Of A Core Parser
Several of my customers have requested that MyXaml not be coupled to
the System.Windows.Forms namespace. Separating the parser from the
presentation layer makes a lot of sense. With 2.0, you can use the
parser in contexts that do not require a presentation layer. You can
also apply the parser to different presentation implementations-web
and compact framework, for example.
Plug-In Extenders
The System.Windows.Forms namespace must of course still be supported.
Issues such as SuspendLayout and ResumeLayout, working with data
binding, image lists, etc., will be implemented using the new extender
feature. I haven't yet migrated all of the .NET 1.1 ""helpers" from
MyXaml 1.0 to 2.0, but you can see an example of supporting the
Suspend/ResumeLayout method calls for SWF by using an extender. The
extender feature will also be used to manage any implementation
differences/improvements found in 2.0 and support for inline code.
The extender feature is also going to be relied on to help work with
third party toolkits that aren't declarative-friendly. By using a
combination of extender and component abstraction, it should be
possible to overcome all of the problems present in these third party
toolkits. The idea is to then offer different extenders for different
toolkits. For example, there are five or six flavors of docking
managers out there. The goal of the plug-in extender framework is to
be able to use the same markup source, plugging in the specific
docking manager extender for the third party toolkit you're using in
the application. This helps to reduce "vendor lock" and even more
importantly, problems that arise when a vendor releases a new version
that breaks existing implementation. The declarative aspects of your
application should be immune to these breaking changes. Instead, only
an update to the extender plug-in needs to be made.
Exceptions
MyXaml 2.0, rather than using Trace statements to indicate errors, now
throws exceptions. In the preview release, there are 27 different
exceptions that the parser generates. While I'm not particularly fond
of exceptions, many of customers (and admittedly I too) have wasted a
lot of time tracking down object graph problems which is only noted by
a trace message buried deep in the instantiation process.
Unit Testing
Have 27 different exceptions doesn't help if you don't test those
exceptions. MyXaml 2.0 includes over 90 unit tests. These tests
validate the parser's functionality, exception generation, and
provides simple but useful examples of the features and object graphs
that can be constructed. The unit tests require the Advanced Unit
Test (AUT) tool, one of my other open source projects.
Code Path Coverage
The main property setter method presently contains 56 different valid
code paths (by valid, I mean code paths that don't result in an
exception). In addition to the unit tests, there is a test fixture
dedicated to ensuring that each of these code paths is exercised (this
is another reason for the AUT requirement as the test tool).
Documentation
I must admit a certain frustration with other open source projects and
the lack of code documentation. MyXaml is small but complicated, and
I have gone through the code with a fine toothed comb and documented
every field, property, class, and method in this release. The result
is a very nice nDoc generated CHM file. This file and the code
documentation should be of great value to people who need to
understand the working of the parser, especially when a third party
assembly is causing difficulties in a declarative context.
Old Features, New Features
MyXaml 1.0 supported the compound property syntax found in Microsoft's
XAML. This support has been eliminated. As to new features, this
release includes support for nested class instantiation (see the unit
tests) and assignment to properties whose type is Type--a useful feature.
Licensing
Customers that have purchased a MyXaml 1.0 license can upgrade to
MyXaml 2.0 without additional licensing.
Feedback
Your feedback is desired! I'd like to see markup examples that should
work but don't--either they throw an exception or they generate
unexpected results. Also, let me know what you think of the extender
architecture--it's very simple. Is this a good approach? If anyone
is interested in developing an extender for a particular third party
toolkit (docking managers come to mind), let me know!
Conclusion
As you can see, a lot of thought and care is being put into this
release. Many people ask, "why use MyXaml instead of XAML?" I think
you can see from the above discussion that declarative programming
isn't just about vector graphics and object graphs. It requires an
architecture that supports what people are trying to do
declaratively--work in different environments, offer customization for
application specific needs, and address real world issues such as
complex third party toolkits, all in a well documented and rigorously
tested open source framework. That's the MyXaml difference.
Download the preview version of MyXaml 2.0 here.
Source: http://myxaml.com/marcclifton/archive/2005/03/11/1717.aspx
- Gerald
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com