Adding comments via ajax to the server & current webpage - javascript

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)

Related

Is it possible to make a HTTP POST to a standard ASP.Net Web Form using XMLHttpRequest/FormData?

Let's suppose we have an ASP.Net Web Form, Page.aspx, in which we do the following:
<script>
$(document).ready(function () {
// grab the standard ASP.Net form
var form = document.forms['ctl01'];
form.addEventListener("submit", function (event) {
event.preventDefault();
sendData(form);
});
});
function sendData(form) {
const xhr = new XMLHttpRequest();
const fd = new FormData(form);
xhr.addEventListener("load", function (event) {
document.open();
document.write(event.target.response);
document.close();
});
xhr.addEventListener("error", function (event) {
alert('Error!');
});
xhr.open("POST", "Page.aspx");
xhr.send(fd);
}
</script>
The reason for this setup is I want to take advantage of the XMLHttpRequest progress event to erm, show some progress indication because the postback may include files that take some time to upload.
The load event handler works great. As a result of the POST I get the contents of Page.aspx again and replace my current document. So it seems that some kind of POST actually does happen BUT, there is one problem. In Page.Load(), the Request.Form and Request.Files collections are empty so I can't process the form/files.
I tried adding the following header but without much luck:
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
Do you think it is possible to make a successful POST (with page receiving data) using XMLHttpRequest/FormData, or is there some fundamental limitation that prevents this from happening for ASP.Net pages?
Thanks!
Well any ajax call simply can run some code behind, but since the web page IS STILL sitting on the client side in the browser, then things like controls and the page state are NOT available.
So you don’t want a post back, but now you asking for a post back? (I am confused). I mean, either you post back the whole page (standard event post back). Or you drop the controls and things in question into a update panel, and then ONLY that part of the page is posted back. I fail to see any advantage of trying to send “more” of the page in a ajax call when the WHOLE idea is to NOT send the page in the first place, right?
I mean, if you need some extra values in the ajax call, then you have to get/grab those bits and parts from the page, and include that information in your ajax call. (perhaps as a json string).
Without a post back, then viewstate and all of the controls are STILL just sitting on the users desktop in the browser. The code behind, and even the page class object + code ARE OUT OF scope at this point in time. Only upon a post-back does the WHOLE page travel up to server - code behind runs - you have use of full controls on the page, and THEN the whole page travels back down to the client side (and this quite much means that JavaScript code will have to re-start!!!
However, if you need a few parts and values in a page and don't want a full post-back? Then simply put those parts into a update panel. you can then in JavaScript for example do this:
varMyAspNetButton = docuement.GetElementById("Button1");
varMyAspNetButton.Click();
The above will save you world poverty and not have to wire up a bunch of js and web methods since the js code simply CLICKS on your button (that is inside the update panel). In this case, of course a whole page post back does NOT occur, but the page load and events do in fact fire - these so called "partial" page post backs means that the code behind is LIMITED to the information (controls) inside of that up-date panel.
However, as noted, if you do a post back, then the browser page NOW travels up to the server - and that quite much means any js code client side is toast and now can't run, since a whole NEW fresh copy of the web page is about to travel down to the client side again - and that re-starts your js code.
As noted, you can do a partial page post back with a update panel. And in js you can fire a "click" or in fact MOST events of asp.net controls on that page with js.
But, then again?
You don't want a full page post back, and you likely don't want all of the controls and the whole page to travel up to the server. But then again you wondering why you can't use or access controls on the page with ajax calls? Well as noted, the server side code behind is OUT of scope and OUT of context when you make ajax calls. The web page does NOT exist server side. We don't know if the user turned off their computer, or will never do anything in that client side browser and web page. The server at that point in time has lost ALL KNOWLEGE of that web page. So any ajax call does not have use of the controls on the page, and does not even have use of viewstate either.
This tends to mean that say when using say a ajax system to up-load files? Well, you can't store the status in the web page server side - since the page DOES NOT really exist at that point in time. So you can call some web methods, and about the ONLY way to keep some values in context is to use session(), since that does not need the web page, or the view state to function and work.
The major down side of session() of course is that if some user has two tabs open or even two different browsers open? Well, session() is SHARED between those pages - so while session() is great, it also shared between ALL copies of web pages for that given user - and thus you need to add code to separate out each session "set" of values, or simply hope that the user will not have two pages in operation for such file up-loads.
But to answer your question?
You can do and achieve partial page pushbacks by using a up-date panela And thus you can have timer code or js code client side to continue to run since a full page life-cycle does NOT occur. In other words, you control what part of the web page will and is sent up to the server side by using a update panel.
If you don't use a up-date panel, then any ajax calls you make WILL have to pass the data from the browser side, since it STILL just sitting on the users desktop, and any code behind can't grab, nor reach out, or see or even KNOW that the web page exists client side.
So you either pass extra values from the web page with your ajax calls OR YOU can use a update panel, drop controls inside and then the partial page post back will ONLY send up and have use of what you want inside of that panel. So you have two really great choices.
And in either case (a full page post back) or a partial one?
Grab a reference to the client side asp.net button, and fire off a .click event. You can I suppose wire up all kinds of _doPostBack in js, but with update panels and the click() trick, then you have a choice of how much of the page gets sent up, and it all quite much automatic wired up for you and saves a TRUCKLOAD of work that you would have to manually write and wire up if you don't use a update panel to control this.
So you get that "partial" page post back, and in that case the code and events inside of that up-date panel can update/see/use/modify controls in that up-date panel, but anything outside of that up-date panel will NOT have traveled up to the server.
And if you don't use a update-panel, then any ajax call is just that - a direct call to the server side - but the web page STAYS client side - thus on-load and any of the controls or objects or in fact the WHOLE class form object that represents that web page IS STILL SITTING client side - thus as noted, no on-load, no code behind can touch or even see or know about the values of controls on that page, and as noted there is also no ViewState either.
The WHOLE idea of ajax calls is that you did not want and never did want the page to travel up to the server, and then be re-rendered, and then re-sent back down to the client side. But you need to be 100% crystal clear here:
Without a page post back (or partial one with update panels), then the web page does NOT exist any more server side. Web pages are state-less and once the round trip has occurred (web page up to server - code behind runs, page sent back to client), then as far as the server is concerned (and you the developer) that web page is GONE and DOES NOT exist anymore at all - it is out of scope and from your point of view (and the server point of view) that web page does NOT exist anymore the instant it been sent back down to the client side. As noted, the only exception that is practical here is session() values - since they are not part of any given web page.
So, you have to decide if you want a partial page post back to get at and modify some values with server side code.
Or you pass the values with your ajax calls and the returned values can then update the browser controls. And of course once you do eventually do that say full page post back, then the code behind can certainly see + use any controls that the client js code changed - but can only do so with that full page post back, or as noted, controls limited to a update panel if we are talking about a partial page post back (update panel).
You either have to include additional data in your ajax calls, or consider using a partial page post back to send up part of the web page if you need to modify that part of the page with code behind. Or as noted, return information with your ajax call, and then update the client side. There not really a in-between choice here.

ajax json call throws ClientScriptManager.RegisterForEventValidation error; how to register?

I've been researching this like crazy, but I can't find a way to to get this error from triggering. I'm hoping someone here can help me.
I have a drop down list object on my page that I'm creating as a server control, but which I'm dealing with entirely client-side at run time. The reason why I'm using a server control at all is because I need it to trigger an AJAX updatepanel elsewhere on my page. Anyway, this dropdown list starts blank, but gets populated with options by some jquery code based on user input. Up to this point there's no problem, but when the user makes a selection from this dropdown, I get the ClientScriptManager error. Selecting from this dropdown triggers an ajax json call to get data from the server.
I'm registering all my client-side script files (including the one that contains the offending json call) with ClientScriptManager.RegisterClientScriptInclude. Registering the dropdown itself with RegisterforEventValidation doesn't work, because the dropdown has no options at load time.
The application works in spite of this, but the error is defeating some enhancements I want to make, so I need to put this to rest. You can see the application (and view the error in your browser's debugging console) at https://www.heritagecutter.com/MillingCalc/; the dropdown your looking for is the one headed "Series", which will become active after you make selections in Material Group and Material Type above. The error appears after you select a series.
Thanks in advance for any guidance.
Found a solution, for anyone who may stumble across this in the distant future:
So the situation with my code was that I was using mostly HTML objects, with ASP.NET server controls for those few instances where I was dealing with the server, even though those server controls were triggering client-side code at runtime. I did this because I are noobsauce.
I was already using client-side AJAX calls to contact the server for my data, so I cleared out the clever-clogs server controls (my offending drop down list, and the Ajax UpdatePanel in toto) and replaced them with HTML objects. I kept the .aspx page that contains my code, because I needed the code-behind to store the web methods being called by client-side script, and I left my web methods and ajax code alone, because the didn't need to be changed, and the error went away on the first try.
I go away somewhat embarrassed, but wiser for it.

Save jquery modified page permanently

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.

Is there a way to get the form data easily with JavaScript?

I was looking on how to get values of form data that are passed with POST requests and found this answer.
I know you you can get GET query parameters quite easily in JavaScript doing window.location.search but is there a way to do similar for POST request or document.forms is my only option?
To expand on what RUJordan said:
When you do a POST, the information is sent to the server using an entirely different method and does not show up in the URL or anywhere else that JavaScript can get access to it.
The server, and only the server, can see it.
Now, it is possible to take some of the form data and fill JavaScript variables and/or hidden form fields so the server can pass data back down to the client.
If you need more help, you'd be better off opening another question explaining exactly what problem you are trying to solve.
Do you want javascript to see the data was POSTed to load the current page?
JavaScript does not have access to the request body (where the POST content is) that loaded the page. If you want to be able to interact with the POSTed parameters, the server that received the request would need to respond with the necessary data written back out on the page where javascript can find it. This would be done after the form was submitted, as part of the response to that POST request.
Or do you want to know what your page could POST form the forms that are on it?
Inspecting document.forms will let you see what could be POSTed later if those forms were submitted. This would be done before the form was submitted, without a request being made.

Will aspx not see changes made by javascript?

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.

Categories

Resources