Server Events vs. DHTML

[Antonio Ooi]

Hi,

I'm an application developer from Malaysia. I wanted to know how ASP.NET
server-side events vs. client-side DHTML for FORM manipulations, may be in
terms of performance and practicality? To my understanding, server events
will only work when user sends request to server. Any FORM object
manipulations will need to go through the Web server, whereas for DHTML, the
FORM objects are manipulated on the fly. The most beutiful thing of DHTML
is, clicking the 'Back' button will not go back to the previous user action
for the form but it dismisses the entire page. Need your advice on that.
Thanks in advance.

Best Regards,
Antonio

[Kevin Spencer]

Sometimes one is more appropriate than the other. There are quite a few
considerations that make the determination. These include the type of
processing that needs to occur (some processing can only bo done on the
server), performance issues (you have brought up some of them), speed of
development, and code maintainablility, to name the most common.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Antonio Ooi" <an*******@yahoo.com> wrote in message
news:Ol**************@TK2MSFTNGP11.phx.gbl...

Hi,

I'm an application developer from Malaysia. I wanted to know how ASP.NET
server-side events vs. client-side DHTML for FORM manipulations, may be in
terms of performance and practicality? To my understanding, server events
will only work when user sends request to server. Any FORM object
manipulations will need to go through the Web server, whereas for DHTML, the FORM objects are manipulated on the fly. The most beutiful thing of DHTML
is, clicking the 'Back' button will not go back to the previous user action for the form but it dismisses the entire page. Need your advice on that.
Thanks in advance.

Best Regards,
Antonio

[Steve C. Orr [MVP, MCSD]]

Your understanding is correct.
If you don't need to post back to the server to handle something, then you
probably shouldn't. Client side code is a great way to keep your code
responsive and efficient.
If all your users are using a recent version of IE then this can work out
great for you, but if you have to support other browsers then it can be a
real pain to make sure your client side code works properly with all
browsers - you'd need to do a lot of testing and tweaking.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net

"Antonio Ooi" <an*******@yahoo.com> wrote in message
news:Ol**************@TK2MSFTNGP11.phx.gbl...

Hi,

I'm an application developer from Malaysia. I wanted to know how ASP.NET
server-side events vs. client-side DHTML for FORM manipulations, may be in
terms of performance and practicality? To my understanding, server events
will only work when user sends request to server. Any FORM object
manipulations will need to go through the Web server, whereas for DHTML, the FORM objects are manipulated on the fly. The most beutiful thing of DHTML
is, clicking the 'Back' button will not go back to the previous user action for the form but it dismisses the entire page. Need your advice on that.
Thanks in advance.

Best Regards,
Antonio

[Kevin Spencer]

Sometimes one is more appropriate than the other. There are quite a few
considerations that make the determination. These include the type of
processing that needs to occur (some processing can only bo done on the
server), performance issues (you have brought up some of them), speed of
development, and code maintainablility, to name the most common.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Antonio Ooi" <an*******@yahoo.com> wrote in message
news:Ol**************@TK2MSFTNGP11.phx.gbl...

Hi,

I'm an application developer from Malaysia. I wanted to know how ASP.NET
server-side events vs. client-side DHTML for FORM manipulations, may be in
terms of performance and practicality? To my understanding, server events
will only work when user sends request to server. Any FORM object
manipulations will need to go through the Web server, whereas for DHTML, the FORM objects are manipulated on the fly. The most beutiful thing of DHTML
is, clicking the 'Back' button will not go back to the previous user action for the form but it dismisses the entire page. Need your advice on that.
Thanks in advance.

Best Regards,
Antonio

[Steve C. Orr [MVP, MCSD]]

Your understanding is correct.
If you don't need to post back to the server to handle something, then you
probably shouldn't. Client side code is a great way to keep your code
responsive and efficient.
If all your users are using a recent version of IE then this can work out
great for you, but if you have to support other browsers then it can be a
real pain to make sure your client side code works properly with all
browsers - you'd need to do a lot of testing and tweaking.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net

"Antonio Ooi" <an*******@yahoo.com> wrote in message
news:Ol**************@TK2MSFTNGP11.phx.gbl...

Hi,

I'm an application developer from Malaysia. I wanted to know how ASP.NET
server-side events vs. client-side DHTML for FORM manipulations, may be in
terms of performance and practicality? To my understanding, server events
will only work when user sends request to server. Any FORM object
manipulations will need to go through the Web server, whereas for DHTML, the FORM objects are manipulated on the fly. The most beutiful thing of DHTML
is, clicking the 'Back' button will not go back to the previous user action for the form but it dismisses the entire page. Need your advice on that.
Thanks in advance.

Best Regards,
Antonio

[Antonio Ooi]

Thanks for the ideas. I think as long as I can do the same for server-side
events of ASP.NET, whereby I can have a "< Back" button to go back to the
previous form and have all my previously entered values filled up, with the
minimum amount of codes, I will consider shifting my projects to ASP.NET. In
the conventional way, I need to issue only one line of code to have all my
previously entered values filled up, that is onclick="history.back()" in the
INPUT tag. Any workaround in ASP.NET in achieving the same result?

Thanks again!

Antonio
MCSD
"Steve C. Orr [MVP, MCSD]" <St***@Orr.net> wrote in message
news:eO***************@TK2MSFTNGP09.phx.gbl...

Your understanding is correct.
If you don't need to post back to the server to handle something, then you
probably shouldn't. Client side code is a great way to keep your code
responsive and efficient.
If all your users are using a recent version of IE then this can work out
great for you, but if you have to support other browsers then it can be a
real pain to make sure your client side code works properly with all
browsers - you'd need to do a lot of testing and tweaking.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net

"Antonio Ooi" <an*******@yahoo.com> wrote in message
news:Ol**************@TK2MSFTNGP11.phx.gbl...

Hi,

I'm an application developer from Malaysia. I wanted to know how ASP.NET
server-side events vs. client-side DHTML for FORM manipulations, may be in terms of performance and practicality? To my understanding, server events will only work when user sends request to server. Any FORM object
manipulations will need to go through the Web server, whereas for DHTML,

the

FORM objects are manipulated on the fly. The most beutiful thing of DHTML is, clicking the 'Back' button will not go back to the previous user

action

for the form but it dismisses the entire page. Need your advice on that.
Thanks in advance.

Best Regards,
Antonio