XML namespace usurpage

4 views
Skip to first unread message

Paul Stovell

unread,
Jan 2, 2010, 2:07:55 AM1/2/10
to wpf-di...@googlegroups.com
Hi Disciples,

I've been thinking about abusing a little WPF feature to make my XAML look nicer. It feels evil but actually I don't think it would be much of a problem at all. I'd love your thoughts:

http://www.paulstovell.com/xmlnsdefinition

--
Paul Stovell

Peter O'Hanlon

unread,
Jan 2, 2010, 4:41:26 AM1/2/10
to wpf-di...@googlegroups.com
Paul - the libraries that we supply to our clients make use of this trick so that they don't have to differentiate between our extensions and what's available by default. I've avoided doing this with samples because I haven't wanted to confuse people who are reading my articles, but it might be time for me to rethink that strategy if others are doing this as well. One thing though - I'm not sure if this will work with Silverlight; it didn't as of SL2 and I'm not sure if this feature has been added yet.
 
Pete

--
Peter O'Hanlon

Philipp Sumi

unread,
Jan 2, 2010, 4:56:36 AM1/2/10
to wpf-di...@googlegroups.com

I'm not sure about this. Of course, it's a convenient thing, and it greatly helps novice developers to get things stuff running because they don't have to struggle with NS declarations. But then, I think we do have differentiation through namespaces for a reason, and R# helps a great deal in managing the imports anyway. I don't think it's a show stopper though, and as evil Paul states on his blog, it's not a problem as long as not everybody's doing it. But I'd probably sacrifice the convenience of "automagic" imports to explicit and more expressive XAML - especially for a public library.

Daniel Vaughan

unread,
Jan 2, 2010, 6:00:13 AM1/2/10
to WPF Disciples
Merging namespaces is fine until a collision occurs I guess. Then I
suppose you can fall back to explicit qualification. In your
experimentation, is that the way it works?

Paul Stovell

unread,
Jan 2, 2010, 7:12:02 AM1/2/10
to wpf-di...@googlegroups.com
Hi Daniel,

Correct. Suppose you referenced Magellan, and Magellan's evil twin, Bagellan. And they both had a <Layout> element. To differentiate you would have to do:

<UserControl
   xmlns:magellan="clr-namespace:..."
   xmlns:bagellan="clr-namespace:..."
   <bagellan:Layout .../>
   <magellan:Layout .../>

Or:

  <Layout xmlns="clr-namespace:Bagellan... " />
  <Layout xmlns="clr-namespace:Magellan... " />

Interestingly, even with both assemblies referenced, and a clean rebuild, I can use <Layout> without being explicit - It seems to arbitrarily pick one of the classes. ReSharper breaks though.

There's also no reason you can't declare XmlnsDefinition attributes for two different namespaces - one for the default, and one for a custom.

So I guess the only risk is if someone used another library, and that other library had an element with the same name, it might accidentally pick the wrong one at runtime and that could cause an unexpected problem. But it's easy enough to solve by being explicit.

Paul
--
Paul Stovell

Corrado Cavalli

unread,
Jan 2, 2010, 9:55:10 AM1/2/10
to wpf-di...@googlegroups.com

Nice idea, i did that in the past but wondering what could happen if everyone will start merging its own namespaces into default one… From a curiosity POV, what about type resolution time? Will that impact?

Hope one day we’ll have “global” import into WPF/SL

 

.Corrado

Peter O'Hanlon

unread,
Jan 2, 2010, 10:55:28 AM1/2/10
to wpf-di...@googlegroups.com
As long as you follow standard namespace naming conventions, e.g. Company.Product, then you should be OK.
--
Peter O'Hanlon
Reply all
Reply to author
Forward
0 new messages