My prof said that dynamic pages get created by the computer, while static pages are created by the user.
Thank you so much!
The difference between static pages and dynamic pages.
a static page has a generic URL suffix, such as .htm, .html, .shtml, and does not contain "?";
Websites using dynamic page skills can perform more functions such as user registration, login, online survey, user management, order management, etc.;
Application and web languages:
Static web pages: HTML, JavaScript, CSS, etc.
Dynamic Web Pages: PHP, CGI, AJAX, ASP, ASP.NET, etc.
Dynamic web pages are used where information changes frequently, such as stock prices, weather information, news and sports news.
Static web pages have fixed content, while dynamic web pages can have changing content.
Static web pages must be modified manually, while changes to a dynamic page can be loaded through an application whose resources are stored in a database.
Static web pages only use a web server, while dynamic web pages use a web server, an application server, and a database.
Regarding: "How to tell if a website is static or dynamic?"
Static websites are simple web pages (typically written in languages like JavaScript, HTML, CSS, etc.) and stored in a web server. In the case of static web pages, as soon as a server receives a request for a page, it immediately sends a response to the client with no additional processing. Users will always view the same content regardless of their location, device type, and web browser.
In static websites, the displayed content remains the same unless someone manually edits the HTML source code on every page that’s part of the website. These pages contain no alterations based on any user input. Hence the name- static web pages. You don't necessarily need any prior experience with database design and web programming to create and maintain a static website. As long as they don't change when we update them, the code for static web pages stays the same.
On the other hand, Dynamic web pages have greater complexity than static ones because they display different content for each user while retaining the same layout and design. A dynamic website generates web pages in real-time. The flexible nature of the content allows for customization based on the requests from the user or the browser used by them. Such pages are usually written in languages like CGI, AJAX, ASP or ASP.NET, and they usually take more time to load than static web pages. They are frequently implemented to show information that changes frequently, e.g., weather updates, stock prices, etc.
Server-side code used to construct a dynamic web page can generate real-time HTML pages for each request from an individual user. While static websites are mostly informational, dynamic websites contain interactive, continually changing elements. In order to provide an interactive website experience for visitors, web developers usually combine both client-side and server-side programming techniques.
Dynamic web pages usually contain application programs for various services and require server-side resources like databases. A dynamic website accesses content from a CMS (Content Management System), which means that the website reflects any changes made in the database content. These sites use client-side scripting, server-side scripting, or both for generating content. Separating the site’s design from its content makes it easier for web designers to create pages without having to worry about formatting issues. After uploading content into the database, websites retrieve their content from there when responding to user requests.
Now, regarding "Would www.tagpro.gg (the homepage) be static or dynamic?"
I have visited the homepage and it is a dynamic webpage actually as you mentioned.
My prof said that dynamic pages get created by the computer, while static pages are created by the user.
Well, actually also static pages can be generated by the computer, since there are a lot of static sites generators out there. Take for example https://astro.build or https://gohugo.io
Would www.tagpro.gg be static or dynamic?
You are right, it is dynamic, since you can see a login/sign-up feature on the page. That's nothing you can achieve with a 100% static site.
Its very simple... Only major two factors matter -
A static website does not have artificial intelligence means it cannot add something automatically the user has to type the code for that is he wants to do so but a dynamic website can do it on its own.
A static website cannot store a information means it only includes frontend no backend no php, node.js or something like that. In simpler words if user signin to your website you would not able to store his username and password.
I recently created a small website where users can sign-in (session is stored as a cookie with the flag HttpOnly).
Users can create and upload their own files and share some of them with their friends/colleagues or even make them completely public.
The issue I have is that these files can be HTML files that run their own custom JavaScript (and I would like to keep supporting this feature, i.e. allow them to have custom JavaScript).
But of course, since all of this is happening from the same domain there is no CORS to protect the user. This means it's possible to have a malicious user create a page with custom JavaScript that will fetch all the other files for the user that views this page (including private ones). And send these files to the malicious user. Additionally the custom JavaScript could also fetch other private information for that user from other endpoints.
Does anyone have any ideas of a good way to deal with this security risk (while still keeping the feature of allowing users to have their own HTML pages with custom JavaScript)?
I have a challenge that I can't solve. I have made a website with node.js and have all of the code written for the routing including routing for sub-domains. Some location only some users can access, some locations only logged in users can access. I wanted to include a chat for my users so I went along and created one with socket.io and some client side js.
Now I need the site to keep the chat element open which in on a bar across the screen when the client goes to another portion of the website. I have looked into many solutions but almost all of them include some js library like angular.js with the ng-model or ui technique but all include writing code for the client side that handles the url and what to load.
I don't really want to do this method because:
I don't want to re-write all my routes and I am not even sure how to handle the authentication of the users.
I find the client method to be a security issue
My website isn't a single page app, I just want one portion of the website to stay loaded.
Here is some images of what I am wanting:
State 1:
State1
State 2:
State2
Notice that the chat stays but other content was loaded. Also that it went to a different sub domain and a location that is only accessible by logged in users.
Thanks!
I guess you want to maintain state across page refresh, much like e.g. Facebook does. A true and trusted way of doing this is setting a cookie that stores the chat state: open/closed, or store the state on the server. Then on page load, initialize the chat based on this data.
I'd like to create a site with Angular (I'm new), but also want to be able to have different "views" be cachable in the search engines and have their own URL routes. How would I achieve this with Angular, or is best not to use it?
Enable pushState in Angular with $locationProvider.html5Mode(true); so that you have real URLs and make sure that, when the URL is requested by the client, you deliver the complete page for that URL from the server (and not a set of empty templates that you populate with JS).
When a link is followed, you'll go through an Angular view and update the existing DOM (while changing the URL with pushState) but the initial load should be a complete page.
This does mean duplicating effort (you need client and server side versions of the code for building each page). Isomorphic JS is popular for dealing with that issue.
If you want to expose Angular views to search engines and other bots, I suggest using an open source framework that we developed at Say Media. It uses node.js to render the pages on the server when it detects a bot vs a real user. You can find it here:
https://github.com/saymedia/angularjs-server
I would suggest not using different routes, however, as most search engines will penalize you for having duplicate content on multiple urls. And while you might think they would just hit the bot version of your site, they are getting more sophisticated about crawling single page app like sites. I would be cautious about duplicate routes for the same content.
Good Luck!
I'm not sure the best way to explain this in words, so I'll give an example to explain what I mean.
When you go to Google, you have a header that contains many different web apps (search, images, gmail etc). These are each independent apps that can be updated separately from all the others, yet share common components (login, the header bar itself etc). How are they doing this?
Right now I have a single app. The top bar has a few different tabs. I need to add two new web apps that can each be updated / sold individually from the other. If someone buys all 3, they should see all 3 in the nav bar. If they only bought 1, they should only see 1. There should be a single login for all these things. I'm not sure how to do this while keeping each thing independent so that can be updated on their own schedule.
The issue is how do I maintain the same nav bar between all 3 sites? This nav bar needs to be configurable (showing only the products they own, as well as other modifications such as font, language etc). I can handle the SSO parts, its the shared code between different apps, and the customization behind it.
Basically, you need to separate the following concerns:
login / user data (who is it?)
licensing (what did they pay for?)
app metadata (what apps do we sell? their name, icon, URL etc.)
app framework (the meta nav bar)
individual apps
To illustrate:
You require a sign-on mechanism (custom solution or third party, like OpenID). The login form is the same for all apps and is concerned with user data only. Login queries your customer database to see if we recognize the user who's signing on, and if we do, set a cookie etc. - that's it.
Each of your apps must include your "app framework" (think of it as a library), which does the following: For the current user (valid cookie etc.) it queries the licensing database for the apps this user purchased. It can then query your app metadata for the purchased apps and generate a nice nav bar with links/icons of those apps only.
Your individual apps do not know anything about the other apps. They don't include any code that deals with logon or switching between apps. All those tasks are delegated to your meta framework, which checks if the user is signed on and generates the nav bar. The app simply displays it at the appropriate place (e.g. top of page).
All of this happens server-sided, of course, and details depend on the actual technologies used.
If you have 3 independent WebApps and want to use a single login for all of them: You might want to look at SSO Single Sign On