Gerald Bauer
2004-12-21 05:42:23 UTC
Hello,
Allow me to highlight Erik Radmall's analysis how XAML compares to
Spring. Erik writes:
Another area I've looked into is using Spring in a XAML world. I have
MS XAML on my system (along with MyXaml and Xamlon), and have
investigated ways to make XAML play nicely with Spring, since for
myself and many others I suspect this will be important when XAML
officially ships. It certainly makes sense for me to use XAML for
parts of my application, and I've even tested wiring my application's
entire window structure using XAML, but will realistically have to
wait for MS to release the official version to deploy it.
One inescapable conclusion of this exercise is that there is a lot of
overlap between XAML and Spring. XAML, for example, provides component
wiring and dependency resolution of object graphs like Spring, along
with event wiring like Spring, along with a bunch of other useful
features to the UI layer, like event routing that includes event
bubbling and tunneling to UI controls which Spring does not provide
(which are really UI specific).
Overall I think there are areas where XAML is really nice. You can
insert "code behind" in the XML declarations, which incidentally might
be a nice addition to Spring. There are also areas where XAML is not
so hot, with its broken XML syntax of dot notation for compound
properties, which is a design choice I find difficult to understand,
and its lack of object lifecycle semantics such differentiating
between singleton or prototype, or init-method or destroy-method
lifecycle features provided by the Spring container, which something I
was not able to find in the XAML documentation or examples. It does
not seem that XAML has been seriously considered as a platform beyond
the creation and hosting of Windows forms controls, so this does not
appear to be an oversight, rather a design choice. I should mention
that the lifecycle features Spring provides are essential to our UI
application, so replacing Spring with XAML as the container will not
work for us, and if I were to use XAML is it, I would still need to
find a way to XAML and Spring cooperate. If XAML were extended to
provide Spring's lifecycle features, then it would be an obvious
choice as a container strategy, since it would then provide the same
vital services as Spring provides my application now.
As part of the investigation I also took a look at the source for
MyXaml, and even hacked it a tad to allow the MyXaml to instantiate a
Spring object via the XAML ref="object" tag within my .xaml
definition. This was entertaining, if perhaps a little silly. It did,
however, serve to illustrate just how similar the two ideas are--that
if XAML just did X, or Spring just did Y, you could dispense with
using two overlapping technologies and simply use one. One real
possibility is to allow Spring to use its config in the same way XAML
does. I will plumb this in a bit and see what's feasible--the only
issue I see currently is there is no way to identify the main
window(s) within the Spring config, but if this issue were resolved
somehow it would be possible to use Spring in the same was as XAML.
One thing that seems pretty apparent is that XAML by itself is not a
terribly advanced or amazing technology--and it's certainly weaker in
the areas of object lifecycle semantics than Spring. One advantage it
does have over Spring is that it's going to be supported by the Big
House as a core platform, and that means there will be a slew of
integration tools and general industry support for its model, and this
is always an important consideration.
I'm still looking into the plugins idea as well, since there may be
something useful there--my only concern is not wanting to reinvent any
wheels, and consider any UI-related issues in light of the roadmap for
.NET, which includes XAML as a core strategy.
Source: http://article.gmane.org/gmane.comp.windows.dotnet.spring.devel
What's your take? Do you agree with Erik Radmall's assessment that
XAML by itself is not a terribly advanced or amazing technology--and
it's certainly weaker in the areas of object lifecycle semantics than
Spring?
- Gerald
-----------------------
Gerald Bauer
United XAML - http://unitedxaml.org
XAML Forum & News - http://xamlnews.com
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->
Allow me to highlight Erik Radmall's analysis how XAML compares to
Spring. Erik writes:
Another area I've looked into is using Spring in a XAML world. I have
MS XAML on my system (along with MyXaml and Xamlon), and have
investigated ways to make XAML play nicely with Spring, since for
myself and many others I suspect this will be important when XAML
officially ships. It certainly makes sense for me to use XAML for
parts of my application, and I've even tested wiring my application's
entire window structure using XAML, but will realistically have to
wait for MS to release the official version to deploy it.
One inescapable conclusion of this exercise is that there is a lot of
overlap between XAML and Spring. XAML, for example, provides component
wiring and dependency resolution of object graphs like Spring, along
with event wiring like Spring, along with a bunch of other useful
features to the UI layer, like event routing that includes event
bubbling and tunneling to UI controls which Spring does not provide
(which are really UI specific).
Overall I think there are areas where XAML is really nice. You can
insert "code behind" in the XML declarations, which incidentally might
be a nice addition to Spring. There are also areas where XAML is not
so hot, with its broken XML syntax of dot notation for compound
properties, which is a design choice I find difficult to understand,
and its lack of object lifecycle semantics such differentiating
between singleton or prototype, or init-method or destroy-method
lifecycle features provided by the Spring container, which something I
was not able to find in the XAML documentation or examples. It does
not seem that XAML has been seriously considered as a platform beyond
the creation and hosting of Windows forms controls, so this does not
appear to be an oversight, rather a design choice. I should mention
that the lifecycle features Spring provides are essential to our UI
application, so replacing Spring with XAML as the container will not
work for us, and if I were to use XAML is it, I would still need to
find a way to XAML and Spring cooperate. If XAML were extended to
provide Spring's lifecycle features, then it would be an obvious
choice as a container strategy, since it would then provide the same
vital services as Spring provides my application now.
As part of the investigation I also took a look at the source for
MyXaml, and even hacked it a tad to allow the MyXaml to instantiate a
Spring object via the XAML ref="object" tag within my .xaml
definition. This was entertaining, if perhaps a little silly. It did,
however, serve to illustrate just how similar the two ideas are--that
if XAML just did X, or Spring just did Y, you could dispense with
using two overlapping technologies and simply use one. One real
possibility is to allow Spring to use its config in the same way XAML
does. I will plumb this in a bit and see what's feasible--the only
issue I see currently is there is no way to identify the main
window(s) within the Spring config, but if this issue were resolved
somehow it would be possible to use Spring in the same was as XAML.
One thing that seems pretty apparent is that XAML by itself is not a
terribly advanced or amazing technology--and it's certainly weaker in
the areas of object lifecycle semantics than Spring. One advantage it
does have over Spring is that it's going to be supported by the Big
House as a core platform, and that means there will be a slew of
integration tools and general industry support for its model, and this
is always an important consideration.
I'm still looking into the plugins idea as well, since there may be
something useful there--my only concern is not wanting to reinvent any
wheels, and consider any UI-related issues in light of the roadmap for
.NET, which includes XAML as a core strategy.
Source: http://article.gmane.org/gmane.comp.windows.dotnet.spring.devel
What's your take? Do you agree with Erik Radmall's assessment that
XAML by itself is not a terribly advanced or amazing technology--and
it's certainly weaker in the areas of object lifecycle semantics than
Spring?
- Gerald
-----------------------
Gerald Bauer
United XAML - http://unitedxaml.org
XAML Forum & News - http://xamlnews.com
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->