I’ve received this question from several people. Suppose you provide an input field for the user to type in his/her zip code. You collect it on post back, set the LocationID property but the change is not reflected. What’s wrong? How do you change the location dynamically?
In fact, what happens now is by design. Let me explain. In the course of this project I pursued two goals:
1. Make it easy to customize
A lot of custom server controls I see around are too cumbersome to deal with. Trying to please everybody a control author may want to bake in every imaginable layout, color, font, you-name-it property. The DataGrid control is a good example of that.
I’m a big believer in simplicity. That’s why I decided to stick with a templated approach. I give the control a number of weather-related properties and leave it up to the author to build a layout of his/her liking. Want Comic Sans MS font in big red letters? Go ahead and add a CSS rule for that. Want tables? Go right ahead.
2. Make it easy to deploy
All you have to do is drop the control in a page, set a couple of properties and you’re good to go. In contrast, many controls requrie server-side code to get them running. This is where differences begin.
Take the Repeater control, for example. It doesn’t know its data source in advance. You set it via the control’s DataSource property and then call DataBind. Therefore it makes perfect sense to defer data binding here.
In contrast, my widget builds its data source from the weather.com XML feed. If you peek inside Weather.cs you will see the following code in the CreateChildControls method:
protected override void CreateChildControls()
{
...
template.InstantiateIn (this.data);
data.DataBind ();
Controls.Add (this.data);
...
}
The control builds itself out very early in the game. By the time the page enters its life cycle it’s too late to modify properties, so no changes take effect. In this sense, the widget offers a “static” view of weather conditions, i.e. it stays tied to one location.
The benefit of doing this is that you don’t have to databind it manually, nor do you need to write any code-behind. Since none of us likes to read documentation, this would’ve been an often cause of oversight—somebody would forget to place a single line of code with xxxx.DataBind() in it.
So what do we do? I can expose a DataBind method (like Repeater does) to allow you to modify its properties on the fly and reflect the changes. For those who are content with a single, “static”, location, everything will work the same way.
I have a couple a concern with this, and I need you, guys, to tell me what you think. The culprit is caching.
The Weather.com SDK recommends to cache its feed for half an hour. They recommend it for a good reason because reading and parsing it is not an instantaneous thing. With caching you fake an immediate response. The weather control caches the feed by its location ID. Naturally, if you change the location ID on the fly, the widget will cache each of them. If you have a high-traffic site this may eat up too much memory. Chances are slim that people will use the same bunch of zip codes to look up their weather, so caching won’t be effective.
On the other hand, dumping caching altogether for fear of memory bloat is not reasonable because performance will degdare. Like I said, weather.com servers may be slow at times.
One way to deal with it is to limit the number of feeds the widget may cache at any given time. This limit can be imposed via a property. By the same token, you will be able to turn caching off completely. By default, we can have some reasonable default to the maximum number of feeds.
Since you, guys, requested this feature, I want to get a feel for the scenarios you had in mind (yep, a “spec”, in a way). What do you think about setting limits on caching? Any other ideas?
