I am changing the contents of a span with javascript. I can see that it has changed with view source.
When I try to get the contents in a c# function right after, it still has the old value.
My guess is that asp is just seeing the html that it sent the client, and that javascript is changing the client html of which asp cannnot see?
this was my only guess on how to explain it. Would this be correct?
Thanks.
Unless what you are changing support POSTing the values back to the server, then your changes will be discarded. <span>'s do not get POSTed to the server.
If you change the value of INPUT's however, then the server will be able to see those new values on the nest page submission POST, provided they are runat=server.
ASPX is SERVER SIDE. Javascript is CLIENT SIDE. The two do not mix unless you make a call back to a webservice, or something similar.
Your <span> change is only on the client, and the server is not aware of it. Look into AJAX as a solution if you wish to communicate interaction back to the server.
Yes, your guess is correct!
Javascript sees only the client side and ASP.NET only the server side. If you make some change on the client side and you want to server side to be aware of that change, you can make use of AJAX.
See Ajax for more info.
In .NET you can use a WebService, a Controller, or a Page for receiving the ajax call.
add runat="server" to your span. this will cause it to get picked up by viewstate and the new value will be available during postbacks.
edit: according to jrummel and testing by mikemanne, a span will not post back even when decorated with runat=server.
I would suggest using an input (as others suggest) instead of a span if you want the value consistently available on the server.
Related
I want to save modifications made on a HTML page(modifications made with JQuery), PERMANENTLY! I have read that this thing gets possible by sending an Ajax call and saving it in a table in a database, but what do you actually save in the database? The URL of the page? And what do you retrieve back in the Ajax call so that your modifications actually stay on the page?
This is a Spring MVC based web application, in case this information is needed.
I have no clue how to start or if to start trying saving it, because I have also read that this thing might not be possible, as we're talking about Client-Side modifications.
Modification that I am trying to make:
function versionOne() {
$('#title').addClass('text-center');
$('#title').css({"margin-top":"0px","color":"black", "font-size":"45px"});
$('#title').append('<hr>');
$('#content').addClass('col-md-6');
$('#content').css({"margin-top":"80px","font-size":"20px", "text-align":"center"});
$('#picture').addClass('col-md-6');
$('#picture').css({"border-radius":"25px", "margin-top":"50px"});
}
I'd be grateful for some suggestions!
Thanks :)
Saving the whole page won't work in most cases since it's very hard to also save the JavaScript state. So while you can save a static copy of the page without JavaScript with $('html').html(), that doesn't get you very far (or causes more trouble than it's worth).
What you want is "preferences". The site should remember some specific values. The usual approach is to load the preferences from the database before the server sends the page for the client. Apply them to the elements of the page and send the result to the browser. That way, the page looks as expected when the user sees it.
When the user changes these settings, use JavaScript to update the page and send the changes as AJAX requests to the server to persist them in the database.
When the user returns to the page, the code above will make sure that the page now looks as before.
I just realized while testing an onClick function with firebug that it would be really easy for a user to change the value of the arguments being passed. This could mess thins up.
Is there any easy way to prevent this, especially when arguments need to be passed?
It is impossible. The code is executing on the user's computer. They are in control.
If they edit it and "mess it up", then that is on their head.
If they edit it and it submits an HTTP request to your server, and your server allows (for instance) that request to delete data belonging to another user then the problem is that your server didn't check that the user submitting the request had permission to delete that data before following through.
You cannot trust anything sent from the client. The user might hand-edit the URL arguments, or a script kiddie could send you a request not even using a browser at all. You must validate everything server-side.
No, this simply can't be done.
Once the script is loaded to the client's machine. He can use/modify it, as he wants.
I'd recommend validating the arguments against expected set of values, and/or business rules wherever the results are being processed (client/server). Ideally validation checks happen on the server where the user has no control. Validation on the client side could even be modified to allow invalid data entry.
There is no way to completely control it - only validate it based on criteria.
You can't prevent this action because JavaScript is a client side . Also you can never trust the client .
You should make a validation for any request at server side to protect your data against client misuse .
you can somehow make it hidden from client eyes
by using .delegate()
EX.
$("table").delegate( "td","click", function() {<br>
// write here your function<br>
});
The client can execute this script but it isn't direct in front of his eyes ..
I'm wanting to add new comments to a list of existing comments on page. I am wondering what would be a good strategy to do that. I am thinking if comments could be submitted via ajax but added to the HTML DOM sooner (just the text) & the alloted id will be communicated to client side from the server which would also confirm that the comment was successfully saved & should be displayed.
Is it good startegy or should I update the entire updated part fetching from server side ? What is the JSF way of doing this ?
Using JSF 2.1.6 with primefaces
The second way was used by facebook earlier. But now they have switched to first way.
Also, in gmail chat, they use first way.
First update at client side, send request to server and if you do not get a successful response, show it as an error. (No need to show anything in case of successful update)
Is there a difference between me using Javascript to redirect to URL + "?Querystring=value" versus using whatever mechanism ASP.NET uses?
If there is a difference, how can I make the rendered ASP.NET page be submitted to the same URL with a different query string by javascript?
If you want to do a post back just like a asp control like a asp:Button you can use the javascript functions included by the framework to do so:
__doPostBack('ControlIDOfEventYouWantToRaise','');
You can read more about the __doPostBack in this article:
Doing or Raising Postback using __doPostBack() function from Javascript in Asp.Net
Just doing a form.submit() will not be exactly the same as using __doPostBack.
To answer the first part of your question there is no difference doing a redirect if you are just doing a Response.Redirect as the will both do a GET. The difference is if you use a asp:Button control for instance, it will access your page first to handle the button (a post back) and then do a GET on the redirected page.
If you want to submit to the same URL (eg post your data) then you should use the __doPostBack method. If you don't require the data to be posted, then just do a redirect in javascript to the same URL with a modified query string (which will just do a basic GET) but your data will not be posted.
The only potential difference is that a querystring parameter is sent via GET, a form is (usually) sent by POST.
GET has a much smaller data limit as browsers have a max URL length (it varies)
You could use javascript to do a form.submit() which shoul emulate what ASP.Net does
I somewhat disagree with Basiclife's answer; if you have any code inside something like
if (IsPostBack) {
it's not going to be equivalent, ie the code is going to be executed if you're just setting the URL. Also, controls keep their state across postbacks but are freshly initialized if you're calling the URL again. This is due to ASP.NET trying to emulate a "normal" application, so the way to make sure a normal call and a postback have the same effect might result in "de-ASP.NET-ing" the entire page.
I'm not sure if what you want works. There probably is a way. But I heavily suspect there's a better way of doing this. If you get a postback for free, and can transmit data, why is it crucial that the data shows up in the URL, instead of being comfortably posted? I can see how you want a page to respond to a URL parameter, and how you might want to change the same parameter later on based on what's happening on that page, but since you always know you're posting back, you can eg override that URL parameter in that case, by something you're posting back. This doesn't sound so nice, but it might actually be less messy. Particularly since you seem to have a reason to not abandon the postback at all (otherwise you could just use a link, right?).
i am using gwt.
i need to check some input data.
all checking functions are located in PHP server check.php
i am not using javascript checking executed from locally.
all i am doing is to send user input to server by ajax and validate in that place
and error message comes from server to client's gwt widget.
is it best approach??
i can do all checking from locally.but not doing.because server side is importent.
all checks must be resides in server so i am doing all checking from server.
if i do check locally and serverside two times ,then will it be best approach??
What you'll want to do is:
Use this account the next time you come back, or any of the others you've created, instead of creating an account each time you come to the site. Avoid this mess.
Create a .php page that accepts JSON-encoded data that you'd like to verify, and respond with some text like "OK" if it's valid. (I'm no PHP expert, but I'm sure there are plenty of them here)
Use GWT's RequestBuilder to send this data to the .php page, and call the RequestCallback's Response's getText() method. Check if the text is "OK" -- if so, the result is valid!
If you need more detail on any of the specifics, just let me know and I'll edit to clear things up.
Generally I agree with Jason (especially the with the first point :D).
I'd like to add that you should do validation on the client side first. Why? Because it allows you to weed out some obviously wrong inputs => less load on the server. But never accept the values from the client, just because your JS code said so - the general rule is to never trust the client side (because, well, it's the client side and the client can change the way your code works).
So in summary, I usually take these steps in my apps, they offer security and lower the load on your server, but may require a bit more work to write and maintain (especially if your client side and server side use different languages):
Validate input client side. If it doesn't pass, don't bother sending it to the server, just show an appropriate message.
If it does pass, send it to the server, but you must rerun the validation on the server side too.
If the server side validations report an error, send it back in some form (JSON with the error message and/or error code, set a HTTP response code, etc).