Jeers for LoginView control

Awhile back I was crying about how LoginView is designed wrong. Apparently Microsoft doesn't agree with me. At issue is the fact that controls inside of a LoginView are created late in the page lifecycle so they can't be accessed directly from PageLoad or postback events. The stated purpose of the control, according to the documentation, says: "Displays the appropriate content template for a given user, based on the user's authentication status and role membership."

I don't know if that sentence represents the broad requirements of the control, but I suppose it depends on how you define "content." The first thing that comes to mind when wanting to use this control is putting a login box in the anon template and some kind of navigation for logged in users in the authenticated template. Or in a feedback mechanism under an article, put the text box for logged in folks and a link to register for the anon folks. As it stands now, the static content is fine, but anything else requires more work.

This is eventually what the Web platform team came up with:


We have identified improving the ease of use of "FindControl" as an issue for a future version of the product. In Whidbey we did introduce a control attribute that allows you to designate controls to be "single instance" templates -- in effect setting this promotes the first level of child controls to the page and they are easier to access (e.g. the behavior you see WebPartZones). However there are trade-offs in this design that make it impractical to do for LoginView, one of the trade-offs is the change in naming container behavior that can cause problems with other login controls when they are templated. We initially did have a LoginView as a single instance template but reverted that change based on feedback from early adopters and internal users of the control.

So I guess it won't work the way I think it should, and that's a bummer. The next best thing is to use a MultiView control, or a derived version thereof, to duplicate this functionality.

No Comments