Let's back up here a bit... There is no such thing as "event driven" programming.
All event driven programming, everywhere, is fake. It's an abstraction created so that humans can model the world better, and to solve certain problems. Modern programming depends on events, and cannot survive without it. Imagine if your OS or CPU constantly polled everything that it was responsible for. Yikes. That's why interrupts were invented. Your CPU would sit back and do nothing. Then, things would send an interrupt, and your CPU would do the work the interrupt asked for. This model has been extended to the programming world. The world can be modelled nicely this way. And, it just so happens that GUIs work especially well with events (e.g. the button was "clicked"). Can you wire GUIs in other ways? Of course you can. But I've seen some _really_ atrocious alternatives - like having a main in C with 5000 case/switch statements for every possible menu item. Yum. If we consider a web page to be another GUI (which it is), then it can make sense to have an event model for that page. It turns out that ASP.NET is not the first to do this. Netscape, in fact, started it with JavaScript. The difference being, JavaScript deals with the event on the client machine. ASP.NET deals with the event on the server. I find this remarkably handy. I can create a page with a search interface. I have two search buttons. One uses the criteria on the page. Another searches everything. I then click on the search w/ criteria button (the button raises an event that calls a method). The page does a search with criteria (the method is run). Now, I click on the search all button. The page does a search all. Nice and tidy. No if statements that try to figure out which button I pressed. ----- Original Message ----- From: Dave Watts <[EMAIL PROTECTED]> Date: Friday, July 18, 2003 12:37 pm Subject: RE: RE: MSDN on CF -> ASP.net > > Anyhow, in terms of ASP.NET and presentation, the event model > > exists to make web development closer to traditional > > client/server development. The fact that VS.NET works well > > with it is a nicety. The event model came first; it does not > > exist for an IDE's sake. > > In event-driven GUI environments, it makes sense to write programs > thatlisten for events. In environments that don't work that way, > it seems to me > to be a bit odd to wrap the illusion of events around the > environment, and > not too sensible in the absence of an IDE to take advantage of it. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > voice: (202) 797-5496 > fax: (202) 797-5444 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
