It is very common to have multiple sibling instances of a template, such as the column DataTemplates in a DataGrid. If these shared a namescope, there would be name collisions. So templates in XAML and Silverlight are obliged to have private namescopes.

The change of namescope makes it impossible, inside a DataTemplate, to use ElementName syntax to bind a Selector.ItemsSource to a DataSource defined at page level. This is a significant issue for LOB application developers. Foreign keys into lookup tables are very commonly implemented using a ComboBox with its list provided by another DataSource. Fortunately, once the nature of the problem is clearly understood it is not difficult to solve.

There are two possible approaches. Both will work. One scales better.

• Declare the lookup DataSource in the template and use ElementName binding.
• Declare the lookup DataSource objects as page resources and use StaticResource binding.

Declaring the lookup data source inside the template would bring it into the right name scope for ElementName binding to work. But putting the data source in the template would be a performance disaster. It would produce a private instance of the DataSource for every instance of the template.

Like name scope, resource scope is container-based. It is possible to declare a resource section in a template, but this is such an obviously bad idea – a private instance of each resource would be created for each instance of the template – that nobody ever does it. The possibility of resource name collisions is therefore unimportant, and we can use the resource namespace to work around the necessarily disjunct name scope of a template.

Source: http://www.calsci.com/motorcycleinfo/FilterXRef.html

This seems to be quite a handy site, with a very high information density.

Basic characteristics

20 x 1.5mm threads, 14 psi by-pass valve, anti-drain back valve, 2.3” O.D. gasket, 2.5” to 3.5” long

If you have the room, I recommend the longer filters. Fit depends on model.

EQUIVALENCE CODE Z436

Made-for-motorcycle filters

None are recommended.

• AC Delco PF2135
• AMSOil SMF103
• Carquest 85358
• AC Delco PF2135
• FRAM PH6017A
• Honda 15410-MCJ-000
• K&N KN-204, about $13. Metric nut on end for easy removal.
• NAPA Gold 1358
• Purolator ML16817. Imported, not made by Purolator.
• STP SMO 17
• WIX 51358

Recommended filters

All have superior filtering.

Automobile Filters

Our society, while being on the whole much nicer that most of what went before, persistently behaves in ways that are mildly inimical to individuals. The power of a democracy is delegated to it by individuals. When individuals en masse disregard a law, clearly the people as a whole have withdrawn that delegated authority and the administration has absolutely no right to impose or enforce said law.

Speeding fines are very widely regarded as having nothing to do with safety and everything to do with revenue collection.

Sour grapes because I copped a fine? Sure, that’s why I’m annoyed enough to write. But that doesn’t change the facts:

1. It’s about money.
2. It’s not about safety.
3. Punitive speed limit strategies do not improve safety.
4. I’ve said this when I wasn’t ticked off about getting caught.

It’s about money

It’s dead easy to show beyond a shadow of a doubt that it’s about money: our government includes future camera fine revenues in the planning budget. That’s a commitment to fining enough people to raise a (very large) amount of revenue.

So much for no quotas. They’re not quotas, they’re targets or some such, just as surely as you can get off a murder charge by calling it post-natal abortion.

Punitive speed limit strategies do not improve safety

That’s a long title, but it’s important to make the distinction between an enforcement strategy, the ostensible objective of that strategy, and the actual result, which in this case certainly isn’t enforcement – people are still speeding.

In the nineties there was a three day police strike in NSW. It was over a long weekend, and in a departure from tradition this one was advertised in advance on the news. If speed enforcement improved safety, you’d expect a huge spike in accidents and injuries. But no, both stats dropped.

Very likely this was because speed doesn’t matter so much when you look where you’re going instead of staring at the dash, and you just match your speed to the traffic.

This is strong evidence that making people worry about strict adherence to an arbitrary speed limit interferes with their observation of the world past the dashboard.

At the time, NRMA tried to make the point I just made. Predictably, the NSW government flat refused to discuss the matter, much less officially investigate the possibility that their speed limit enforcement strategy is the real safety threat. Probably they were concerned about the threat to their revenue stream.

It’s not about safety

For the sake of argument, assume that the official position is true: speed limits actually make the world a safer place, and that the perils of ignoring them are so dire as to be intolerable.

If this were the case, genuine enforcement would be far, far more important than punishment or revenue collection. It would be vital to make it flat-out impossible to exceed the gazetted speed limit.

Can this be done with current technology at a reasonable cost? Yes, absolutely. I can think of a cheap way that would work in built-up areas, and a more expensive way that would work nationally.

The former entails speed signs that emit a directional beacon indicating the local speed limit to the car’s computer. The other involves a GPS tunit and a lot of data about roads and speed zones.

I know any public servant worth his salt can make a radio cost five hundred dollars, but it’s still not much in the grand scheme of things.

Some will claim it is draconian to impose the cost of fitting the above equipment. That’s bollocks. It’s no more financially onerous, and quite a bit more ethical the current practice of imposing heavy fines with only nominal interest in safety. And unlike fines, it would be a one-time cost.

What I really think is that the governments should *** off and mind its own business, and in particular stop wasting expensive police manpower on bullshit.

Safety might even improve. If you can’t speed, you can’t cop a speeding ticket, so you can stop staring at the dash and look where you’re going.

This is what I do now, which is a large part of why I’m pissed about the fine. I wasn’t going terribly fast, and I was completely off the throttle (down a hill).

You can’t really put that sort of speed limiter on a motorcycle, but I match my speed to the traffic. It’s all part of not smacking into the vehicle in front.

There is a religious argument over whether it is important for view parameters to refrain from exposing implementation details such as the underpinning data store.

Why might that be bad?

The public interface of an object is effectively a contract. The consumer of such an interface has an opportunity to depend on the capabilities exposed to it, and once that happens the provider of those capabilities is obliged to guarantee their availability forever.

In short, don’t make any promises you aren’t prepared to keep forever.

The good news

Manipulating the profile of the currently logged in user is easy. WebContext.Current.User providers a derivative of ProfileBase exposing profile properties as strongly typed object properties. You can set the properties and invoke WebContext.Current.User.Save() to commit the change to whatever profile provider is configured.

It’s dead easy to find out whether the current user is in a role: the method ProfileBase.IsInRole(string rolename) returns true or false. It also sports a Roles collection for more elaborate comparisons, as well as an IsAuthenticated Boolean property the meaning of which should be obvious.

The bad news

Where the support for authorisation is much less complete is in creating the user, assigning roles, and setting the profile properties.

Or maybe it’s not so bad

The rationale for this is it’s not hard to code this up yourself in a web service. Knock up a page that collects all the info, and pass it all to a web method. This runs at the server, and you can write methods like these:

BackingStore is a profile property in the application from which this was clipped. It’s a sort of bureau service and we have a database per corporate customer so the data can be backed up and held in escrow per customer. The important thing to know about BackingStore is that is must be set before the login can be used, because application start-up uses this information.

wasEntities is the Entities object for an EF model of the Windows Authentication Services (WAS) database ASPNETDB. CreateUserPrefs creates an entry in a table of user preferences. This information ought to live in profile properties but older systems sharing the database depend on this table. It’s a legacy thing predating our use of WAS and profiles; once upon a time this was a desktop application.

The stored procedure behind this web method looks like this:

It was brought into wasEntities as a function import.

This is a good example of a technique I cooked up to get around the fact that while it’s not hard to set the connection string at session start-up, it’s difficult to change dynamically. This stored procedure is defined in the WAS database, but operates on the database named in its first parameter.