I am a newcomer developer to ASP.NET.
I wonder that is running forms on server (namely runat=server) the right way of coding ? I feel that all of scripts, forms etc. must run on client side because server side runnings may cause bottleneck on server side.
So what kind of advantages/ disadvantages
-running on server side
-running on client side ?
Yes, that runat=server means that ASP.Net does some processing on the server side.
This processing means that
You have an object model you can use in your code, to access properties of your controls and event handlers (such as an OnClick for the various Buttons)
The (possibly complicated - see grids) HTML is generated to be sent to the client (=browser)
The real form/script etc does run on the client. Validations run both client-side and server-side.
I think this link will give you a good understanding of the difference. difference between server and client controls There are plenty of explanations out there if you just Google
Related
What are the main differences between Resumability , Hydration and Reconcillation ?
We know Resumability is future of web app, Is it possible to make most of the current meta framework (Nextjs,Remix, Sveltekit, Solidstart, etc.. ) resumable ?
SSR means server side rendering. It is desired for search engine optimization and faster load time. Hovewer. a server written in Javascript does not have the same API as the browser. So, there is no way to render full application. Even if it is possible, it would not make sense since runtime environments are tailored for different use cases. For example, there is no click events on the server side, etc. So, SSR returns partially rendered application + client side code.
When client side code executes, it will hydrate the application, meaning it will take the partially rendered app returned from the server, calculate the new state and bind events etc. Client side application does less work than its client only version but still some tasks are repeated. Resumable frameworks like Qwik tries to address this shortcoming.
In Resumabilty, there is no hydration. Client side logic is infused into the server returned code. Qwik serializes the application's state and framework state into HTML. Events like click event are be bound to the UI upon user's interaction, when user clicks on a button.
Reconciliation means reconciling two states, in other words diffing and patching previously rendered state of the application. React uses virtual DOM and re-renders everything when the state changes. But for a large application, this is costly. So, rather than re-calculating whole DOM, it keeps the unchanged parts and re-renders only changed branches. In the context of server side rendering, reconciliation means reconciling server side rendered state of the application with client side rendering logic.
We know Resumability is future of web app.
This is a bold statement. In computer science everything is a tradeoff.
Is it possible to make most of the current meta framework resumable ?
I don't think so. Maybe some of them but definitely not all because resumability is hard to retrofit and may require complete re-write. Not all applications needs SSR or search engine optimization.
If I have a intranet application and am doing both client & server side validation - should I be designing the server side validation (which is done mainly for security reasons) to have a similar look to the client side validation?
I suppose what I am asking is: does server side validation need to really return proper error messages at the field level? Or can it simply reject the page, as the user should be using javascript in a modern browser? (I am using Kendo for client side validation which will work in major browsers).
Is this a strategy sometimes performed, or is there reasons for having the server side validation be useful in a visual sense? If so, what's the reason for this, and does it change if the site is public facing?
Thanks!
I think there are definitely instances where you will want your server side validation to be as user friendly as your client side validation. Imagine a common scenario where your user has to input some login details. You can validate some of this client side - the email address is properly formatted, for example - but from a security point of view you would want to check that the login information is correct on the server, and if the password isn't right then you need to pass a friendly message back. Rejecting the whole page in this case would be OK but that doesn't tell the user where they went wrong.
What client side validation does is allow you to cut down on the amount of server side validation that you need to perform. Checking that certain types of input - mandatory fields or phone numbers - are correct is a lot quicker to do client side and this adds to the overall user experience. It's also becoming technically much quicker to add client side validation; it's pretty well embedded into HTML 5 and there are a number of great jQuery libraries. But friendly server - side validation will always have a place where security is a requirement.
Why do we need both client side and server side validation ? i have read that both are necessary for security reasons.. so if client side validation can be bypass then why not use only server side..what is the use of using client side..
It is important for users with slow/restricted/limited internet connection to avoid unnecessary request to the server (e.g. request to submit a form containing invalid data, which will eventually get rejected by the server). The waiting time for the response may become a reason for a user to leave your web page, and then talk bad about your web site to friends and relatives, or even to whoever.
We always want to make all users happy, don't we (even though sometimes we feel that they are the enemy)
Client side validation helps the user to correct the errors without a full postback with all error messages in it. It enhances efficiency, but its just a convenience and can obviously be bypassed.
it's not good practice postback for every validation so you will need to put client side validation to validate fields which are mandatory so you should put client side validation also
About Server side validation, you cant realy compltetly on client side in case browser javascript disabled it is better to be validated at server side.
With client-side rendering, your initial request loads the page layout, CSS and JavaScript. It's all common except that some or all of the content isn't included. Instead, the JavaScript makes another request, gets a response (likely in JSON), and generates the appropriate HTML (likely using a templating library).For subsequent updates to the page, the client-side rendering approach repeats the steps it used to get the initial content. Namely, JavaScript is used to get some JSON data and templating is used to create the HTML.
Updates using server-side rendering is where a lot of developers start going off the deep end. They actually think page refresh
Both client-side and server-side are needed for many reasons. i am writing few points that will explain why it is necessary
for every from validation a request sent from web browser to the web server. so it is a unnecessary overhead to the server for checking every control to validate. suppose 1,00,000 people sending the same request to the server. For every request and response it will take some time(may be in nano seconds) which is really unnecessary. so it is recommended to use client-side validation.
For security reason we must use the server-side validation. As a programmer it is responsible to stop the bad data coming to our application. suppose in browser someone intentionally or by unknowingly disable the JavaScript and trying to insert the data. if server-side validation is not present there bad data can come to our application. Data may be some wrong information or it can be a self executed program also which is really harmful for our application.
so it is recommended to use both client-side and server-side validation for a better standard application.
You don't need client side, but it's much more convenient for the user if a post-back isn't necessary. If you don't care about the UX, you can make all of your validators server-side only and your data and operations will be protected.
I was wondering if there is any way to always run some server side code when a user leaves a page in ASP.NET. The page Unload event is no good because that doesn't get called if someone clicks on a link. Ideally I'd also like the code to run even if the user closes the browser.
I suspect what I'm asking isn't possible, but it doesn't hurt to ask
Problem is, HTTP is a stateless protocol, so when the page has finished being served, you wont know if the user is still on the page or not.
The only way to acheive this would be a hidden piece of Javascript that constantly pings the server with it's session ID, or another similar mechanism. When the ping becomes unresponsive you can reasonably assume the page is not being viewed by the user anymore.
Here is a diagram that explains traditional HTTP message flow.
im not really sure if you can do that but i have a workaround in mind.
There is an event in the DOM called onbeforeunload. it get calls everytime a user leaves a page. you can try sending an ajax request to the server from this function.
The closest thing you can come without creating too messy a solution is to enable ASP sessions. This will create a session on the server for each visitor, who will be identified by a cookie.
After a certain amount of inactivity from the visitor, the session will be closed, and a SessionEnd event will be raised. This you can hook up to in the Global.asax file.
I will not recommend this however, because HTTP is pr. definition a session-less protocol, and using server based sessions violates this fact, and are often problematic. Many solutions that use server based sessions run into problems when the user uses the browser-back button, and resubmits a form. Because the content of the submitted form no longer corresponds the data that exists in the server session.
Also, enabling server based sessions seriously hurts the scalability of the application.
Not that I know of. You'll need to use javascript for that, and call a web service on the server side.
This may be a dumb question - and the title may need to be improved... I think my requirement is pretty simple: I want to send a request for data from a client to a server program, and the server (not the client) should respond with something like "Received your request - working on it". The client then does other work. Then when the server has obtained the data, it should send an asynchronous message (a popup?) saying "I've got your data; click on ... (presumably a URL) to obtain data". I have been assuming that the server could be written in Java and that client is html and JavaScript. I haven't been able to come up with a clean solution - help would be appreciated.
Try to employ "Websocket Method" by using "SuperWebSocket" for server side, and "WebSocket4Net" for client side. It is working perfectly for my current project.
Most of the work invovles the server being asynchronous. To do this you must
Have an ajax call to the server that starts a job and returns a confirmation the job has been started.
A page on the server that will return whether or not any jobs are complete for a user.
Have an ajax widget on your client side that pings that page on teh server every so often to see if any jobs have been completed. And if so make a pop up.
This is the only way unless you use Flex data services.
Are you trying to do this on the HTTP protocol? It sounds like you're talking about a web application here, but it's not clear from the question. If so, then there are a variety of techniques for accomplishing this using AJAX which collectively go under the name "Comet". Depending on exactly what you're trying to accomplish, a number of different implementation, on both the client and server side, may be appropriate.
for pure java i suggest something like jgroups (client+server are java)
for html, you should use ajax - there you have a timer that checks every X seconds
Nowadays you have an alternative technique to use: Websockets. These are used for server->client communication without polling or ajax-style delayed responses.