The application is now composed of three screens, main one (choose categories):

Select a post in a category:

And view the posts in a category:

Notice that you can page between the posts, this enables a very quick browsing experiance.

I commited the changes to the Rhino Tools repository (here), so you can see how I did it (not very complex). That data arrives from a sqlite database called ayende.blog using Active Record, of course.

Additional features that I want to add:

• Add search capabilities, so I would be able to search the content / titles. Probably using SQLite full text searches. Allow to view the page results and to page through them.
• Add tagging support, allow to browse the tags and page through tagged posts.

Not a lot of feature, eh?

Except that I have this list of things that I want to fix:

• Give a uniform UI for the buttons in the first two screens, probaly on par with the prev/next links on the last screen.
• Figure out control templates and replace the links on the last screen with a real control (right now it is a TextBlock with an event on MouseDown).
• Figure out how to factor the common header into a seperate header control.
• Add a column with the number of posts in each category.
• Use WPF Commands instead of doing things in the events.
• Figure out a better way to do paging than just moving between all those pages. There are advantages to this approach, so I think that I will keep them.
• Put a meaningful title on the page, so the back button menu will look nice.
• Put a Home button on the titlebar that will get you back to the main screen.
• Figure out if an a really long chain of pages is a memory leak in the order that I should do something about. Yes, it is a memory leak, probably need to use KeepAlive=false, in which case the page will be discarded, and a new instance will be used when stepping back to it. As this is the default behavior, no need to do anything about it.
• Figure out if triggers can replace the checks for next item, prev item. There isn't a way to do this properly, because there is an if pos+1 == count invovled.

"Categories:" is static text, the rest is generated via this code:

Is there a way to do this via XAML and not from the code?

I would like to thank Tomas Restrepo for pointing me in the direct direction, this is indeed possible, like this:

Notice the ItemsSource="{Binding}", which tripped me at first. Also, note that I am binding the tag of the text blog to the ID of the category. I don't really like this, but I couldn't figure out how to bind to the current item itself.

I think that I'll let that one stand on its own...

I have no idea what happened, but I was working on an ASP.Net application (no un-managed code), hit the pause button in the debug menu, to see where the application is spending a lot of time, and I somehow ended up here. Hm... somehow I get the feeling that my team didn't write it...

The comments says it all, I think:

Posts I have made to this blog: 10Mb, this it just the text we are talking about, not images or anything else. This is excluding comments. With comments it is close to 15Mb.

Wow!

Take a look at this. Again, I must say that I really like WPF model. All the hurdles that I had so far were entirely my fault, and no hoods yet.

Next is to support accelerator keys, paging between posts in a category and a way to tag the posts.

I am mainly doing this because I want to be able to do a quick review of all the posts in a specific category, and decide if I want to do something more with them, by the way.

David Hayden has a post (ASP.NET AJAX Web Controls - AJAX Experience Without Learning AJAX) that really bothers me. He talks about the different components that he tested for Ajax support, and conclude with:

Frankly, I would like to know as much about Ajax as I could get away with. The problem is that you can't escape from the complexity. You can wrap it, hide it, stash it in the attic and throw away the key, but it will come back and hunt you.

 Complexity, meet Ajax, you are going to be best friends.

The law of leaky abstractions holds quite well for Ajax. Eventually, you will need to do something slightly beyond what is supported by the controls, or you will get an error that can't be fixed by setting a property somewhere, or you'll need to debug an issue. Those are the cases where the willful ignorance will come to haunt you.

It looks like a lot of the people working on MonoRail has at least some RubyOnRails experiance, this means that there usualy a way for people coming from mostly WebForms background to map the concepts they know to the MonoRail lingo.

Just to set the record straight, MonoRail is runing on ASP.Net platform, no perl involved.

Here is a mostly random attempt to map some of those concepts, note that I am talking about views only here;

• Master Page
• Master Page with multiply content areas
• View State
• Page LifeCycle Events
• User Controls
• Server Controls

Feel free to add more subjects, and I'll try to answer them as well.

Master Pages:

Master Pages are a way to share a common look and feel between pages, without duplicating the HTML. In MonoRail speak, they are called layouts, and they are settable on a controller or action granularity (or directly through code, if that strikes your fancy).

Master Pages with multiply content areas:

But wait, you are using a master page that is filled with more than a single location (for instnace, the main content and a header). In MonoRail, the same functionality is provided using a main content area ( ${ChildOutput}, for instnace ) and the use of normal variables that are filled by the view using a capture for component, like this:

And in the layout:

The output of those will be:

View State:

View state doesn't exists, and good riddance. The web isn't stateful, the framework shouldn't lie to you and say that it is. When you need state, we have a powerful set helper classes that help provide you with the functionality that you desire.

Page LifeCycle Events:

They don't exist either, along with their complexity and the head aches that they bring. MonoRail has the following happening in a request: before filters, action, after filters, view rendering. And you usualy can ignore the filters.

User Controls:

Sometimes called partials, subviews, or macros in MonoRail speak (although each has a specific meaning), they provide the same functionality. A simple example of using one may be:

MonoRial's views can be easily embedded in an assembly, so it is trivial to take those from project to project without having to copy the sources themselves.

Server Controls

Those are called ViewComponents in MonoRail, and they provide a set of UI services for the application. Because in MonoRail the views are not working in a complex object hierarchy, it means that the view components are free to do a lot of interesting stuff that are harder to do in the WebForms model. Take for example the CaptureFor component, which output its content into a variable, which can later on be used by different parts of the views / layout.

No, no perl involved.

Since it is expected that I will learn WCF and use it extensively, I decided to take a look at WPF and see what I can do with it. Considerring that I am thinking about taking some of my posts and turning them into a series of recipes, I thought that it would be a good idea to start by creating Ayende Viewer.

Not, it is not even half way complete, but it it looking good, isn't it?

Couple of notes about it:

• It plays really nice with business objects, which make me really happy. No more DataSet-Driven-Databinding.
• I took a look at the architecture and it looks delicious. Simple for the simple cases, possible for the complex cases. And (at least in initial exploring) I didn't find any welded hoods.
• The tools sucks, but I say this as someone that things that it is better that the tools will be bad and the framework easy to use than the other way around. Microsoft, please, do so again in the future, give your RTM products 6 months - year in the field, before bringing the big UI guns, it will do wonder to the code quality.
• I like the HTMLisque feeling of it...

Of course, me being me (otherwise who would I be?), I run into some interesting issues that I haven't been able to figure out for a while. It all started when I wanted to add a value conveter so I could see dates in a comprehensible form. I found out about IValueConverter, implemented it, and try to use it. No magic words could convince the application to run, it kept complaining that the type (which I just wrote) did not exists.

A long time later, I finally try to remove the reference to the converter from the XAML and compiled, it worked. Adding the references back immediately fixed this issue. As far as I can figure out, XAML is reflecting over the assembly and trying to find the type, since I haven't compiled my assembly since adding the type, it couldn't find it, and the XAML error broke my build.

Second was an issue where it would flat out refuse to acknowlenge that the resource that I added existed, some observations about the state of the moon later, I finally figured out that it is evaluating the XAML (or BAML) in order, and moved the resource defination to the top of the page.

Conclustion, I think that I will like it...