[sm-users] POTENTIAL BREAKING CHANGE: Streamlined Xml configuration

[Jeremy Miller]

Everybody,

I'm tearing into StructureMap's Xml support to begin the 3.0 release.
For a variety of reasons, I'd like to streamline the Xml configuration
going forward in 3.0. I'm not sure how many people still use the Xml
configuration for many things, but I'd like to ditch some older
syntax. Specifically, I'd like to keep:

<StructureMap DefaultProfile="">
<Registry Type="StructureMap.Testing.XmlFileRegistry,
StructureMap.Testing"></Registry>

<AddInstance PluginType="" PluggedType="">
<!-- more args -->
</AddInstance>

<DefaultInstance />

<Profile Name="blah">
<Override />
<!-- more instances -->
</Profile>
</StructureMap>

AND DITCH EVERYTHING ELSE.

So, goodbye to <PluginFamily>, <Plugin>, <Include>, <Assembly>,
<Interceptor>

NEW ADDITIONS:

<AddInstance> would support Scope/Lifecycle on an Instance by Instance
basis

<!-- This is merely a proposal -->
<AliasType Alias="easy to read name" Type="assembly qualified name" />

ATTRIBUTE STYLE VS NODE STYLE:

I'm also suggesting that the node normalized business goes away:
http://structuremap.github.com/structuremap/NodeNormalized.htm

and only the "attribute style" remains as the only way to do things:
http://structuremap.github.com/structuremap/AttributeNormalized.htm

I frankly feel like it's getting to the point where Xml configuration
is a second class citizen. Most externalization of configuration can
be done now without resorting to Xml configuration. You can always
externalize the *data* fed into services and/or use branching logic
inside the ObjectFactory.Initialize() or Registry classes.

I'm looking for feedback here. I didn't really want to make any
breaking changes for 3.0, but since I'm already making so many changes
for the Xml (partially in preparation for Silverlight), I thought I
might as well clean out the historical baggage.

--
You received this message because you are subscribed to the Google Groups "structuremap-users" group.
To post to this group, send email to structure...@googlegroups.com.
To unsubscribe from this group, send email to structuremap-us...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/structuremap-users?hl=en.

[Jason Imison]

We're currently using a mixture of Xml and DSL config. What you are
proposing to keep is enough for us.... but we can't switch to trunk
because of the following bug.

http://groups.google.com/group/structuremap-users/browse_thread/thread/a690ebb2295a6443/58a5d827188c0477?show_docid=58a5d827188c0477

[Chris B]

I think the above proposal sounds pretty good and seems to retain the
features I need, although I have not taken a really serious look at
it. I will say that in a project I work on, we need XML registration
because we do not want to have compile time references to certain
implementations, even in the registries. Perhaps there is a better
way for us to handle this through StructureMap, and, more likely,
better architectures which wouldn't put us in this position in the
first place, but for the time being, we are where we are and the XML
configuration is a must-have feature for us.

I will also put my vote in for the "type aliases" feature. I find
meaningful type aliases much easier to read than type names, so I
would consider it to be very helpful.