migration from asp: better client or server-side code?

[Ben]

Hi,

I made an application in classic asp (reservation of books and video stuffs
for students) and want to migrate to asp.net.
The user has to chose a date, then pushung on a submit button. The whole day
is then displayed in cels of a table. The user has then to click in a cel
representing a hour of the day and an object (book ..), and finally click on
the submit button to insert that reservation in the database.

My problem is: there is a lot of javascript client-side code. All onclick
events are executed on client-side.
Have i to change this into server-side code or i can still use that
client-side code?

Is it true that the filosophy of asp.net is: maximum server-side script and
minimum client-side? If so, is there no danger to overload the server,
instead of sharing the execution of the application between client and
server?

Thanks for help
Ben

 

[jan.hancic]

That depends on what your client side scripts are doing.
If it is buissnies logic then it should defenitly go to the server
code. And there are several reasons for that. For example: you don't
want someone to steal your code do you? And javascript is tricky as
anyone can disable it and then your application will not work.

Javascript should be used for client side validation (which must have
it's server-side equivalent) and for UI. But never for buissnies logic!

 

[Michael Nemtsev]

Hello ben,

b> I made an application in classic asp (reservation of books and video
b> stuffs
b> for students) and want to migrate to asp.net.
b> The user has to chose a date, then pushung on a submit button. The
b> whole day
b> is then displayed in cels of a table. The user has then to click in a
b> cel
b> representing a hour of the day and an object (book ..), and finally
b> click on
b> the submit button to insert that reservation in the database.
b> My problem is: there is a lot of javascript client-side code. All
b> onclick
b> events are executed on client-side.
b> Have i to change this into server-side code or i can still use that
b> client-side code?

Why for doing this? The current schema is normal, needn't to change it

b> Is it true that the filosophy of asp.net is: maximum server-side
b> script and minimum client-side?

It depends on your scripts, functionality and how much compatibility with
other web browsers do you need.
If everything works good now you haven't to change this for asp.net, except
where server-side code is really need

b> If so, is there no danger to overload
b> the server, instead of sharing the execution of the application
b> between client and server?

yes, it's a problem due to big VIEWSTATE (btw that is zipped pretty well)

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Bob]

Thanks for replying.
When creating an new application, what do you suggest? Using as much as
possible server-side code or finding a balance between cleint and server?
And how to determine that balance?
Ben

 

[jan.hancic]

Like I said it depends on what you need.

I would tend to stick to server side as much as possible.
Don't get me wrong I love javascript. But anybody can disable it, steal
your code or find a sceurty hole. And with javascript you can't be
shure it will work in every browser...

 

[Michael Nemtsev]

Hello Bob,

Balance is determined with the size of round-trips to the server and back.
For example if you need to fill listbox with values from another listbox
you need to do it with JavaScript, to avoid postbacks for each item transfer
between listbox.
Use such tools like HTTPWatch, Fidler to look at your VIEWSTATE and how much
postbacks in your page interactions to diminish them with JavaScripts (where
it posible only)

BTW, I recomend to apply AJAX to your new projects. It's drastically diminish
size of data transfered between client and server

B> Thanks for replying.
B> When creating an new application, what do you suggest? Using as much
B> as
B> possible server-side code or finding a balance between cleint and
B> server?
B> And how to determine that balance?
B> Ben
B> with
B>B> except
B>B> well)
B>B> not
B>---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Bob]

Thanks,
I imagined 'balance ' as something different. Suppose an application which
gets some data from the server, but then executes a lot of heavy
calculations and displays it. Is it not better to let the client executing
those calculations instead of the server?
What i mean is: what can the server best do and what can the client best do?
Is this correct: avoid postback as much as possible but let the server do
all the remaining things?

A last question maybe ...
if i want to keep the javascript on client-side for all onclick events, can
i use the new webcontrols and htmlcontrols of asp.net or i have to use the
old button, input, submit, select ... i used with asp classic?
If not, why those webcontrols then?
Thanks

 

[Guest]

The beuty of ASP.net is that you can write only server side code, yet it
generates a certain amount of client side code, where apropriate. For
examply the validation controls, you don't have to write any code at all,
just ASP.net markup, they then generate a load of client side javascript
automatically that validates the forms acording to your criteria. Also with
ASP.net2 you can use AJAX to create call backs to the server. It's horses
for courses really, i avoid client side code whenever i can, but if you are
comforatable with it or the website gets a lot of hits and you want to
minimise server load then go ahead.

 

[Michael Nemtsev]

Hello Bob,

B> Thanks,
B> I imagined 'balance ' as something different. Suppose an application
B> which
B> gets some data from the server, but then executes a lot of heavy
B> calculations and displays it. Is it not better to let the client
B> executing
B> those calculations instead of the server?

If this calculation can be easily performed on client, do in on client.
Thus you need only 1 postback to the server.
For example let used typed "2" and "2" and you press "Add" button. Using
server-side approach you need
1) to send this data to server
2) add them
3) return result to the client

It's not appropriate solution. What do you really need is to perform this
task on client.

B> What i mean is: what can the server best do and what can the client
B> best do?
B> Is this correct: avoid postback as much as possible but let the
B> server do
B> all the remaining things?

Client best for the UI tasks, and server for server ones. I take a position
to use more html controls if it's possible, and server controls for other
cases.
Several UI interactions, changing value of controls, message boxes, changing
layout are JavaScripts tasks.
And such task as dataBinding, interaction with other components (all not
UI tasks) are for server.
But there is another problem - if you site need to be working in several
browsers using JS is a tricky due to compatibility. For this case diminish
using the JS and put logic that works wrong in other browser to the server.

B> A last question maybe ...
B> if i want to keep the javascript on client-side for all onclick
B> events, can
B> i use the new webcontrols and htmlcontrols of asp.net or i have to
B> use the
B> old button, input, submit, select ... i used with asp classic?
B> If not, why those webcontrols then?

You could use HTML controls, because most of them are directly mapped
to the native html controls.
Problem is that server controls event handling is not directly mapped
to html one. I mean that for server controls, let take asp:TextBox for example,
there is no such events like "onfocus", "onclick" and etc. And you need perfrom
additiona task to assign action to this events directly from server code
using control.Attribute[] property.


To sum what I've told you about, in era of AJAX using JS is more and more
common, and if you are both confident in JS and server code
apply JS where is possible to be in the bound of browser comatibility and
time spend to implement required behavior.
For the propotype use server code, and afterward analyze the number of
postbacks and size of VIEWSTATE to find the places where to apply JS to make
you site more "thin"
B> transfer
B>B> much
B>B> (where
B>B> diminish
B>B> not
B>---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Bob]

Thanks

The beuty of ASP.net is that you can write only server side code, yet it
generates a certain amount of client side code, where apropriate. For
examply the validation controls, you don't have to write any code at all,
just ASP.net markup, they then generate a load of client side javascript
automatically that validates the forms acording to your criteria. Also with
ASP.net2 you can use AJAX to create call backs to the server. It's horses
for courses really, i avoid client side code whenever i can, but if you are
comforatable with it or the website gets a lot of hits and you want to
minimise server load then go ahead.

 

[Bob]

Thanks for your explanation

Hello Bob,

B> Thanks,
B> I imagined 'balance ' as something different. Suppose an application
B> which
B> gets some data from the server, but then executes a lot of heavy
B> calculations and displays it. Is it not better to let the client
B> executing
B> those calculations instead of the server?

If this calculation can be easily performed on client, do in on client.
Thus you need only 1 postback to the server.
For example let used typed "2" and "2" and you press "Add" button. Using
server-side approach you need
1) to send this data to server
2) add them
3) return result to the client

It's not appropriate solution. What do you really need is to perform this
task on client.

B> What i mean is: what can the server best do and what can the client
B> best do?
B> Is this correct: avoid postback as much as possible but let the
B> server do
B> all the remaining things?

Client best for the UI tasks, and server for server ones. I take a position
to use more html controls if it's possible, and server controls for other
cases.
Several UI interactions, changing value of controls, message boxes, changing
layout are JavaScripts tasks.
And such task as dataBinding, interaction with other components (all not
UI tasks) are for server.
But there is another problem - if you site need to be working in several
browsers using JS is a tricky due to compatibility. For this case diminish
using the JS and put logic that works wrong in other browser to the server.

B> A last question maybe ...
B> if i want to keep the javascript on client-side for all onclick
B> events, can
B> i use the new webcontrols and htmlcontrols of asp.net or i have to
B> use the
B> old button, input, submit, select ... i used with asp classic?
B> If not, why those webcontrols then?

You could use HTML controls, because most of them are directly mapped
to the native html controls.
Problem is that server controls event handling is not directly mapped
to html one. I mean that for server controls, let take asp:TextBox for example,
there is no such events like "onfocus", "onclick" and etc. And you need perfrom
additiona task to assign action to this events directly from server code
using control.Attribute[] property.


To sum what I've told you about, in era of AJAX using JS is more and more
common, and if you are both confident in JS and server code
apply JS where is possible to be in the bound of browser comatibility and
time spend to implement required behavior.
For the propotype use server code, and afterward analyze the number of
postbacks and size of VIEWSTATE to find the places where to apply JS to make
you site more "thin"
B> transfer
B>B> much
B>B> (where
B>B> diminish
B>B> not
B>---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche