I'm studying Web Applications at university, and at the moment we have an assignment: build a 'blog' using only CSS, Javascript and XML. We have to store the blog posts in a .xml file, which is what's got me stuck at the moment.
So, essentially I need to be able to write a Javascript function which writes to a server-side file. There are so many better ways to do this but we literally have to do it in Javascript. The teacher is totally unhelpful and everyone I asked thinks it can't be done.
I don't want anyone doing my work for me or anything, just it'd be nice to know how to do this, if it's even possible.
Cheers in advance.
If you are talking about JavaScript running in a browser, then you have to write some JavaScript that makes an HTTP request (possibly using XMLHttpRequest) to a server side process that will write the file. The client can't write directly to the server's filesystem.
If you are talking about JavaScript running on the server, then it depends on your JavaScript environment. There are lots of different ones: http://en.wikipedia.org/wiki/Server-side_JavaScript
Related
This question might have been asked in the past but I cannot seem to find the answer. I would like to navigate between pages without avec to redirect to a brand new xxx.html file. Basically, I want to keep only one html file being the index.html
In order to understand what I mean, here is a small preview of this functionality I want to achieve.
Preview
As you can see, the piece of clothing is not its individual html file. What method is used to achieve this?
What you are seeing is called a Single-Page-Application. There are a lot of frameworks with which you can create a page like this. If you are going for plain HTML/CSS/JavaScript it will be a lot harder to do correctly.
What you're seeing here is a dynamic webpage that is taking advantage of client-side technology to create this effect. To help further explain, let's quickly go over some web development terminology:
Client-Side: Code that is executed on the user's computer (in this case in their web browser).
Server-Side: Code that is executed on a server, then a response of some sort is sent to the client.
With server-side code, the value cannot change unless a new call is made to the server to get a new response. This is because the code isn't actually running on the computer the user is running, it's running on some other computer probably thousands of miles away. However, with client-side code, dynamic changes could be made in real-time because the code is actually running on the user's computer.
When it comes to server-side code, we as developers have a myriad of options. Any language that can send an HTTP response to a web browser could theoretically be used as a server side language. In 2018, that's basically every major language in existence! That being said, some popular options today include Python, Ruby, Java, and Javascript (Node JS).
When it comes to client-side code, however, we're limited by what can run in a user's web browser. In general, modern web browsers only understand Javascript. However, while the language has gotten better over the years, writing code in pure JavaScript can sometimes be cumbersome, so there are libraries that help make writing Javascript easier (such as jQuery) and there are even languages that compile down to Javascript to add new syntax and functionality (such as Typescript and Coffeescript).
If you'd like to start writing dynamic web applications, a good place to start would be to learn the basics of JavaScript. Then, maybe start learning jQuery, or front-end libraries such as Angular or React. Good luck!
You will have to use javascript for this. Either you can load all content at once and just show/hide the content you need, or you could ajax to fetch the content and then render it without page reload.
Currently, I am developing a 2-player tetris game. Originally, I was planning to implement a client-server model in a mobile environment.
However, now I change into web game, which is accessible by a browser. Since I am not used to a web development, I want to know if client-server model is necessary in a web game.
To be honest, I am a little bit skeptical writing both client and server code since a browser does a job to connect to the server.
Is it possible to build a network-based game by using only one server without a client part?
Is it possible to build a network-based game by using only one server without a client part?
Nope. You need a client.
It doesn't matter if you're in the browser or writing a native application. Yes, the browser solves a lot of client problems for you - it implements HTTP for you, and it has display (CSS), content (HTML), and evented logic (JavaScript) that you can use. But you still need to write your client using those technologies.
Even if the browser exposed a call in javascript like this:
window.startPeterHwangsTetrisGame();
You still have a client. The client is 1 line of code, and it is exactly the above script*.
Realistically, you should look for a game-oriented web development tutorial and start there.
*(aside from the necessary HTML within which that javascript exists)
Well, in one sorta correct way, no, because you're not redesigning the browser, but nobody would say it like that. Web design includes a lot of code / markup used on the client (browser), and while your server is sending the browser the data, and that data is a mix of CSS, HTML, and JavaScript (as well as media like graphics and perhaps music), the browser is the piece of software doing the lifting on those pieces once it receives them. That data is selected by the server, so the logic for that is on the server, but this is what people would think of as "client design" in the context of a web application.
There are also a number of models (ways of arranging your programming designs) which would lead to cleaner code, and a lot of these would send a grouping of information (called a model) to the client (the browser) and then the browser would do some interpretation of how to use that data (called a view). This is a simplification since I don't think you're ready for a big dive into specific theories, but you could start with a JavaScript and HTML tutorial and then learn a server language:
Python is my favorite, but PHP is big as is Java (NOT to be confused with JavaScript), and I make my living doing C#. Really there are plenty of great choices.
One commentator recommended Node.js because you'd use JavaScript on the server with Node--just like for the client part (the response data you're sending to the browser). That's double duty, but I am partial to Python (as I said). Just pick something, and as you learn, you'll get to know what you like. If you change languages, it'll be easier to learn your second one.
I'm working on a project and I just need a holistic overview on how to go about it.
I'm going to use HTML/CSS canvas to make the game.
However, the game involves visualization of large amounts of data that is best served in a database. What I do not know how to do is:
Link my HTML/CSS game to a SQL database
Parse a text file to populate the database.
I don't have specific issues I just don't even know where to start? Some people have said AJAX? Others have said parse.com?
You have two options:
write a server-side application to serve data from a DB
use client-side HTML5 storage (such as local storage, WebSQL, IndexedDB, etc)
If you use the server implementation you will need AJAX to communicate with the server.
To do this you will have toove beyond JavaScript and learn server side programming. The good news is there are tons of awesome server side languages that make building websites easy.
If you come from a javascript background, ruby would probably be an easy transition. I'd suggest Sinatra.
If you are using SQL server, c# and asp.net are great choices that are very well designed, thou c# is very different from JavaScript as a language.
Like python? Web2py and Django are good.
Then there is PHP and java...
You would probably write an API in one of these server side languages, access it using Ajax to retrieve Jason and process it.
And don't bother with parse.com. write your own parser in the language of your choice. Its usually really easy, and instructive.
I think you already know a language you can use. How about javascript? Of course a real serverside language like Java or PHP would be better - maybe as already told: ruby but why not try it with node.js:
Node.js could be the first thing you may look at. (http://nodejs.org/)
It's really nice & well documented - there is also a big question about node.js with mysql: MySQL with Node.js which also works fine.
I've been looking at the API for Flattr, http://flattr.com/support/integrate/js , which has a cool way of accepting query variables for their JavaScript to load.
My question is, do most APIs use something other than JavaScript to accept these different variables for their services? EG:
Ruby on Rails
PHP
Python
Then these are parsed by the respective language and returned as outputted JavaScript to the requesting website?
Cheers
Javascript itself is totally capable of reading how it's embedded to the HTML it belongs to, by reading document.getElementsByTagName("script") and further parse/match their src attributes. Therefore, it's not a problem at all for it to further parse the query variables attached at the end, and dynamically (all in javascript, client side) load components within.
Any javascript libraries that allow you to pack the whole thing and deploy to your own web server should take this approach, since there's no server to handle the request anyways.
On the other hand, javascript libraries that are hosted on other sites that allow you to use (like YUI) MAY take the server approach like you mentioned.
In my personal experience, projects that I have worked on have used server side languages to deal with get params.
So a request might be /myjavascript.js?id=123123 The server side language would create the correct javascript for that request.
Keeping everything on the server side has the advantage of not allowing the user to see what is going on. If this isn't a problem for you, javascript is more than capable of handling different params.
In my experience it's fairly common that widgets embedded into others' sites gets their parameters by parsing them from their script tags. It makes the widget script static and self-contained and thus easier to distribute through eg. a fast CDN. Performance is important when you're going to convince someone else to add your javascript to their site as poor performance from the widget can make the entire site appear sluggish.
A better place to specify the parameters than query parameters would however be to specify them in the URL:s hash-part as that part isn't included when caches are checked and thus the script would have to be downloaded fewer times - which of course is good for performance, especially if the parameters might shift a lot.
With all the recent hype about JavaScript and HTML5 replacing Flash, I wanted to know - How would it be possible to protect client-side js code? Of course, it is possible to obfuscate it, but that would only make it a little harder. Also, for games which submit high scores to the server, wouldn't it be incredibly easy to modify those scores before they are sent to the server? I know even Flash files can be decompiled, but they can be obfuscated and flash decompilation is not as easy as modifying data in JS - could be done easily using a plugin such as Firebug. I'd like to know everyone's views on this.
Javascript, being parsed on the client, is never 100% safe. There will always be ways to find out what it does. A few days ago I've even seen a tool which unpacks packed javascript so the only thing you can really do is using "ugly" variable names (or actually, make a javascript packer transform your "good" variable names into short/ugly/nonsense ones)
To protect game results, you have to move some of the game logic to the server so the client cannot send arbitrary results.
Summarizing it: Don't put secrets in javascript code and don't trust anything coming from the client - no matter if it's from a form or generated/submitted via javascript.
You say that for game that sends high scores to the server it would be too easy to modify javascript and forge request?
Except for case, when you use some cryptography on the client, it is the easiest way to forge such request not even analysing the script but sending false request itself. Everything you send between server and browser can be easily viewed on computer, analysed and changed.