I don't understand. I have searched all internet forums but found nothing helpful. I am trying to update the numberOfLikes field on my postsTable in MySql when the user clicks on the like button. I know this is done through ajax but I am only familiar with prototype ajax and none internet forums state anything about it.
Here's the flow chart
1. On "seeForums.php" user clicks on the "like" link.
2. The like link has an id that triggers the function which updates numberOfLikes on my postsTable.
Thats it. Thats all I need. But I need it in a prototype ajax format, something like this.
function processLikes()
{
new Ajax.Request(theUrl,
{
contentType:"text/HTML",
onSuccess:updateLikesMySql,
onFailure:error
onException:error,
});
}
Helps are appreciated :)
You can't do this with Javascript alone as it is client side only, you'll need to get a server side language (e.g. PHP) involved as well.
The idea is that you send an AJAX request to your PHP file along with the data that you want to update, and your PHP file will handle inserting values into the database. That PHP file would then print an output (e.g. success or failure) which would be received in your Javascript so you can act accordingly.
You should know that the nature of HTTP (web) makes it Request/Response like.
So your backend code runs on the server,
And javascript and all frontend code run on the client.
Client has no access to your database, So you can't do anything to your database with Javascript.
Best thing you can do is ask your serve with javascript to update the database,
Make a server-side script available at some URL,
Then use ajax to call that URL.
In the server-side script, do the code which updates the database.
Related
this is my first post and I am trying to get back to technology after a break of few years. Really enjoying coding again and decided to learn the MERN stack first. I went through some tutorials and then started to build a website for my business. Created a few pages here and there and was fairly successful to build most things via express, HTML and CSS, until I hit a situation.
Question.- I have an app.post for my '/ranking' route and in this function I am performing some logic. This app.post is being called from the '/ranking' page when the user hits the "View Profile" button. The idea is to pick up unique ID as the value from the HTML template, pass it onto app.post. Then perform the business logic, which includes finding the unique values of the unique ID from the DB. Once this is done, pass it over to a /profile page with res.render. Now this is all working fine. However, after the res.render("profile") call, even though the website is going correctly to the page that I want it to, the url reads
http://localhost:3000/ranking (This is the page from where the post call made). Instead I want it to read,
http://localhost:3000/profile
If there is a solution for this please do let me know. Also if the answer implies that I haven't understood certain key concepts about express and routing, please pass me in that direction. Thanks in advance.
The URL of the route and the filename you pass to render are entirely independent.
If you want to redirect someone to a different URL, then you need to respond to the request using res.redirect and not res.render.
I have an ExpressionEngine site that I'm building with Bootstrap. It's a site for volunteers to find projects to help with. On the home page I have a modal with a form for them to select when they're available and what categories of jobs they're looking for. Then they can click submit and it'll go to a new page with filtered entries.
I don't know if this is possible using the GET method or POST method on the form. I've figured out how to use the GET method and get a query string into my URL but I don't know how to use that data to filter my entries on the entries page. Or would using POST and JSON be a better option? I don't know really how to implement either so any help would be great.
Thanks a lot!
It depends on how the information you would like to show is stored.
If you are using MySQL (a common RDMS), or any other form of SQL Database for that matter, the most common way is to send your GET query string (for example) to your server, have a sever-side language (such as PHP) handle that request by accessing your database, and then echo the result. This can be done synchronously, or with AJAX.
For example, the flow of everything might look like this:
User selects an option (say, "Gardening Projects").
JavaScript converts the value of that input option to a query string and sends an HTTP request using the GET method.
The destination of this request is "filter.php" (for example).
"filter.php" access your database using an SQL query, which searches for any entries in your database, say, having a tag of "gardening".
"filter.php" echos a statement with those entries (or, better yet, returns a JSON object)
JavaScript then parses the resultant JSON object into the DOM, which displays as a bunch of links in a result area that your user can click on.
The question you have about how to handle this is very broad, so I would recommend simply doing some Google searches or looking around this site for resources that show you how to set up databases, access those databases with possibly PHP/SQL, and maybe even use AJAX to return those results, etc.
To get you started (these are in no particular order):
AJAX Tutorial
PHP - JSON encode
SQL tutorial
jQuery AJAX
I got it figured out with some help from #JoshBeam. It turns out that I was trying to make it way more complicated than it actually is. Rookie mistake. In the end I just ended up using method=get in my form and the setting the action as the page with the filtered entries. I then used php to echo the inputs into my EE channel:entries tag.
One thing I still haven't figured out is how to make it so that my query string will combine values for matching names. Currently I have checkboxes for days of the week, each with name="day" and different values for each day. If there are multiple checked, my query string becomes example.com/?day=sun&day=mon when I'd rather have it as example.com/?day=sun&mon. So if anyone has any tips on that, I'd welcome them! I also wonder if there's a way to add pipes between each value when I echo them in my EE tag so that I can have multiples - e.g. {exp:channel:entries category="1|2|3"}. But I have really yet to Google either of these questions so I'll do that.
Thanks!
I am creating a dashboard application in which i show information about the servers. I have a Servlet called "poller.java" that will collect information from the servers and send it back to a client.jsp file. In the client.jsp , i make AJAX calls every 2 minutes to call the poller.java servlet in order to get information about the servers.
The client.jsp file shows information in the form of a table like
server1 info
server 2 info
Now, i want to add one more functionality. when the user clicks on the server1, I should show a separate page (call it server1.jsp) containing the time stamps in which the AJAX call was made by calling.jsp and the server information that was retrieved. This information is available in my calling.jsp page. But, how do i show it in the next page.
Initially, i thought of writing to a file and then retrieving it in my server1.jsp file. But, I dont think it is a good approach. I am sure i am missing a much simpler way to do this. Can someone help me ?
You should name your servlet Poller.java not poller.java. Classes should always start with an uppercase. You can implement your servlet to forward to a different page for example if sombody clicks to server1 then the servlet will forward to server1.jsp. Have a look at RequestDispatcher for this. Passing information between request's should be done by request attributes. if you need to retain the information over several request you could think about using session.
In the .NET world, we use SessionState to maintain data that must persist between requests. Surely there's something similar for JSP? (The session object, perhaps.)
If you can't use session state in a servelet, you're going to have to fall back on a physical backing store. I'd use a database, or a known standard file format (like XML). Avoid home-brew file formats that require you to write your own parser.
I am trying to validate that a username is unique on a registration form and would like to verify the uniqueness of the username right after the client types it as opposed to performing this server side after the form has been submitted.
Should I collect a resultSet from the database, store it in an array and then pass this along to the jsp page in the form of a bean (I am using a model 2 design so the user passes through a servlet before arriving at the jsp page)? What if the array is very large? How do I bring this data into javascript?
Alternatively, is there a way to do the query using ajax and javascript all on the client side? Maybe its possible to somehow run the query in the background?
I am really just looking for some direction because I am clueless as to what to even begin researching something like this. Is this even a smart move, performance wise?
I'd use "AJAX" for this.
Here's one approach: set up a blur() handler on the username text field of your form. When the blur() method is invoked, you post the username to the backend code; it verifies it and returns some appropriate response. You then parse the response and change the CSS class on the username text field (e.g., turning it red) -- or do whatever else visually you want to do to indicate "username in use."
Either way, you've got to get the username from the client to the server for verification; you wouldn't want any mechanism which allowed the client to directly use the DB (think security/exploits/etc).
If you're not already familiar, check out jQuery (http://jquery.com/) to make your client-side life much easier.
Even if I offer alternatives to PUT and DELETE (c.f. "Low REST"), how can I provide user-friendly form validation for users who access my web service from the browser, while still exposing RESTful URIs? The form validation problem (described below) is my current quandry, but the broader question I want to ask is: if I go down the path of trying to provide both a RESTful public interface and a non-javascript HTML interface, is it going to make life easier or harder? Do they play together at all?
In theory, it should be merely a matter of varying the output format. A machine can query the URL "/people", and get a list of people in XML. A human user can point their browser at the same URL, and get a pretty HTML response instead. (I'm using the URL examples from the microformats wiki, which seem fairly reasonable).
Creating a new person resource is done with a POST request to the "/people" URL. To achieve this, the human user can first visit "/people/new", which returns a static HTML form for creating the resource. The form has method=POST and action="/people". That will work fine if the user's input is valid, but what if we do validation on the server side and discover an error? The friendly thing would be to return the form, populated with the data the user just entered, plus an error message so that they can fix the problem and resubmit. But we can't return that output directly from a POST to "/people" or it breaks our URL system, and if we redirect the user back to the "/people/new" form then there is no way to report the error and repopulate the form (unless we store the data to session state, which would be even less RESTful).
With javascript, things would be much easier. Just do the POST in the background, and if it fails then display the error at the top of the form. But I want the app to degrade gracefully when javascript support isn't available. At the moment, I'm led to conclude that a non-trivial web app cannot implement an HTML interface without javascript, and use a conventional RESTful URL scheme (such as that described on the microformats wiki). If I'm wrong, please tell me so!
Related questions on Stack Overflow (neither of which deal with form validation):
How to send HTML form RESTfully?
How do you implement resource "edit" forms in a RESTful way?
you could have the html form post directly to /people/new. If the validation fails, rerender the edit form with the appropriate information. If it succeeds, forward the user to the new URL. This would be consistent with the REST architecture as I understand it.
I saw you comment to Monis Iqbal, and I have to admit I don't know what you mean by "non-RESTful URLS". The only thing the REST architecture asks from a URL is that it be opaque, and that it be uniquely paired to a resource. REST doesn't care what it looks like, what's in it, how slashes or used, how many are used, or anything like that. The visible design of the URL is up to you and REST has no bearing.
Thanks for the responses. They have freed my mind a bit, and so in response to my own question I would like to propose an alternative set of RESTful URL conventions which actually embrace the two methods (GET and POST) of the non-AJAX world, instead of trying to work around them.
Edit: As commenters have pointed out, these "conventions" should not be part of the RESTful API itself. On the other hand, internal conventions are useful because they make the server-side implementation more consistent and hence easier for developers to understand and maintain. RESTful clients, however, should treat the URLs as opaque, and always obtain them as hyperlinks, never by constructing URLs themselves.
GET /people
return a list of all records
GET /people/new
return a form for adding a new record
POST /people/new
create a new record
(for an HTML client, return the form again if the input is invalid, otherwise redirect to the new resource)
GET /people/1
return the first record
GET /people/1/edit
return a form for editing the first record
POST /people/1/edit
update the first record
GET /people/1/delete
return a form for deleting the record
(may be simply a confirmation - are you sure you want to delete?)
POST /people/1/delete
delete the record
There is a pattern here: GET on a resource, e.g. "/people/1", returns the record itself. GET on resource+operation returns an HTML form, e.g. "/people/1/edit". POST on resource+operation actually executes the operation.
Perhaps this is not quite so elegant as using additional HTTP verbs (PUT and DELETE), but these URLs should work well with vanilla HTML forms. They should also be pretty self-explanatory to a human user...I'm a believer in the idea that "the URL is part of the UI" for users accessing the web server via a browser.
P.S. Let me explain how I would do the deletes. The "/people/1" view will have a link to "/people/1/delete", with an onclick javascript handler. With javascript enabled, the click is intercepted and a confirmation box presented to the user. If they confirm the delete, a POST is sent, deleting the record immediately. But if javascript is disabled, clicking the link will instead send a GET request, which returns a delete confirmation form from the server, and that form sends the POST to perform the delete. Thus, javascript improves the user experience (faster response), but without it the website degrades gracefully.
Why do you want to create a second "API" using XML?
Your HTML contains the data your user needs to see. HTML is relatively easy to parse. The class attribute can be used to add semantics as microformats do. Your HTML contains forms and links to be able to access all of the functionality of your application.
Why would you create another interface that delivers completely semantic free application/xml that will likely contain no hypermedia links so that you now have to hard code urls into your client, creating nasty coupling?
If you can get your application working using HTML in a web browser without needing to store session state, then you already have a RESTful API. Don't kill yourself trying to design a bunch of URLs that corresponds to someone's idea of a standard.
Here is a quote from Roy Fielding,
A REST API must not define fixed
resource names or hierarchies
I know this flies in the face of probably almost every example of REST that you have seen but that is because they are all wrong. I know I am starting to sound like a religious zealot, but it kills me to see people struggling to design RESTful API's when they are starting off on completely the wrong foot.
Listen to Breton when he says "REST doesn't care what [the url] looks like" and #Wahnfrieden will be along soon to tell you the same thing. That microformats page is horrible advice for someone trying to do REST. I'm not saying it is horrible advice for someone creating some other kind of HTTP API, just not a RESTful one.
Why not use AJAX to do the work on the client side and if javascript is disabled then design the html so that the conventional POST would work.