One of the things I hate about the joy of postbacks is losing my scroll position. On a page that's a bit longer than the window, if I have an auto-postback combobox (for example), the user selects an item, the page posts back, and poof! they're back at the top of the page.
On a corporate intranet the post back is nice and fast, and many times the user has no clue that it happened.... Except for the fact that the page just "jumped" back to the top.
Because of this I (as many people) write my controls to re-position, or I have page logic to re-position after a postback. There are articles on CodeProject with controls for keeping the scroll position, one on DotNetJunkies that isn't quite so pre-packaged, but still good, and several tutorials. The problem then is that the behavior is coded in everywhere, or the control must be included on each page, or the page must be derived from something other than the Page class, or something else.. I wanted a fire and forget solution.
So here's what I created late last night to un-vex myself -- an HTTPModule that adds scroll position retention across postbacks to all pages. It's implemented as a filter that adds javascript to the pages after they are output. I've tested it only on IE 6, as that's the browser my client site's intranet uses.
The nice thing about this (to me) is that three lines in your web.config instantly gives you scroll position retention across postbacks on every page in your application. No muss, and not a whole lot of fuss.
To use it, add the module in to your web.config (see the readme.txt included for instructions on doing this), and then configure it to either add the behavior to all pages, or be selective (again, see the readme.txt). The zip includes the source, and a pre-build binary that's strongly named in case you want to just drop it in.
If you find any bugs or problems with it, fix 'em yourself! No, really you can just leave me a comment here and I may look at it. The module works great for me (the infamous "it works on my machine!" that translates to "it only works on my machine!"), and hopefully will for you too. If you like the code, I wrote it. If you don't like the code, then some other idiot wrote it.
Download it here (13K zip)
Cross-posted from Philip Rieck's full blog. Full of neat stuff, don't miss it!
Aaron Skonnard asked “Is UDDI Dead?” a few days ago, Wondering if WS-Addressing will reduce the need for it. Dave Bettin thinks that it can be sucessful, at least in the enterprise. Michael Erls thinks so too.
My take - UDDI hasn't lived at all yet. I'm not so sure it will. I agree with the opinions that if it does, it will be in the enterprise only, but I don't think it will live there either.
Why not? Well, at several large enterprises, I've seen solutions already in place -- web services at well known points that serve up the endpoints for other web services. These are tied into a web app that lets people search for functionality based on keywords and categories that make sense in the business they have.
This solution allows developers to find the services they want, if they exist. It allows them to list and describe the services they create. It allows them to programmatically (via the webservice) find a service that they already know about. All using technologies and methods they already understand -- and indeed use on a daily basis.
Now, UDDI has a lot of cool stuff -- security, subsciption, good searching capability, blah, blah, blah... And UDDI v3 has fixed some issues (like multiple registry support, publisher keys, etc) but for most its simply overkill. They need 10% of the features -- why learn a whole new set of tools when a few hours gives them the framework that they need?
Since I've seen this succeed -- and haven't yet seen UDDI deployed in an enterprise -- I'm wondering if UDDI has ever lived. And from my experience, its future is bleak as well.
cross-posted from Philip Rieck's full blog