Date Filtering and Back to the weather API

I've been working on the LMC all weekend with the intention of finishing it off so I can start on another project next week while the stakeholder is away!

Date Filtering

Whist I was building out the Content Manager application, it dawned on me that I couldn't use the basic date range filtering that I had been using. The reason for this is that the content date ranges aren't actually date ranges because they do not have a year element. For example, one range might be 02/03 to 02/06 whereas anther may be 10/10 to 10/02 (i.e. go over a year boundary). The only thing I could assume is that a period would always be less than a year long.

So, once I had replaced the display and editor templates in the Content Manager to work with dd/mm entries. I had to revisit the LMC application and write some custom filtering logic to replace the basic date between logic.

Weather API

I'd been looking at weather widgets from various sources, and whilst they ware all very nice, none of them really ticked all the boxes for what I wanted. I had two main criteria. Firstly they need to be able to take a post code district as a parameter. Secondly, the size and styling of the widget had to fit in with the look and feel of the Lawn Maintenance Calendar style. The closest I got to finding a widget that worked was the Met Office one. It looked good on the site, but there was no way of dynamically sending through a post code district.

Initially, I'd played with World Weather Online's free weather API, which is a nice little rest service. But I stopped playing with it when I discovered the widgets because I didn't want to re-invent the wheel, so to speak. But I went back to the API in the end because it was the only solution that could match my acceptance criteria. It accepts a post code district as an input and because it just returns the data and image links as XML, I'm free to present it in any way I wish. This is great because I could use ASP.NET MVC display templates to lay out the forecast just like the widgets that I had been using (very MVC). I could then use the same styling that is used throughout the application to style the 'widget' so it looked like it was part of the rest of the app. I have to say, I'm very happy with the result.

The next thing I need to do was ask the user for the postcode district (the first part of the postcode). Initially, I was going to ask the user to register for an account and specify the postcode at the registration stage, but after having a good think about this, I decided to just use a cookie instead. I'll probably be adding user accounts at a later stage when I introduce personal notes to the calendar. For the time being, using cookies to capture and keep the postcode district works well.

So, I've now completed the development for the first phase of the Lawn Maintenance Calendar. I now need to get it tested by the content manager before putting it live.