Right! Bringing out the big guns! Jeff blogged about why the LoginView of ASP.NET Whidbey “sucks”. I do not think that he has any experience building custom server controls. In a follow up blog post he made, he said:

Some might argue that it's like the controls you create in a grid or repeater, but this isn't like that at all because you'll never have the same template rendered more than once in a LoginView.

Ok, fair enough in terms of accessing the items. But what about the HeaderTemplate and the FooterTemplate? They only occur once and sometimes, you have access what is in that part of the page. I dunno', that argument that Jeff presented at that point seems kind of invalid but I will call this redundant argument because of what I have to say at the end of this blog post.

However, he did present a good basis of his point when he said the following:

Every ASP.NET developer has been there before. Some sections of a form should be shown to some people or anon users.

Ok, not every developer -- you get your administration back-end pages and your public pages. That is under “normal” circumstances where the user either have the rights to edit the content or they do not. However, I must agree to the point (no matter how much emphasize or exaguaration has been put on a minor point) that there are times that you want to just show some extra UI to the certain people who has certain rights.

But what I really got pissed off at the fact that Jeff never looked any further than “It is by design.” First off, I want to say that is part of the design of the templating system. That is how far it goes; however, the templating system does provide some leverage.

Again, I said in my comment of Jeff's initial blog post is:

 The better solution instead of waiting for the PreRender stage of the life cycle to come by is to migrate the controls into custom templates, port it into an user control or port it into a server control.

Ok. Maybe I was not specific enough. I have written an article before on the basics of the templating system. Have a read though it and you have the following options at your disposal:

1. Set custom templates on the LoginView control via C# / VB.NET code (programmactic).
2. Have a user control encollapsed in the template.
3. Extend the LoginView control to tailor for custom needs. This will require a lot more work and I would recommend #2 over this one.

There is just one part of Jeff's argument that I would love to though into the trash:

Postback events have long since fired. Honestly, how is this useful? Some might argue that it's like the controls you create in a grid or repeater, but this isn't like that at all because you'll never have the same template rendered more than once in a LoginView.

Maybe the events have been fired long before for other controls outside of the LoginView control but have you ever heard of “controls play catch up to the current status of the page life cycle?” For example if I had to add a control to the page whilst the page is in PreRender stage, then my control will then go through (in chronological order):

1. Init
2. Load
3. PreRender

If there there was any kind of post back events, they would fire just after the Init and Load events. (That is, depending on the type of interfaces implemented on those controls). I have already gone through this in an article that I have also written (I pointed to the page that would be of more relevance to the subject).

However Jeff, if this was possible (I gave the proposed solution in that blog post in detail; I am not talking about the hack), then I would totally agree that there is a better approach.