Archive for the ‘Uncategorized’ Category

Unpacking Some Boxes

I was asked to make one final post here when RSS feeds were exposed on the new site. Well, the feeds were always there, just not readily visible on the page. If you were using a browser that was feed aware, it would have detected two feeds on the site. However, that’s not really all that friendly. Not having the usual feed icons on the page was one of those “unpacked boxes” that I talked about. Well, I’ve updated the site design a little, and now those pesky feed icons are prominently displayed.

This time, this really should be my last post on this blog.


Read Full Post »

Moving Again

Yes, I know, it’s not been that long since I moved from Windows Live Spaces to here, and there’s not a lot of content here. However, I’m still moving again. This time I’m going to self host so that I have complete control over the site. So, if you’re following my rantings, follow me on over to http://www.digitaltapestry.net.

Read Full Post »

I’ve Moved

OK, after the rant in my last post, I’ve done it. I’m not going to be posting to this blog anymore. I’m moving over to WordPress at https://digitaltapestry.wordpress.com.

Read Full Post »

Spaces Rant

Windows Live Spaces are driving me nuts. I’m going to be looking for a new home for my blog very soon. I’m that fed up.

I get way too much spam in my comments. Do a Google (Bing) search and you’ll find that this has been a very long standing complaint, and there’s really no excuse for this. The spam I’m getting is very obviously spam, and is guaranteed to be caught by event he lamest of spam filters, but Spaces doesn’t employ any spam filters! Oh, but it gets worse. For much of the lifetime of Spaces there was no way to report spam. The tried to address this, but the result is a pain to the user, and there seems to be no results obtained from reporting the spam. There should be a big SPAM button on every comment when you’re in admin mode. Pressing that button should do numerous things:

  1. It should automatically notify the site administrators as to the wrongful behavior of the user, so an investigation can begin and the user can be banned.
  2. It should delete the comment.
  3. Optionally, it should block the user from ever posting to the blog again (outright banning from all blogs should be done only after investigation by administrators). In this case it should also delete all other comments on the blog left by this user.

Instead, we’re left with having to manually locate a form to fill out with information about the spammer that seems to be ignored, and then manually have to delete every spam comment. Manually deleting those comments is a royal pain. You can’t multi-select, it has to be done one message at a time, and each deletion requires confirmation. In less than a week I’ve received more than 60 spam messages, and deleting all of those is going to waste a lot of my valuable time. What’s worse, it’s all spam that I never should have gotten in the first place, if they’d simply run a spam filter!

Yeah, I’m going to be moving somewhere else. Just got to figure out where.

Sorry for the rant, but I’m in a mood right now!

Read Full Post »

This is just too funny not to share. I’m not going to give exact quotes or setup context, but just go straight for the funny bone.

Peter O’Hanlon: Who is this Major Hack you refer to? Is he in the same battalion as General Exception?

Michael Brown: I think Colonel 32 was also in that division.

Peter O’Hanlon: Along with Private Bytes?

Read Full Post »

I’ve released a Beta for Specificity, so it’s no longer just a source repository. Specificity still isn’t ready for full release. There’s additions to the release I plan to make, including project and item templates. However, I expect the APIs to be stable at this point. Creating a release, including an installer, was important to me. See, it’s going to help with one of the largest complaints I’ve received for Onyx: figuring out which source revision of Specificity to use. In the next day or two, I’ll update Onyx to use an installed version of Specificity, and those issues should be gone.

I’ve had to learn a lot of new tech to make this release. I’m using Wix to create the installer, and that’s not the most intuitive thing to work with. Then there’s the project and item templates that I’m working on. These require a custom wizard to control code generation, since Specificity is compatible with numerous different unit testing frameworks. If I find the time, I’ll try and blog about what I’ve discovered here, but if nothing else, hopefully the source will be useful for anyone else trying to figure this stuff out.

Read Full Post »

Disclaimer: This blog post is theoretical notes about an interesting subject, and does not contain a working solution. I will probably provide a solution in the future, but if you’re looking for one here, you’ll be disappointed.

Glenn Block had an interesting post about the “spirit” of the ViewModel design pattern. If you haven’t read it yet, do yourself a favor and go do so. I’m not going to talk about his subject matter here, really, but there was a very interesting reply in this posting from Ward Bell who’s also got a blog that’s well worth reading. In the reply, Ward talks about simplifying XAML/WPF coding by using convention based programming. In particular, this paragraph in his response stuck out to me:

Maybe we shouldn’t be marking up Person.Name at all. Maybe, if we had an easy way to walk the XAML tree, we could automate the wiring of the binding by letting convention tell us that "Person.Name" is accessible from the ViewModel.

See, the thing is, we do have a way to easily walk the XAML tree.

I’ve been playing around with a couple of different convention based solutions to WPF programming, some of which will see the light of day in Onyx in the near future, hopefully. What I’d like to do with this blog post is explore the idea, describing a concept that could be implemented to do exactly what Ward wants. I’m going to discuss implementation details, but I’m not going to provide code. This is all theoretical and is being presented for discussion purposes.

Ward gives a use case where he has a TextBox that’s been provided an x:Name value. He then says “A one-line wizbang in the code-behind constructs the binding for us … and not just for this TextBox but for every control bound to a property of Person.” First, I don’t like the idea of needing a “one-line whizbang in the code-behind.” I’d propose that instead we rely on an attached property/behavior to do this. Onyx already has the perfect attached property for this: View.ViewModel. The change handler for this attached property can walk the tree to provide our convention based bindings. In WPF we can actually use a trick that would enable us to not even have to walk the tree manually. View.ViewModel in the WPF version of Onyx is marked as an inherited property, so we’ll get change notifications for every child element which means WPF has done the work of walking the tree for us. In Silverlight you’ll have a bit more work to do, and it may be a bit tricky to handle some timing issues, but it’s all very doable.

I’d like to discuss using x:Name as the hook to use for our conventions. I don’t like this, for a few reasons. First, the fact that x:Name creates backing fields for you is something that I don’t care for, unless your intention really is to have a backing field. Second, x:Name is meant to be unique, while there will be several scenarios where we don’t want to be restricted in this manner. So, I’d propose using a special attached property for our hook. I’m struggling with a good name for this one, but for now let’s just call it View.Moniker.

So, now we have everything that’s necessary to do data binding by convention instead of configuration. But we can carry this idea much further. Let’s say we have a Button that we’ve given a View.Moniker of “Save”. If we have a SaveIsEnabled property on our ViewModel, that should be bound to the IsEnabled property of the Button. If we have an OnSaveClicked method on the ViewModel, that should be added as an event handler for the Click event of the Button. If we have a SaveCommand property on the ViewModel, that should be added as a command binding on the Button. You can imagine several other conventions to adhere to, so this should be an extensible concept. Instead of hard coding the conventions, include an ApplyConventions (needs a better name) event that can be hooked into to apply the conventions required by the individual application.

So, what are your thoughts on this?

Read Full Post »

Older Posts »