I’ve had a lot of success with WP-Amazon Reloaded so far. People have been happy with the results of my development efforts thus far. As such, I am happy to announce that I finally received WordPress.org repository access today to host the plugin.

Unfortunately, WP-Amazon Reloaded was no longer available as a name for a plugin on the official WordPress.org plugins repository so I went ahead and renamed the plugin. From now on, WP-Amazon Reloaded is Amazon Reloaded for WordPress. You can view the official repository and download the latest version there.

If you have any feature requests, please don’t hesitate to ask.

Weblog Tools Collection recently announced the WordPress Plugin Competition 2.5, a chance for WordPress plugin developers to use their innovative capabilities to come up with new and useful plugins. There are always good prizes at stake, and I’m determined that I’m going to enter this time. I’d love to have a chance to win my share of some cash or hosting, like last competition’s winners did.

I already have more than a few ideas of what I might be doing, but I’m not completely sure yet. If you’d like to suggest some plugins that you think would be nice to see developed, then I’d be all for considering them. Please let me know in the comments here or by email via my contact form.

A well-conceived and documented architecture is at the heart of most successful software. As such, that’s where we’re going to start with what I’m going to call our Gradient Previewer. This post will concentrate on the goals of our architecture, the inspiration I’m drawing from, and the basic tact we’ll be taking. At the end, I’ll include a packaged Visual Studio 2008 Solution that you can download and look at what we’re starting with.

Architecture Goals

For this application, I have two main architectural goals. The first involves the separation of application logic from the user interface. Fortunately, WPF and the .NET 3.5 framework make this easy to do once you know a few tricks. This separation helps keep each separate piece of the application focused on a single task or set of tasks, making maintenance easier and the application more apt to be understood.

The second goal is to make the application skinnable. Quite frankly, I am not a very practiced visual designer, and I know that the first UI for this application will definitely not be the greatest thing since sliced bread. Taking an architectural approach that allows for the application to be skinned provides for the opportunity for the UI to be reworked down the line into something more beautiful. That’s the plan at least.

Architectural Inspiration

I’m definitely not going into this project blind. I’ve taken inspiration from many places. First and foremost, I’d like to thank Josh Smith for allowing the download of the source for his Podder application. You can find Podder here.

Another resource that I’ve relied upon as I’ve learned about WPF is the idea of the Model-View-ViewModel pattern that I first learned about on Pete W’s Idea Book. While I’ve taken it in a somewhat different direction (moving control out of the viewmodel and into a controller) it was a great resource to get me thinking.

Architectural Design

Getting down to the nitty gritty, let’s go ahead and examine the solution explorer window at this point. It will help illustrate how I’ve laid out the application.

The first thing you’ll notice is that the solution is split into two projects. The first project is GradientPreviewer, where our application lives and where all the stuff that makes the application work will happen. The second project is GradientPreviewerLib, which holds the models and viewmodels for this project. These are the back end data objects that will eventually be bound to our UI in various forms.

Looking through the first project, you’ll notice a number of different folders. The first is the Controllers folder. In the Controllers folder (and namespace), we’ll be placing a controller for each major UI element in our application. These controllers will be responsible for managing the actions that occur in the UI element that they encapsulate. Next, you’ll see the DefaultSkin folder and it’s subfolders. Here we’ll be creating the UI for use in the default skin. The default skin contains Converters.cs and Resources.xaml files. The former will hold any converter classes necessary for the default UI while the latter will define the view parts and any other resources to use for the default skin.

Speaking of the UI, we come to the UI folder and namespace. Each part of the user interface that is absolutely needed for the application to function will reside here. For now, we just have the MainWindow.xaml file representing the main window for the Gradient Previewer application. The content of each UI part will be dynamically filled using a dynamic resource that is returned from the current skin’s Resources.xaml file.

Finally, we come to the App.xaml and Commands.cs files that reside in the default namespace. App.xaml and it’s codebehind class App.xaml.cs provide for startup of the application and are pretty much necessary in every WPF application. Commands.cs will encapsulate a number of RoutedCommands that will be used to trigger actions within the application. Every action that can be taken will first be defined in this class as a public static RoutedCommand.

Download

If you’ve enjoyed this tutorial and want to see where we’re currently at as far as code goes, download the following zip file: Gradient Previewer Solution Part 1

I recently started development of a commercial application. After much deliberation, I ended up choosing the new Windows Presentation Foundation as the framework for this application. While I have been generally pleased with the several books I’ve examined on the subject, I’ve found the online resources to be somewhat lacking in substance (although there are exceptions, notably here, here, and here). The demo applications I’ve seen have shown off some pretty important concepts, but really don’t have practical uses (with the exception of the awesome Podder podcast tool). That leads me to this series of tutorials.

What I would like to do is create a fully functioning application, pulling together the concepts and techniques I’ve learned for others, that demonstrates how to do WPF development in a way that is easy, efficient, and fun. The application also has to be useful in some way to some group of people.

After sitting down and thinking about useful domains, I decided to build a tool that would help WPF developers in general. As such, I’ll be creating a gradient brush preview tool. This tool will allow you to visualize a gradient, assign new stop in the gradient collection, generate both radial and linear gradients, and preview the gradient as a background or foreground brush on a number of common WPF controls (panels, buttons, etc.). Finally, the gradient brush will be exportable to XAML code which can be copy and pasted or saved to file.

As with any large endeavor, I’ve tried to sketch out a basic plan outlining the steps in this development process. The following list is my attempt to delineate that plan:

1. Application Architecture
2. Object Model Development
3. Basic UI Structure
4. Data Binding
5. Advanced UI Concepts
6. Pulling It Together

I’m sure this list will be modified over time, but for now I think that it is a good guide to what I’m thinking about doing here. I hope you’ll join me on my tour of WPF and learn with me as I try to find the best way to do things on this exciting new development platform.

In the latest version of the WordPress blogging system, the administrative UI was completely revamped. One of the biggest differences comes with the manage posts screen. The Id column was removed from the posts table, making it somewhat ponderous to attempt to find the Id of a specific post. This is bad news for designers, as the Id of a post sometimes determines what kind of styling to apply to the content.

The WordPress community’s solution to this problem is the following:

Q. How can I find the Post ID or Page ID?

A. If your browser shows the URL in the status bar, when you mouse over a link, you can see the ID in the as part of the URL displayed in the browser status bar. In FireFox you can show the status bar by checking the Status bar choice under View. A more complicated method to finding the ID is to use something like phpMyAdmin to look at the database table wp_posts–look down the column of post_title to find your Post or Page Title. The ID field on that row will be your Post (or Page) ID.

(from WordPress 2.5 FAQ)

Someone on the WordPress ideas page suggested that the Id column be restored, and that’s exactly what this plugin does. [EDIT]You can now download the plugin from it’s official plugin page on WordPress.org. Please let me know if you have any problems.