Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Im kinda new to the whole web applicaiton , and web sites world, but i started to programming and build my own web , using angular and i feel very comfortable with the idea of client side rendering , and the using of AJAX in angular($HTTP
/ $RESOURCE) , but i didnt use the "legacy" apporach to building web sites , because i jump on angular because it was sound like the best new !
but as i learned i got alot of obstacles in my path because lack of knowledage in the tradionial web site technoligoes and how all developes , i was like to know how the web sites has started , and what are the attuidue toward this world , and how does the server side rendering works , because as i understand all of this , is that simple i have templates , and the JS in the side client do all of the manipulation , add/delete divs etc , and there is no any connection to the server side about rendering the DOMS at all , only get information by using http or resources.. i want to know how does php server side works .
There are two different meanings for rendering, which is probably what confuses you.
Angular can take a piece of 'raw' information and 'render' the DOM elements required to display that data. The data could be, for example, a JavaScript object, which could be fetched as a JSON object from some API.
Rendering on servers vs client
In the more traditional approach, the HTML code comes 'pre-rendered' from the server. That means the server contains static HTML (just an HTML file that you could have typed in Notepad), or a server side script like PHP, which would "render" the HTML code with all the data in it. The server returns this HTML source code and the browser just "renders" it.
So "rendering on the server" means taking templates and data and combining them into raw source code.
And "rendering on the client" traditionally means taking that HTML source code and displaying it on the screen. Angular uses a third variation, which means doing DOM manipulation to "render" the data into the document. But I'll get to that later.
So server side rendering doesn't mean (now or ever before) that the actual display, the page that you look at, is rendered on the server. Not even the DOM is rendered on the server. The server just renders the textual HTML source code from the data it fetched, and the client (the browser itself) still generates the DOM and does the graphical rendering of the page.
And PHP therefore also doesn't respond to a button click directly. It only responds to HTTP requests, which can originate from an URL being typed in, a link being visited, a form being posted, or an AJAX request being performed.
HTML has built-in behavior
Traditional HTML has built-in behavior, which is why it could work without any client side scripting. A normal hyperlink is not clickable because of the script, but because the browser knows this element and its intention. So the logic of hopping from one page to the next is built-in in the browser itself. Same goes for forms. The browser knows that the data of a form should be sent to a server when you click the submit button. All you do in HTML is define (in the form attributes) what the URL is, the method, and which button to press to send the information. Again, no scripting needed.
Client side JavaScript can manipulate an already loaded page
The client side process is actually a two step process. First, the HTML source code is parsed and transformed into a DOM document, a list of in-memory objects containing information about the elements.
This document is then rendered (displayed) on the screen.
JavaScript (and that includes jQuery or Angular too), can work with these in-memory objects. It can bind events to them, so you can validate form input before sending it (saving the time of doing the round trip, server side checking, and parsing a complete response page), or respond to the click on any element. And you can even manipulate the objects themselves by just changing their contents, their appearance, removing them, or adding new ones.
So JavaScript's approach seems to be somewhat in between. You don't have to actually draw the changes you want, but you don't have to rely on HTML loading either. You have direct access to the objects, and any change you make to them automatically reflected on the display by the browser. So you can insert an extra element object and it will automagically appear on the screen.
And that is what makes JavaScript so fast and powerful. This approach is more direct than loading a big chunk of HTML from the server. So in the old days, you could just hop from one page to the next, and the whole page would need to be reloaded and re-rendered. With JavaScript, you could do small interactions, and with AJAX you could get pieces of information from an external source and display that information on the page without having to reload the entire page.
NB. AJAX by the way is also not very new. It was invented years ago by Microsoft to build a rich, web-based version of Outlook. The X in AJAX stands for XML, which is nowadays replaced by JSON as the notation of choice for communicating these pieces of information.
Angular 'hides' this DOM manipulation
Angular is just a framework that abstracts all this DOM manipulation that JavaScript can do. It lets you put markers in the HTML, and manipulate object data in JavaScript, and it will automatically put those together to update the page. This makes it easier to build a web application on a high level. You just have to worry about the design and the data, and much of the technicality to put them together is taken out.
Apart from that, Angular is not more than any other way of JavaScript DOM manipulation. It just lets you mess with the document that is currently loaded, something that a server side script cannot do.
However, in most cases the server (and the server side scripts) still plays an important role. It is this server side process that now 'renders' the JSON data that is fetched by your Angular application. That is, of course, unless you have some application that doesn't require any additional data to be loaded from anywhere else.
the html was invented for sharing linked documents in the web. It all began with static text stored on a server and delivered to the client rendered by the browser.
Then the html text was generated dynamically with programs/templates on the server(PHP,JSP, e.t.c). Javascript did the animation and some little client side programming(dom manipulation).
Then the Javascript for manipulating the dom was generated on the server which get delivered to the client and building the document client side.
when the user starts my app, there is a lot of data coming from a web service which is stored into the device´s database and then shown on the HTML-page using jquery`s .html() method. The problem is when the user selects another HTML page and then comes back, the data is not shown anymore, it has to be read out from the database again.
I know this isn't "rent a coder" but my question is: Is there a way to keep the data persistant on the HTML page even after the page is reloaded? Or do I have to pack everything into a single HTML document?
The solution could be to handle all navigation with AJAX, make your website a one page app and keeps things into cache. But i think this is a really big topic.
In any case a good Javascript MVC Framework like Backbone or Ember could help you.
I'm currently working on a concept for a heavy AJAX based web application.
The communication between client and server should be based on JSON, not plain HTML. So I was wondering how to store the templates for the seperate sections and how to get them by the javascript.
For example I have an multiple image uploading form. The user submits and with JSON response I get back title of the album and the src paths of the images. I want to show the complete photo stream from that JSON.
I never built something like I want know, so I'm trying to be prepared before actual programming comes in.
Are there good JS templating libraries? Can I load the templates after the AJAX call or do I need to load every template on the first page load?
Load the templates on demand. This saves you bandwidth, memory space as well as HTTP requests.
You can load them as plain HTML or as a bunch of templates, wrapped in JSON.
Cache them. You should have some sort of caching logic to check first your local cache (localStorage, a JS object on the page etc.) if the template exists. Otherwise, request it from the server.
I suggest using Mustache for templating. As for storage, I suggest using PersistJS. For caching logic, build one yourself.
I don't know any better way to ask this question than to give my situation.
I have a reader application that needs to be made, on the page it will have the Table of Contents on the left side and the actual content of the book on right. The TOC content shows chapters and sections within the chapter. The content on the right will only shows one of those sections at a time, no preloading the whole book. When you click on the section in the TOC, makes an API call to a separate server that holds all the book data and returns the HTML to be displayed in the content section.
I want to know if there is a way to make the application to use both unobtrusive javascript and active resource. Active resource would handle the interaction between the Rails Application and the server that holds the book content. The unobtrusive javascript would be the controller between the table of contents and the content on the right.
I guess what I'm wondering most of all, beyond just its possibility, is if I can integrate this is such a way that I don't need to make unnecessary api calls. Currently, I can't figure out how this would work without it making an api call to rails then making another api call to the book content provider.
Thanks for your help in advance!
#tab
Edit:
The Content model would be used to talk to the external API using ActiveResource. UJS would be used to call that model and display that returned content on the page. So the flow would sort of be like, click link myapp.com/book.js. This would go to the controller book#index that would initialize a variable that gets its data from the content model. The content model would use ActiveResource to make an API call to the external content server and would return html. The html that would be returned would be filtered back out and displayed on the page.
There will certainly be some caching, but the page itself will also need to be dynamic enough to allow editing of the content.
I was able to make a test program that used unobtrusive javascript to call a model using an API call.
It works the exact same as any other unobtrusive javascript setup, but instead the controller makes a call to the activeresource model. It acts no differently, I suppose I shouldn't be surprised.
I am wondering if there is anyway to grab the html that is generated from an ASP page. I am trying to pull a table from the page, and I foolishly used a static html page so I would not have to be constantly querying the server where this page resides while I tested out my code. The javascript code I wrote to grab to unlabeled table from the page works. Then when I put it into practice with the real page and found that the ASP page does not generate a viewable page with a jquery .get request on the URL.
Is there any way to query the page for the table I need so that the ASP page returns a valid page on request?
(I am also limited to using javascript and perl for this, the server where this will reside will not run php and I have no desire to learn ASP.NET to solve this by adding to the issue of proprietary software)
Use Perl's LWP module to query the ASP.NET page to get the required information. I would open the target page in a web browser while doing a WireShark trace so you can tell exactly how the browser is calling the page and getting the table information, and then perform the same call with LWP.
Is the page that is trying to get the table on the same domain? It needs to be. If not you have to use a proxy or XMLHttpRequest Level 2 access control headers.