Archives
-
Yield and generics rock!
public sealed class FilteredEnumerable<T> : IEnumerable<T>, IEnumerable {
private IEnumerable<T> _enumerable;
private Predicate<T> _filter;
public FilteredEnumerable(IEnumerable<T> enumerable, Predicate<T> filter) : base() {
_enumerable = enumerable;
_filter = filter;
}
IEnumerator<T> IEnumerable<T>.GetEnumerator() {
foreach (T item in _enumerable) {
if (_filter == null || _filter(item)) {
yield return item;
}
}
}
IEnumerator IEnumerable.GetEnumerator() {
return (IEnumerator)(((IEnumerable<T>)this).GetEnumerator());
}
} -
Please, please, please, learn about injection attacks!
-
The ASP.NET 2.0 page lifecycle in details
In his new and already excellent blog, Léo gives us a great diagram that details the ASP.NET 2.0 page lifecycle.Needless to say, this is a poster you can now find in nearly all offices here in the ASP.NET team at Microsoft. Thanks for the great work, Léo!Read it, print it, use it every day!UPDATE: updated the links to the new locations for these resources. The poster would probably need some updating in particular where callbacks are concerned but it's still very useful. -
What level of control do you need over the rendered HTML?
I'm answering a post from Dimitri Glazkov here. Dimitri tracked this back to my post about UI reusability. It's probably a good idea to read his post before you go on reading this if you want to understand what this is about.In an architect's ideal dreamworld, I'd say you're absolutely right, Dimitri. In the real world, though, I'd mitigate this.
After all, that's what server controls are all about: abstracting the HTML rendering and substituting higher-level abstractions for it. The controls are not ethereal entities, and they need to have some level of control over their rendering to actually work. If you want to have complete control over the rendered HTML, the only thing you can do is output it yourself, and you're back to classic ASP (or PHP). So we should probably be somewhere between complete control and pages made of only server controls.I'm sure you're aware of this, but I'll say it anyways for your readers and mine who may not be as advanced as you are in ASP.NET.There are a few things you can do to control the rendering of ASP.NET controls:
- Use CSS (works with any server-side web technology)
- Use styles (and in particular their CssClass property to link them to CSS) (v1)
- Use templates, which give you total control over the HTML that's rendered by some parts of the controls (usually the ones that are the most visual and are not vital for the control to actually work). Templates rule! (v1)
- Know the control set: there is a fine granularity over the control you can have over the rendering just by choosing the right control. For example, DataGrid, DataList and Repeater are similar list controls that give you more and more control over the final rendering. (v1)
- Develop your own controls, from scratch or by inheriting from an existing one. This way, you can override part or all of the rendering code. (v1)
- Use themes and skins to isolate the general presentation of the site. Themes are more or less equivalent to server-side CSS: they act at the same level of abstraction as controls, and enable to set any property (hint: even TEMPLATES) of any control, site-wide or based on a skin ID. Themes are very easy to write as they have the same syntax as a page. (v2)About adapters, you're right in mentioning that there is a yet unfulfilled potential there. But it may be not in their implementation but in their very use. They may be used for something else than just device adapting. I'll try to blog on that if I have time to experiment with the concept a little more.Your point about the three roles in the designer is a good one and there may be things more or less along these lines in Orcas. But if you look at it as it is currently, we're already kind of there... You have the visual design view, for designers, you have the HTML view, for what you call the prototype, and you have codebehind for the actual plumbing of the page. Yes, the first two actually act on the same thing, but at a different abstraction level.
I do not understand your third role, though: why would theme development be the role of an advanced developer? I would have given this role to the graphics designer. Well, at least, the designer can determine the general look of the page and a developer can transform that into a theme. -
Don't redirect after setting a Session variable (or do it right)
A problem I see over and over again on the ASP.NET forums is the following:In a login page, if the user and password have been validated, the page developer wants to redirect to the default page. To do this, he writes the following code:Session["Login"] = true;Response.Redirect("~/default.aspx");Well, this doesn't work. Can you see why? Yes, it's because of the way Redirect and session variables work.When you create a new session (that is, the first time you write to a Session variable), ASP.NET sets a volatile cookie on the client that contains the session token. On all subsequent requests, and as long as the server session and the client cookie have not expired, ASP.NET can look at this cookie and find the right session.Now, what Redirect does is to send a special header to the client so that it asks the server for a different page than the one it was waiting for. Server-side, after sending this header, Redirect ends the response. This is a very violent thing to do. Response.End actually stops the execution of the page wherever it is using a ThreadAbortException.What happens really here is that the session token gets lost in the battle.There are a few things you can do to solve this problem.First, in the case of the forms authentication, we already provide a special redirect method: FormsAuthentication.RedirectFromLoginPage. This method is great because, well, it works, and also because it will return the user to the page he was asking for in the first place, and not always default. This means that the user can bookmark protected pages on the site, among other things.Another thing you can do is use the overloaded version of Redirect:Response.Redirect("~/default.aspx", false);This does not abort the thread and thus conserve the session token. Actually, this overload is used internally by RedirectFromLoginPage. As a matter of facts, I would advise to always use this overloaded version over the other just to avoid the nasty effects of the exception. The non-overloaded version is actually here to stay syntactically compatible with classic ASP.UPDATE: session loss problems can also result from a misconfigured application pool. For example, if the application pool your site is running is configured as a web farm or a web garden (by setting the maximum number of worker processes to more than one), and if you're not using the session service or SQL sessions, incoming requests will unpredictably go to one of the worker processes, and if it's not the one the session was created on, it's lost.The solutions to this problem is either not to use a web garden if you don't need the performance boost, or use one of the out of process session providers.More on web gardens: http://technet2.microsoft.com/WindowsServer/en/library/f38ee1ff-bdd5-4a5d-bef6-b037c77b44101033.mspx?mfr=trueHow to configure IIS worker process isolation mode: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/26d8cee3-ec31-4148-afab-b6e089a0300b.mspx?mfr=trueThanks to Frédéric Gareau for pointing that out.UPDATE 2: Another thing that can cause similar problems is if your server has a name that contains underscores. Underscores are not allowed in host names by RFC 952 and may interfere with the ability to set cookies and thus to persist sessions.UPDATE 3: It appears like some bug fixes to Session have permanently fixed this problem. At least the one caused by the thread aborted redirect. Still, it is good practice to not abort the thread (and thus use the overload with the false parameter).