I apologize if this question is not specific enough, but I do need some help understanding this concept. I've been researching many Javascript libraries including JQuery, MooTools, Backbone, Underscore, Handlebars, Mustache, etc - also Node.js and Meteor (I know all those serve different purposes). I have a basic idea of what each does, but my question is mainly focused on the templating libraries.
I think the general idea is that the template will be filled by a JSON object that's retrieved from the server. However, i'm confused by how that JSON object is formed, and if it can go the other way to the backend to update the database. Please correct me if this is incorrect.
For a more solid example, let's say I have Apache running on Linux, and am using MongoDB as the database and python as my primary language. How do all these components interact with the templating library and each other?
For example, if I have an HTML file with a form in it and the action will be set to some python script; will that script have to retrieve the fields, validate them, and then update them in the DB? If it's MySQL I'd have to write a SQL statement to update it, but with Mongo wouldn't it be different/easier since it's BSON/JSON based?
And for the other example, let's say I have a view-account.html page that will need to pull up user information from the DB, in what form will it pull the information out and how will it fill it into the template? I'm guessing i'd have to have a python script that pulls the information from the DB, create a JSON object, and use it to populate the fields in the html template.
I am aware there are web frameworks that will ease this process, and please suggest any that you would recommend; however, I'm really interested in understanding the concepts of how these components interact.
Thanks!!
There are obviously many ways this can all work together, but it sounds like you have the (a) right idea. Generally the frontend deals with JSON, and the server provides JSON. What's consuming or providing those responses is irrelevant; you shouldn't need to worry that Mongo is your database, or that underscore is handling your templates.
Think of your frontend and backend as two totally separate applications (this is pretty much true). Ignore the fact that your frontend code and templates are probably delivered from the same machine that's handling the backend. Your backend is in the business of persisting data, and your frontend in the business of displaying it.
RE: Mongo using JSON/BSON; The fact it uses the same language as your frontend to communicate is a red herring. Your DB layer should abstract this away anyway, so you're just using Python dicts/tuples/etc to talk to the database.
I'm guessing i'd have to have a python script that pulls the information from the DB, create a JSON object, and use it to populate the fields in the html template.
Spot on :)
Related
As I can't orientate freely in the topic of building dynamic sites, it is quite hard to me to google this. So I'll try to explain the problem to you.
I'm developing a simple social network. I've built a basic PHP API represented by the files like "get_profile.php", "add_post.php", etc. with the POST method that is used to pass some data. Then I try to get the data using JS AJAX (php functions return it by JSON), which means I get all the data that I need to show on a page after the page is loaded. That causes decreasing of a page loading speed and I feel like this structure is really wrong.
I hope you'll explain me how to build a proper structure or at least give me some links to read. Thanks.
Populate the HTML with the (minimum) required data on the server side and load all other necessary data on the client side using AJAX (as you already do).
In any case, I would profile your application to find the most important bottle necks. Do you parallelize AJAX requests?
Facebook, for example, doesn't populate its HTML with the actual data on the server side, but provides the rough structure, which is later filled using AJAX requests.
If I understood your architecture right, it sounds ok.
Advices
Making your architecture similar to this allows you to deliver templates for the page structure that you then populate with data from your ajax request. This makes your server faster also since it doesn't have to render the HTML also.
Be careful with the amount of requests you make though, if each client makes a lot of them you will have a problem.
Try and break your application into different major pieces and treat each one in turn. This will allow you to separate them into modules later on. This practice is also referred as micro-services architecture.
After you broke them down try and figure user interaction and patterns. This will help you design your database and model in a way in which you can easily optimise for most frequest use-cases.
The way of the pros.
You should study how facebook is doing things. They are quite open about it.
For example, the BigPipe method is the fastest I have seen for loading a page.
Also, I think you should read a bit about RESTful applications and SOA type architectures.
I have the following scenario: I'm doing a publication lookup tool so users can find documents through a search field and filters. Right now we are working with a small budget, so all the data is stored in a json file (~60 records). If the project is successfull, we will have a server with a database and a couple of thousand records.
I want to develop all the lookup solution using breeze, so later I will don't have to make many modifications. The problem is that I can't find information about querying a json file directly (without a server).
Do you think that this is possible?
Actually, it is possible. But I can't think of a way that is as simple as setting up a simple server. That's like following off a log with Visual Studio. Maybe you're coming from a different environment? I'd like to know. Even there, it's usually pretty easy to spin something up with some kind of http API that can return JSON.
If you only have 60 records, I'm guessing this is a prototype that you're trying to stand up in a hurry. You're so much in a hurry that you don't even want to use a server ... which is kind of odd because you need something to serve the HTML, CSS, and JavaScript files, right?
You could do it with node.js / express very easily; almost as simple as setting up an express route that reads and returns the JSON file. But that still involves a server running somewhere (the client's own machine?) and you'd have to learn some elementary node.js
You can do it entirely with HTML and JS script files and no server other than the file system.
Off the top of my head, I think I'd begin by writing a custom Breeze ajax adapter that is actually a mock: no matter what you ask of it, it returns the JSON data in its entirety.
You call this once at application start to load the entities into an EntityManager cache. Then make all subsequent queries be local queries. You can set the EntityManager default query strategy to turn all queries into local queries by default.
No matter what you do, you'll have to define metadata to describe the entity types in your JSON data. I'm guessing you only have one type so that should be simple and quick.
You'll also have to do something to tell Breeze what kind of entity you're querying. Adding .toType('Foo'); to the end of your queries may be sufficient. You can always delve into the JsonResultsAdapter if you need something fancier at a lower level of the stack.
None of this is hard. But none of it is Breeze 101 either. You're not following what we've thought of as a typical application development path. Maybe we're missing something. I'll be curious to see if people can relate to your situation.
I'm working on a project and there is some battle between how some JS filtering should be implemented and I would like to ask you guys some input on this.
Today we have this site that displays a long list of repeated entries of data and some JS filtering would be nice for the users to navigate through. The usual stuff: keyword, order, date, price, etc. The question is not the use of JS, which is obvious, but the origin of the data. One person defends that the HTML itself should be used and that the JS should parse through it making the user's desired filtering. Another person defends that we should use a JSON generated in the server, and that JSON should be the data's origin.
What you guys think on this? What are the pros and cons?
As a final request, I would like you to be the most informative as possible since your answers will be used and referenced for all us in the company. (Yes, that is how we trust you!:)
The right action is matter of taste and system architecture as well as utility.
I would go with dynamically generated pages with JS and JSON -- These days I think you can safely assume that most browsers has Javascript enabled -- however you may need to make provisions for crawler (GoogleBot, Bing, Ask etc) as they may not fully execute all JS and hence may not index the page if you do figure out some kind of exception for supporting those.
Using JS+JSON also means that you make your code work so that support for mobile diveces is done client side, without the webserver having to create anything special.
Doing DOM manipulation as the alternative would not be my best friend, as the logic of the page control and layout is split-up in two places -- partly in the View controller on the webserver, and partly in the JavaScript -- it is in my opinion better to have it in one place and have the view controller only generate JSON and server the root pages etc.
However this is a matter of taste, and im not sure that I would be able to say that there is one correct and best solution.
I think it's a lot cleaner if the data is delivered in JSON and then the presentation HTML or view of that data is generated from that JSON with javascript.
This fits the more classic style of keeping core data structures separate from views. In this manner you can generate all types of views without having to constantly munge/revise the way you store, access and manipulate the data. You can even build classes and methods to develop a clean interface on your data that is entirely independent of how that data is displayed.
The only issue I see with that is if the browser doesn't support javascript and that browser is a desired viewer. In that case, you have to include a default HTML version from the server that will obviously not be manipulated and the JSON will be ignored.
The middle ground is that you include both JSON and the "default", initial HTML view of that data in rendered HTML. The view comes up quickly and non-JS browsers can see something useful. But, then any future manipulation of the view (sorting, for example) uses the JSON data and generates a new clean view from the JSON data. No data is then ever "parsed" from the HTML view.
In larger projects, this also can facilitate the separation of presentation from data manipulation so different people may work on creating HTML views vs. manipulate the data (like sorting).
I would make the multiple ajax calls to the server and have it return the sorted/filtered data. If you server backend is fast than it won't be very taxing and you could even cache the data between requests.
If you only have 50-100 items than it would be reasonable to send it all to the client and have javascript sort and filter it.
Some considerations to help make the decision
Is the information sensitive and unique? (this voids and benefit to caching in my first point)
What is the most common request that will happen and are you optimizing for that?
How much data is there? (tens of rows, hundreds, thousands, millions)?
Does you site have to work with JavaScript turned off? (supporting older browsers?)
Is your development team more comfortable doing this in the front-end or back-end?
The answer is that it depends on your situation.
I am currently looking for an intelligent best practice solution for the following problem. Within a web page, I want to make use of data that is currently organised in some MySQL tables.
Problem: I cannot access the database from the webserver, so I am not able to query the data using SQL. Therefore, I thought to transform the data into something JavaScript can handle (e.g. JSON) and perform all the operations on the data on client-side.
Doing SQL-like queries on an object will probably be kind of hard, even if those I need will probably be easy (simple SELECTs). Is there a elegant way to do that? Some nice little javascript library?
Thanks in advance for your ideas.
Best practice would (of course) be to put some kind of link (even if not a direct one) between the database and the web server.
For SQL in the browser, though, there's the TrimQuery library, basically a mini-SQL engine written in JavaScript for use on the browser. You would output the "tables" as arays of objects using JSON (as you indicated), and then query it via TrimQuery's SQL support.
But if you can't access the database from the web server, I assume you'll be making a mostly-static copy of the data as an admin procedure and placing it on the webserver. That being the case, you may well be better off determining your usage patterns in your web app and then formatting the data into useful objects as part of the DB->web server copy operation. But if you really need ad-hoc queries into the data, TrimQuery may be a route you could use.
You can try JSINQ:
http://jsinq.codeplex.com/
which is a Javsascript LINQ implementation. It allows to "query" json object with linq expressions (then in a sql-like way).
I am trying to get into web development, specially interested building the front-end, UI part of websites while learning JavaScript maybe with AJAX technology. (I have a UI, HCI background.)
However, I have absolutely no previous knowledge about server-end web development either. To my understanding, frameworks like Django seem to pretty good at this (correct me if I am misunderstanding).
So the question is: how much Django, or Rails do I need to know, if my interest is primarily the user interface part of web development. Can I just let somebody else do the back-end stuff?
Pardon me for my imprecise choice of terminologies.
You need to know a bit about the server side. Here's what you need to know.
If you have a heavy JavaScript website, you're likely going to want to pass information from the server to clients with JSON (JavaScript Object Notation). This is just a way to format data into strings that JavaScript knows how to convert to objects.
So, each of your server-side functions that send data to the client will return JSON. If you have someone writing the server-side for you, that's all you should have to know. You're JS functions will receive JSON, and then you deal with it.
If you have to write the server-side yourself, then that involves 1) getting data from database 2) formatting the data 3) converting to JSON.
I have open-sourced a commenting widget that accepts JSON messages, and gives examples of how you would set up the Django server code. Maybe it will help you: http://www.trailbehind.com/comment_widget/
You can make a career of front-end user interface development without know a ton about server code. You would do well though to have at least a rudimentary understanding of what happens on the server when you send it a request, where your data comes from, and what the life-cycle of a web page is. This assumes that you have the support of back-end developers. As you mentioned Ajax in your question that implies that you want your web sites to actually do something, which will require things to happen on the back-end (such as storage, manipulation of data, logging in a user, etc.).
As with all things, the more you know, the easier it will be to get what you want from the dedicated professionals. I would suggest that you learn about programming in general, not try an learn a language and framework. In particular, try to understand datatypes, server settings (like timeouts, post versus get, etc.), security and database interactions as they exist beyond JavaScript/ECMAScript. That way when a developer is explaining why they cannot do something you have requested or are offering alternatives, you are speaking the same language.
Yes and no. Typically what people think of AJAX, such as posting a comment on YouTube and seeing the comment appear instantly with a thank you message, for example, requires a server side language handling the requests, looking up data and returning results as html snippets, JSON data, or XML.
However, an AJAX call can be made to static resources as well. You could have an XML file or html snippet stored statically on your web server and have it loaded. The uses for this sort of static loading are generally fewer because if you already have the static html or data in file next to your regular page, why not just put that data directly into the page?
It helps to set up a local server and write a few lines of code to service your AJAX calls. You can do a lot of JavaScript learning with just a little back-end learning.
If you're new in web development you'd rather wait with Ajax and server-side languages until you've learnt the basics with HTML, CSS and JavaScript, especially if you want to mostly work with the user interface and not the funcionality.
As you said you can let somebody else do the back-end and focus on front-end (JavaScript, HTML, CSS).
You would need to communicate with the back-end developer when storing or processing data from the server.
As mentioned before back-end development knowledge would be useful but if you have someone doing it, it's not essential for beginning.