So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!
Related
I'm an android developer and about two years and recently I've been thinking about building web applications. So I started researching about spring boot and everything is great. Then, I came across this thing called template engines (thymeleaf) which by definition separate your code from presentation.
What is confusing me is how can a backend server have html? should the presentation be handled by html, css and javascript in the front end? I even saw tutorials where they actually type in html code in their controller as return values.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
THank you
the frontend will manipulate this data
What front end? You mean the JavaScript code in the HTML page? Where did that come from? Oh yeah, the server.
It is the server that serves the HTML pages to the client, as well as any .js and .css files.
The server could provide static pages, and anything dynamic is handled by JavaScript. Or, the server could dynamically build the HTML page, using ... you guessed it ... a template engine.
You generally don't want JavaScript to build the page initially, just to use JavaScript for handling any dynamic behavior. Some pages don't even need any dynamic behavior.
Unless of course you're thinking about single-page applications (SPA), where there is only one root HTML page, and everything else is built client-side with JavaScript and AJAX calls, but most web applications are not SPAs.
Thymeleaf replaces JSP by providing HTML pages using a template engine. The controller requests the HTML file and Spring Boot provides that template after building it using the Model provided.
Thymeleaf is great because it allows you to rebuild templates on the fly. Lets say for example you're showing a users points to them on the front end, but maybe the points increase or decrease.
What you can do is build the template in the background using a Model. The Model reference is magically provided to the template provided which parses it.
#RequestMapping(...)
public String request(Model model) {
model.put("points", 5);
return "my-template.html"
}
Then use the Thymeleaf language to provide your object to the HTML file to be processed in the engine during runtime.
<html..>
<head>...</head>
<body>
<h1 th:text="${points}"></h1>
</html>
Spring Boots Template engine will build this in the background and present it to the user, but it will show the actual points to the end user! Hope this helps a tiny bit.
I know this question has been answered pretty effectively so far, but I want to add my two cents in as I work with Thymeleaf often.
The easiest way to think about a template engine is that it allows some dynamic development of html based on information passed to it by the controller method. This allows you to put logic in that normally wouldn't exist, or say display a certain section if a user is perhaps logged into admin.
If web pages were houses, html is the frame, css is the walls, Javascript is the lights and electricity, and a template engine would pretty much just be the architect designing the plans on the fly before the frame was built based on desires of the buyer of the house (user inputs).
OK, newer Apps and websites may just load/boot/open once and then pull or push data via AJAX requests, this is good, it saves traffic and it is fast.
But it has not always been like this and some Frameworks still don't build everything on small requests. Spring in Java or Symfony in PHP are MVC Frameworks and use template engines to build pages. This may sound a little outdated but there is still a lot of websites using this.
And if you build a web app for a customer with slow PCs or other devices and the page contents are performance heavy you might want to do as much work as possible on the server so that the user does not have to wait for long. And also you can cache the rendered pages. There is even server side rendering of react pages to e.g. make the initial page load faster...
With Java and Spring I did just use JSP I don't know thymeleaf. Just use what you like and maybe what is most supported/documented.
And building websites like this does not mean you cannot use AJAX, but if you use templates you need to think about what makes sense.
What is confusing me is how can a backend server have html?
The "back end" must have HTML, because that's what's delivered to, and rendered by, the client.
It may just be that the back end "server" is just a CDN delivering, say, an HTML/JS SPA, but there's still something delivering content to the browser.
That said: server-side rendering is still a thing, and has had a resurgence lately--a React app may have its initial rendering done on the server so again the client gets a page rendered with both HTML and associated data, and then starts acting like a normal SPA.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
Because something needs to run the JS to access those APIs.
Some history:
Browsers used to suck. JS used to be a neat add-on, sites were relatively static, and essentially all rendering was done on the server. The back end would get data from wherever it got data from and generate complete HTML pages, and there was little happening on the client side other than some form fields, maybe some validation, and that was about the extent of it.
I'm currently looking at putting together a website with ASP.NET MVC that gives the viewer the ability to move around from page to page (view to view) without it being refreshed each time.
The way I'm currently thinking of doing it treating views as 'areas' (or mini master pages) and using partial views in the place of views. I'll then switch the partial views in and out as needed using AJAX calls to the controller (which will load the partial view) and JavaScript.
I feel like I could have explained this better but I'm not quite sure how to phrase it, so hopefully this diagram will help somewhat:
Here's a look at my current folder structure. Index.vbhtml is acting as the aformentioned 'area'.
Views/
Accounts/
Partials/
ViewAccount.vbhtml
CreateAccount.vbhtml
Index.vbhtml
I'm loading my partials views in using a JS function along the lines of: nav.navigateToView("Action", "Controller")
For example: nav.navigateToView("ViewAccount", "Accounts" will load the ViewAccount.vbhtml partial view onto my page.
What I'd like to know is: Is there currently a defined method for doing this, or perhaps a library I can use to aid me? If not, could you give some helpful advice on how to achieve this? I'm not convinced the method I've described will be adequate.
Apologies if this question has already been asked! I've had a tough time trying to find anything relevant on this topic. Am I missing something simple?
Thanks,Aaron.
From the description you have provided, I think what you are describing is a single page application (SPA). Needless to say, there is a bunch of articles available so sorry for not being more specific.
One approach would be to use Angular.js which is a Javascript framework, described here and here (and thousands of other sites).
ASP.NET Single Page Application (SPA) helps you build applications that include significant client-side interactions using HTML 5, CSS 3 and JavaScript. It’s now easier than ever before to getting started writing highly interactive web applications.
Please see this site.
I'm completely new to Angular. I currently have a Django app that acts as a JSON-serving API (using Tastypie) and also serves up a few static pages for things like user registration, invitations, and viewing events.
Eventually, we're going to have a webapp that interacts with the Django API in all kinds of ways and makes total sense as a single page web app written in Angular (or something similar). However, as it stands right now, I just want to separate out these relatively self contained pages (mostly forms, confirmation pages, and event viewing pages) into their own app.
Since eventually everything is going to be in Angular, my thought is that I might as well start making these things in Angular, even though Angular's architecture doesn't seem very tailored to small forms and other things that will likely just be linked to from email messages.
Does it make sense to build these things out using Angular, setting up the necessary service/factory calls, making controllers for the form/event viewing pages, etc.? And if so, what's the best architectural decision in terms of modularity? Should every part of the app that "stands alone" (i.e., doesn't really interact with other parts of the app) be a separate Angular module?
If they are literally separately loaded pages and you eventually plan to have these pages be part of a single page angular application, Than what I would do is:
Create angular modules that have the same variable name for all seperate pages so like var app = angular.module('blah',[])
I'd link all my controllers for each individual pages at the time to their specific "app" module app.controller('blahCtrl',function(){}); ...
You boot these modules separately on their respective pages for the
time being
then when you do make the transition to moving it to one module where everything is in one page you can simply port the controllers because they will all belong to a module represented through the variable "app"
Starting a new Ember app and was prepared to follow token authentication type structure for authentication in the restricted API routes but was then told we need to not show any of the javascript (or as absolute little as possible) before authentication. This has me a little puzzled given single page javascript apps.
I'm using the, very helpful, ember-app-kit which has great tools that compile everything down to a minified and obfuscated single javascript file, which I thought was good enough for security, but apparently its not.
Having the entire app loaded once, and even in a single compiled/minified js file, what is best practice for "hiding" some of the javascript and only loading after authentication?
I had one thought of my own and have found another potential:
A ) coming from rails, I thought I could just build a very thin rails app that handles authentication in a server side view that doesnt load any of the app js. Then on successful authentication, transition the user to a view that loads all of the JS for the app and go from there.
B ) I found some talk of new functionality in ember-data that allows you to async load javascript files in the models. This seems like it could work but also seems very complex and I'm not sure if It'll totally work cause they want to hide not only models but things like app routes (basically everything but login)
I have done option A in rails: authenticate the user on the server and then forward them to a page containing the actual client Ember application. It will be far simpler than trying to dynamically load the app on the client side. Simple is usually best.
Ok I am trying to get my head round this whole backboneJS thing. I understand you have to separate your site into modules and break each module down into Models, Collections and Views like described in this example.
My JS file structure currently looks like this:
-js
-application.js
-lib
-jquery.min.js
-backbone.min.js
-underscore.min.js
-modules
-newsfeed.js //activity feed
-file.js // page to upload files to
-members.js // page that show other members of group
//-general-site-logic.js??
I have two questions:
Should all application logic be controlled from BackboneJS? If not then where should this separate logic reside in my application structure? Surely backbone can't control all of your client-side activity. What about activity that doesn't involve any collections?
Should I be using RequireJS to manage modules when using BackboneJS or not? I have found this example but it seems to complicate the already confusing concepts of Backbone even further.
I am about to embark on a very javascript heavy app and really want to get this right before my code begins to mushroom!
The great thing about Backbone is that it is just a collection of useful pieces that you can put together however you want. You can organize it however you want.
Surely backbone can't control all of your client-side activity.
Why not? I have a rather large client-side app where all of the code (aside from jQuery plug-ins and such) is written using Backbone constructs (Views, Models, Collections, Routers).
In our case, we are using Rails, so we don't need to worry about requiring other JS files. We break the project up into many js (coffee) files and the "asset pipeline" merges it all into one js file for us. (we do need to tell the asset pipeline some ordering rules, however... models before collections, collections before views, etc)
When we do this, we have the following setup:
-assets
-javascripts
-backbone
-collections
-helpers
-models
-routers
-templates
-views
-bootstrapper.js
Of course, that is how WE do it. For larger projects, I always know where to find my components and we create subfolders within for our different sub-views. For instance:
-views
-people
-people_list.js
-people_item.js
-orders
-order_list.js
-order_item.js
-order_form.js
On smaller projects, however, you can put everything in one JS file and it wouldn't be a problem. Most toy examples are laid out this way.
An intermediate layout might be something where you just separate your models from your views like this:
-models.js // models and collections
-routers.js
-views.js
I guess what you should get from this is: "Organize however you'd like". Do what makes sense for the project size and your team's understanding of organization.
Backbone provides structure. It isn't opinionated, however, to how that structure is designed.
If it helps I have a bootstrap, project starter integrating backbone.js, coffeescript, sinatra, jasmine and skeleton.
It'll get you started with project structure and save you time integrating the tech stack. Also uses skeleton css for responsive design.