I would guess this is not going to happen any time soon. There are a lot of date pickers for ASP.NET already, including one distributed by Microsoft as part of their Ajax library. They way ASP.NET pages get converted to HTML when viewed by the user makes it hard to use any JavaScript library that is not specifically coded for ASP.NET.
-Mike Chabot On 4/25/07, Brian Miller <[EMAIL PROTECTED]> wrote:
It's a .NET thing. The ASP.NET paradigm is to write your page in a server-side language (usually C#), and the server-side object gets rendered into whatever is viewed on the client side. It would be pretty involved, though, because the plugin is dependent on jQuery (and bgiframe, and the Date methods). The way to do it is probably to create an element (class) for each dependency, to be instantiated in the ASP page, and then do some exception-handling for when the dependencies are missing. I believe that there's a way to have it error at compile-time, so you can see right in Visual Studio if you forgot to include something. My C# is pretty rusty, but it would be worthwhile for someone to do a "jQuery for ASP" project. I'm not sure that I'll have a lot of time to devote to it, but I can kind of see how it would be done. - Brian >> Looks fantastic, Kelvin! I showed it to our lead engineer who has been >> assessing date packages and he said he'd drop his current date package >> in a >> heartbeat for this one IF someone had built a server-side version of it >> (.NET). So, if anyone takes on that challenge let me know. I long for >> the >> day when I don't have to deal with the rat's nest of code that the >> Peter >> Blum date control generates. >> > > Thanks :) I'm curious - why is there a need for a serverside version of > this control? What exactly would it do? Is it just so that users without > JS could get date picking functionality? What context are you using the > date picker in? > > Cheers, > > Kelvin :)
