> Well, sure, but the illusion seems less illusory on a desktop than
> in a web
> application. Thus, I submit that it makes for a more useful model for
> desktop applications than for HTTP applications, where the request-
> responsemodel sticks out like a sore thumb.
Well, see, it's not the request-response model that's the problem. It's the fact that
browsers _must_ render a new web page when they start a request-response cycle.
That's the problem. Oh sure, there are ways around this, but they're all a pain.
We've seen the HTTP request-response model used in a different context: Web Services.
You can have one CF template with as many web service calls as needed, and hey,
they're each a request-response cycle. Works great, less filling.
>
> I'm not sure that this abstraction allows humans to model the
> world better,
> though; what is the equivalent of a GUI application in the natural
> world?
None, really. However, events happen all the time in the real world. Your car
explodes. Frogs fall from the sky.
> > 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.
>
> Yes, a web page, by itself, can be thought of as a GUI. But
> there's a
> critical difference between the web page (the stream of HTML that
> the user
> receives) and the program that generated that page. It's not all
> of a piece,
> and treating it as if it were may add unnecessary complexity if
> you already
> know how web programming works.
Well, this is the same case in traditional desktop GUIs as well! There's absolutely
no correlation between, say, the code you wrote for a pretty Swing window and the
pixels that appear on the screen, other than the code that declares it. The closest
I've seen to what you describe is MFC, where you actually had to dedicate memory to a
window, and actually have a command to draw the border, and another to fill the window
with a blank background, and another to add the title... etc...
>
> > 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.
>
> I frankly don't see this as any simpler than just using the if
> statement. I
> think that if I were more of a desktop programmer, I'd be all over
> ASP.NET,though.
I'm not a huge "if" fan when I'm using an OO language. Anytime I write something like:
if (condition) {
do this
}else
{
do that
}
I consider it a candidate for refactoring.
>
> 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
