I'm with Tim in that I don't think every form should trigger a postback to the server. There are many occasions where that's just a waste of time and bandwidth. In many respect I tend to think that ASP.NET makes more sense for intranets and enterprise applications that run on a webserver. That's where you are more likely to have a separation between designer and developer. Though in cases where there is a change in the person updating pages it not the original developer it is nice to have the code where it is less likely to be messed up.
I've only had one production site that ran on ASP.NET and that only used the ASP.NET for Calendar, Registration and Mail functions I never could get into that whole "project" thing required in Visual Studio. As a result I rarely use code behind. The changes in Whidbey make it a much better tool for a web developer than the current version (or the previous one). Add to that the new personalization and login libraries and I will probably start using it more once ASP.NET 2.0 framework is deployable on commercial sites. Right now the license terms prevent it from being used in a production environment. Though I've had no stability or other issues with it. (Course I run betas in a Virtual PC whenever possible.) I've played with the Whidbey beta and have downloaded but not really used the Visual Web Developer 2005 Beta (public beta). Cheryl D. Wise Certified Professional Web Developer Microsoft FrontPage MVP http://wiserways.com -----Original Message----- From: Furry, Tim Tim adds: Cheryl's point about separation of tasks is one pushed by Microsoft, but I think it's probably a rare instance where developers aren't putting in the design elements themselves (i.e. probably only a really big company might have separation of tasks). Scott, your analogy is very close - with the usually overlooked but important aspect that the "linked" code is *strictly* code (the code-behind page, no HTML), and thus can be (and is) compiled, with all the usual relevant goodies available (strong typing, compile-time checking, debugging, speed, etc.). That being said, I haven't really used .NET much yet other than simple playing around, and being a Notepad webbie guy from way back, still find it very difficult to think of web pages and sites in an object-oriented way. OOP makes perfect sense for a Windows app - it runs and runs and keeps running until the job is done. Web apps are different - post, push, done; post, push, done - there's no real application continuity (and that's the way it's supposed to be). I think in general .NET for webs ties the browser to the server much more tightly (i.e. onClicks hit the server) and I'm not convinced that's a good thing. I've worked on one web app here at my new job where a former programmer wanted to move the focus from a select box to a text box after a selection was made - and ended up putting in a crazy freebie .NET page of code that hits the server and reloads the page, rather than using just a line or two of JavaScript on the client side to move the focus. ____ • The WDVL Discussion List from WDVL.COM • ____ To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] or use the web interface http://e-newsletters.internet.com/discussionlists.html/ Send Your Posts To: [EMAIL PROTECTED] To change subscription settings, add a password or view the web interface: http://intm-dl.sparklist.com/read/?forum=wdvltalk ________________ http://www.wdvl.com _______________________ You are currently subscribed to wdvltalk as: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
