I am currently working on the development of a platform and I was wondering how sites like Behance, Artsation and upwork do to partially reload their page. (When you click on a link, the page loads well but the menu does not move just like the footer). I first thought of Nginx but Artsation does not seem to be used Nginx.
I would like to know the things to reproduce this kind of loading page if someone could enlighten me on the subject.
EDIT: I already know ajax, but the thing is that on behance, the server seems to really redirect
Thanks
You probably should learn about AJAX, here is a starting place:
https://developer.mozilla.org/en-US/docs/Web/Guide/AJAX/Getting_Started
And if you use jquery
https://learn.jquery.com/ajax/
First of all, Behance uses Ngnix.
Second, If you want to create a real-time web application you need to do it with NodeJS and Express or any framework based on NodeJS. But there is an alternative, which is Ajax.
So using ajax will helps you to load contents on your website in each couple of seconds or load a part of your page.
See: https://www.youtube.com/watch?v=ytKc0QsVRY4
Maybe I was not clear enough or I went a bit in the air asking the question, I'm sorry.
I already use Vuejs for my project (all front end, router, store, I use axios to recover data from my API), but I'm looking for a way to relieve JS files that weigh more than 2 MB. That's why Behance interest me, it seems to give this impression of redirection without redirection, I would rather say that it is this effect that I would like to reproduce.
Next time I will try to ask questions more clearly :)
Sorry for the inconvenience
Related
I am not sure the scope of this project exactly, I'm hoping someone here might have prior experience with this.
I have a project which is to develop a mobile site which will serve as a framework to display content. the 'app' will be a simple list, and when an item is selected, the frame would disappear and pull up the selected content. The display would be extended across the iPad an another separate monitor.
I would have no issues creating something that functioned in this way, however..
I was wondering if there were any way to keep the iPad's interface static (the frame does not disappear and the list content does not display on the iPad), and changing the the current active site on the larger display?
I have intermediate experience with server side languages such as PHP and Ruby, and know my way around javascript (especially ajax calls). I do not however know how to approach this concept. Is this even possible? I would appreciate any feedback or discussion. I am sorry if this question seems more open ended than simple.
Server-Sent Events were the key to success in this situation.
http://www.html5rocks.com/en/tutorials/eventsource/basics/
I have a script running on the external display (site.com/container), and an AJAX call running on the remote (site.com/remote).
When the user selects an item on the iPad graphically, the Ajax call stores the value in a file. The contents of this file are then sent via the SSE data format (at a set retry interval) and interpreted back on the external display (site.com/container).
this is not quite as perfect as the 'detect on event' that I would have hoped for, but as far as functionality goes, it certainly seems to work. Hopefully I can improve upon the steps I'm taking and make make the whole thing more concise.
I recently created a website where a user logs in and accesses various forms and other things. I was wondering, after login, how can I change the php code so that it automatically modifies a portion of the page making it personal? Here is a screen shot of the front end.
I would like the login form portion disappear and then have a new layout replace it. Would I use Javascript or AJAX. If either, does anyone have any guidance on how to go about doing this project?
It sounds like one of your goals is to minimize page refreshes, possibly having none at all.
Your main challenges include:
1. Managing possibly lots of unrelated DIVs, which make up your functional segments.
2. Speed issues - lots of code crammed into one page.
3. All input sent asynchronously (things get complicated very fast when you want to do EVERYTHING with AJAX!)
As far as your initial login menu, you can fade that out by wrapping it in a DIV and calling jQuery's fadeOut() function on it. To update PHP components without refresh, that's where your AJAX comes in. You're going to want to use a little of each and like therealsix said, they're all essentially Javascipt at the core.
My best advice would be to spend a big chunk of your time dedicated to this project in the planning stage. Understand how you are going to deal with DIVs crashing into each other. Develop an overall table layout that gives you flexibility concerning where content DIVs come in and out. Think about which ones are replaceable at any given time. Study up on modular coding.
That's broad advice because I don't know what exactly the project entails, so if you have any specific issues, let me know.
I would say neither. If you're going to change the whole page, just redirect to a new page.
If you needed to do this without a page reload you would need to use javascript and AJAX (ajax in some sense is javascript). Then I would recommend you look at the jquery functions (http://api.jquery.com/load/)
A couple of years ago, before I knew about Stack Overflow, I was working in an office with a lot of competition between the programmers. There, I had to code a web page in PHP with Drupal, that needed to get data from another site by RSS. What happened was that there was no way to get the data beforehand: the data depended on the content of the page which itself was dynamic, so the page stopped loading for a couple of seconds while PHP went to get the RSS data. That was bad. The page depended on a couple of parameters out of a huge list. So fetching all possible combinations in davance was out of the questions. It was some sort of search page, that included the results of a sister site, I think.
The first thing I did to improve that was to set up a caching system. When the page was loaded, it launched a Javascript method that saved the RSS data back into the database for this specific page, using AJAX. That meant that if the same page was requested again, the old data would be sent immediately. and the AJAX script would get the cache updated with the new data, if needed. The Javascript pretty much opened a hidden page on the site with a GET instruction that matched the current page's parameters. It's only a couple of days later that I realised that I could have cached the data without the AJAx. (Trust me, it's easier to spot in hindsight.) But that's not the issue I'm asking about.
But I was told not to do any caching at all. I was told that my AJAX page "exposed the API". That a malicious user could hit the hidden page again and again to do a Denial of Service attack. I thought my AJAX was a temporary solution anyway, but that caching was needed. But mostly: wasn't the DoS argument true of ANY page on the site? Did the fact that my hidden page did not appear in the menus and returned no content make it worse?
As I said, there was a lot of competition between programmers, so the people around me, who were unanimous, might have been right, or they may have tried to stop me from doing something that was bad because they were not the ones doing it. (It happened a lot.) But I'm still curious. I was fully aware that my AJAX thing was a hack. I wanted to change that system as soon as I found something better, but I thought that no caching at all was even worse. Which was true? Doesn't, by that logic, ALL AJAX expose the API? If we look past the fact that my AJAX was an ugly hack, was it really that dangerous?
I'll admit again and again that it was an ugly, temporary fix, but my question is about having a "hidden" page that returns no content that makes the server do something. How horrible is that?
both sides are right. Yes, it does "expose" the api, but ajax requests can only access publicly accessible documents/scripts in the first place, so yes, all ajax requests "expose" their target script in the same way. DoS attacks are not script specific, they are server specific, so one can perform a DoS using anything pointing to the server, not just this script your ajax calls. I would tell your buddies their argument is weak and grasping at straws, and don't be jealous :P
If I read your post correctly, it seems as if the AJAX requested version of the page would know to invalidate the cache each time?
If that's the case, then I suppose your co-worker might have been saying that the hidden page would be susceptible to a DDOS attack in a way that the full pageload wasn't. I.E. The full pageload would get a cached version on each pageload after the first, where as the AJAX version would get fresh content each time. If that's the case, then s/he's right.
By "expose the API", your co-worker was saying that you were exposing the URL of a page that was doing work that should be done in the background. The outside world should not know about a URL whose sole purpose is to do some heavy lifting task. As you even said, you found a backend solution that didn't require the user's browser knowing about your worker process at all.
Yes, having no cache at all when the page relies on heavy content is worse than having an ajax version of the page do the caching, but I think the warning from your coworker was that no page, EVEN if it's AJAX, should have the power to break the cache in a way you didn't expect or intend.
The only way this would be a problem is said "hidden page that returns no content that makes the server do something" had different authentication scheme or permissioning from the rest of the pages, or if what it made the back-end do would be inordinately heavy compared to any other page on the site that posted something.
i have a page on which i have some rating function like people who like the post can rate up or who don't can rate down.
on that link im calling a php file with some parameters passed in the anchor tag. Then in that php file im saving that rating with +1 or -1 (whichever is the case) in the database and after doing that im redirecting to that first page from where we have rated.
Now this whole function is reloading my whole page which i dont want.Is there any way with which i can do this rating without reloading the page,i want that when a person clicks on rate then just after click the rating should be shown according to what the user just did(+ or -) and that too without reloading the whole page.Is there any way to do that in php???????
Yes, it's called "Ajax". However, you don't do this on the server-side with PHP, you do it on the client-side with JavaScript. There are plenty of tutorials around, I suggest you take a look.
Note that there are many JavaScript libraries out there to make this extremely easy. I'd recommend taking a look at jQuery because I've personally found it to be the easiest to learn and use.
It seems a few answers have already been posted recommending different libraries. If you would like the avoid the (admittedly minimal) overhead of an included library, the following tutorial shows how to use a simple XMLHttpRequest object.
http://www.xul.fr/en-xml-ajax.html
The "xhr.responseText" is what you would receive back from the php processing (which would typically be done in a small, single-purpose script seperate from the primary page).
You can do this using Javascript or AJAX. There are plenty of free scripts online that can help you to do this without building the whole thing from scratch.
This page (http://www.ajaxprojects.com/ajax/tutorialdetails.php?itemid=364) has a good list of different star rating scripts you can choose from. You can Google for more.
Here's another relevant tutorial I came across when answering some other question:
http://docs.jquery.com/Tutorials:Getting%5FStarted%5Fwith%5FjQuery#Rate%5Fme:%5FUsing%5FAjax
When is it appropriate to use AJAX?
what are the pros and cons of using AJAX?
In response to my last question: some people seemed very adamant that I should only use AJAX if the situation was appropriate:
Should I add AJAX logic to my PHP classes/scripts?
In response to Chad Birch's answer:
Yes, I'm referring to when developing a "standard" site that would employ AJAX for its benefits, and wouldn't be crippled by its application. Using AJAX in a way that would kill search rankings would not be acceptable. So if "keeping the site intact" requires more work, than that would be a "con".
It's a pretty large subject, but you should be using AJAX to enhance the user experience, without making the site totally dependent on it. Remember that search engines and some other visitors won't be able to execute the AJAX, so if you rely on it to load your content, that will not work in your favor.
For example, you might think that it would be nice to have users visit your blog, and then have the page dynamically load the newest article(s) with AJAX once they're already there. However, when Google tries to index your blog, it's just going to get the blank site.
A good search term to find resources related to this subject is "progressive enhancement". There's plenty of good stuff out there, spend some time following the links around. Here's one to start you off:
http://www.alistapart.com/articles/progressiveenhancementwithjavascript/
When you are only updating part of a page or perhaps performing an action that doesn't update the page at all AJAX can be a very good tool. It's much more lightweight than an entire page refresh for something like this. Conversely, if your entire page reloads or you change to a different view, you really should just link (or post) to the new page rather than download it via AJAX and replace the entire contents.
One downside to using AJAX is that it requires javascript to be working OR you to construct your view in such a way that the UI still works without it. This is more complicated than doing it just via normal links/posts.
AJAX is usually used to perform an HTTP request while the page is already loaded (without loading another page).
The most common use is to update part of the view. Note that this does not include refreshing the whole view since you could just navigate to a new page.
Another common use is to submit forms. In all cases, but especially for forms, it is important to have good ways of handling browsers that do not have javascript or where it is disabled.
I think the advantage of using ajax technologies isn't only for creating better user-experiences, the ability to make server calls for only specific data is a huge performance benefit.
Imagine having a huge bandwidth eater site (like stackoverflow), most of the navigation done by users is done through page reloads, and data that is continuously sent over HTTP.
Of course caching and other techniques help this bandwidth over-head problem, but personally I think that sending huge chunks of HTML everytime is really a waste.
Cons are SEO (which doesn't work with highly based ajax sites) and people that have JavaScript disabled.
When your application (or your users) demand a richer user experience than a traditional webpage is able to provide.
Ajax gives you two big things:
Responsiveness - you can update only parts of a web page at a time if need be (saving the time to re-load a page). It also makes it easier to page data that is presented in a table for instance.
User Experience - This goes along with responsiveness. With AJAX you can add animations, cooler popups and special effects to give your web pages a newer, cleaner and cooler look and feel. If no one thinks this is important then look to the iPhone. User Experience draws people into an application and make them want to use it, one of the key steps in ensuring an application's success.
For a good case study, look at this site. AJAX effects like animating your new Answer when posted, popups to tell you you can't do certain things and hints that new answers have been posted since you started your own answer are all part of drawing people into this site and making it successful.
Javascript should always just be an addition to the functionality of your website. You should be able to use and navigate the site without any Javascript involved. You can use Javascript as an addition to existing functionality, for example to avoid full-page reloads. This is an important factor for accessibility. Javascript should never be used as the only possibility to reach or complete a request on your site.
As AJAX makes use of Javascript, the same applies here.
Ajax is primarily used when you want to reload part of a page without reposting all the information to the server.
Cons:
More complicated than doing a normal post (working with different browsers, writing server side code to hadle partial postbacks)
Introduces potential security vulnerabilities (
You are introducing additional code that interacts with the server. This can be a problem on both the client and server.
On the client, you need ways of sending and receiving responses. It's another way of interacting with the browser which means there is another point of entry that has to be guarded. Executing arbritary code, posting data to a non-intended source etc. There are several exploits for Ajax apps that have been plugged over time, but there will always be more.
)
Pros:
It looks flashier to end users
Allows a lot of information to be displayed on the page without having to load all at the same time
Page is more interactive.