Security information portal. Creating a user interface component. Creating modular components

Difficult to learn. Although not even that. Ember.js concepts are difficult to learn and understand. It seems to me that any Ember.js training course should start with these words.

I am a developer working with Ruby on Rails (previously I programmed in .NET and Python). It was quite difficult for me to understand the magic that makes Ember.js work. I sometimes talk to other novice developers who have taken (or are trying to take) the Ember.js path - all their problems begin because they do not understand how this framework works.

Yes, on the one hand there is official documentation which describes in detail all aspects of this framework. But it lacks concept; for a novice developer, these are just fragments of information scattered randomly. From the documentation, for example, you can find out that we have controllers, models and views in our arsenal (controller, model, view). But in order to find out what they are responsible for and how they work, a novice developer is asked to first step on a rake a couple of dozen times. Plus, in addition to the controllers, models and views, Ember.js gives us a whole platoon of motley objects such as components, templates, router and paths (component, template, router, route).

But first things first. Let's start our Ember.js training by remembering that it is not an MVC (model-view-controller) framework; forget about it. Yes, Ember.js has controllers, models, and template views, but that’s where its similarity to MVC frameworks ends. Ember.js is a framework for writing applications that run in the user's browser.

Take a look at the following diagram, it describes in detail life cycle request to standard application written in Ember.js:

The states of your application are described using the address that you enter into the address bar of your browser. Using an address, you can save the state of your application or even share the state with other users, for example by sending a colleague a link to specific task in your bug tracker (the application shows the issue - this is its status).

So imagine that an application written in Ember.js receives information that the address is in address bar it was changed. The router intercepts this information and tries to figure out what to do with it next.

UFO (small lyrical digression): Ember.js works on two principles. Rules are above configurations (convention over configuration) and if Ember.js does not find the expected object, then it creates it itself based on its internal rules. Here it is worth noting the way the Ember.js code generator works. You're probably familiar with generators in other frameworks: they create a file with code and save it on your disk. Unlike other frameworks, the code generator in Ember.js creates an object only when it needs it and keeps it in memory. Once an object is no longer needed, Ember.js destroys it - this principle frees you from unnecessary boilerplate support.

Let's continue. Let's say the user requested the path /posts. Based on this request, the router will try to find the next object in the chain by its name - path. As you probably already guessed, Ember.js will look for an object of type Route called PostsRoute. The path in Ember.js is responsible for providing the model to the controller.

Ember.js will look for a model called PostModel. The model describes the structure of the data stored in your storage and the business logic of the objects. You can think of a model as a class from which Ember.js creates objects containing data. The data warehouse is just an abstract technical layer that sits between the model and your server. The storage stores data after Ember.js retrieves it from the server.

After the path takes the data, it gives it to the controller. Controller in in this case will be called PostsController. It is worth noting that there is no direct connection between the controller and the model; they don’t know about each other and the controller, in principle, doesn’t care what model you give it. The controller is just a data decorator - it processes it before giving it to the user.

Ember.js then takes the processed data from the controller and gives it to the template. But there is another object that sits between the controller and the template - the view. It is the view, which in our case will be called PostsView, that tells Ember.js which template to use for of this request. By rule, Ember.js will use a template called posts.

Feedback Users can interact with our application (poke buttons, drag elements and mess with the developer in other ways available to the user). Ember.js distinguishes between two types of user interaction with the application. The first is the so-called. native browser events - click, drag, drop, mouseEnter, mouserLeave and so on. The second way is events that have a name. The second type of event is basically triggered by a click on an element on which the given event is defined.

So what's the difference, you ask? Or you wanted to ask. The first type of event is handled exclusively by the view; Ember.js doesn’t care which button the user clicks, the main thing is the fact that the click happened. The second type is triggered only after a specific element is clicked and is processed by the controller. If the controller cannot handle the event, Ember.js tries to handle the event on the Route Object before reporting an error.

Template Structure Things start to get even more confusing once newbies learn that Ember.js templates can be nested with other objects, thereby triggering the whole cycle all over again. There's really nothing wrong with that.

On this moment You already know that a template has a context - a model, a controller, and a view.

Let's start with partial templates. This is the simplest object you can put into your templates (although object is probably too big a name for partial templates). Ember.js will simply take the template you specify and present it in the parent template; in this case the context of the parent will be used - i.e. in a partial template you will have access to the model, controller and parent view. Simply put, all events will be handled by the parent's view and controller.

The view and the component are quite similar to each other (in truth, the view is parent class component). The view and component both have their own own template. Behind the view and component is its own object. The difference is two key points. Firstly, event handling - the component itself processes named events and the view simply gives them to the parent template, which in turn gives them to the controller. Secondly, the environment - the component is completely isolated and can only work with objects that you give it; the view in turn has access to all objects available to the parent template. From the perspective of the parent template context, the view has access to the model and controller but has its own own view. The component is more isolated and does not have access to anything.

The last element is render. It is the most complex of all the objects available in templates. When you call render in a template, you need to provide it with two parameters - the name of the template and the model. Ember.js will find the template and based on the name of the template, it will find the controller and view. It will then give the controller a model and after the controller has processed the model, Ember.js will insert it into the template. Simply put, with the help of rendering you can assemble several independent templates with completely different contexts on one page; the render does not have access to the parent template's context (the render has its own context instead) and all events will be handled by the view and render controller.

I hope you enjoyed the theoretical introduction to Ember.js. If Ember.js interests you, then you can continue to get acquainted with it by reading the official

Translation

These days, complex Javascript applications can be seen everywhere. Over time, they become more and more complex and it is no longer acceptable to simply write a chain of callback functions in jQuery. Javascript programmers are gradually learning that regular developers have known for decades. Organization and efficiency can play an important role in development. Thus, Javascript MVC frameworks like Backbone, Knockout and Ember have emerged to fill the void between beginners, intermediate and experienced developers. They offer different possibilities and functionality that suitable for different people people, depending on their needs.

I think I'm pretty good developer... far from the best, but I can work with existing technologies, which I use in my developments. I kept an eye on these frameworks and Backbone and Ember suited me. I played around with Backbone, even bought a video tutorial on it. He's good, but I still find it difficult to force myself to think like him. I heard about Ember just a few months ago and it's just going from strength to strength. It offers a lot of the features that I need and I decided to see how it suits me. Ember provides several key features that I find very attractive, the main one being data binding. You simply create a variable, and when the value of that variable changes, whatever part of your application that monitors that variable is updated. This would find its use, for example, in chats, etc.

For now main drawback Ember compared to Backbone is that the latter has many tutorials, articles and finished projects on Github. While on Ember you can find very few materials on the net that immediately show all its internals, but miss the very basics. So my goal is to write a tutorial that will help you start using Ember now. Well, among other things, I am writing this article to consolidate my own knowledge.

Ember.js is built on MVC (Model-View-Controller) architecture and you just have to divide your code into 3 parts:

M = Model – similar to an array. This is where the data that will be used by your application is stored.
V = The View is the visual part of your application - forms, lists, etc.
C = Controller – Think of the controller as a traffic controller. It manages the interaction between other parts of the application. When the user clicks on the button, the controller determines which view should be loaded, which in turn determines which model to use to save the data.

Let `s start? To get started, download the Ember.js Starter Kit. Extract it to a directory that can be accessed by your web browser. Open index.html and js/app.js in your favorite text editor. In app.js add the following line:

Welcome = Ember.Application.create();

Congratulations! You've created your first Ember app! Open index.html in your browser and be delighted with your new site. Oh wait, there’s nothing there... what do you think about this? Nothing appeared except the title and that's great. All that has happened is that Ember has created an application that you will use throughout the tutorial. Some developers prefer to call this a namespace. This simply means that all other parts of your application will begin with the name you chose. This helps avoid variable name conflicts and keeps everything in order.

There's one thing that most jQuery developers are very used to - good old document.ready . Ember offers something similar by accepting an optional object in the create method. Add the code, reload the page and you should see a congratulations message. Pat yourself on the head...you deserve it!

Welcome = Ember.Application.create(( ready: function())( alert("You've done it!"); ) ));

The next thing we need to do is add a Model. Each Ember application can have many models and each of them is a unique data type. In some frameworks, a model is represented as a class. Basically, it's just a structure that tells us how to work with this object. Let's create a model for some of my favorite books.

Welcome.Book = Ember.Object.extend(( title: null,

The next thing we need is a controller. By the way, in addition to controlling the application, controllers in Ember also transfer data from the model to the view. Here's a simple controller in Ember:

Welcome.booksController = Ember.ArrayController.create();

Not exactly the same as creating a controller, but this creates an ArrayController that contains an array. This is where information about our books will be stored. It's there, you just don't see it. You can explicitly specify the contents of the array, or, for example, fill it. This is done by passing an optional object to the create method:

Welcome.booksController = Ember.ArrayController.create(( content: ));

Now we have a model and a controller, all that remains is to write the view. Remember when I said that the view is the visual part of your application? This means it will be located in the index.html file. Let's write our presentation first and then discuss it. Just below the H1 tag, add the following:
((#view Ember.Button target="Welcome.booksController" action="loadBooks")) Load Books ((/view)) ((#collection contentBinding="Welcome.booksController" tagName="ul")) ((content .title)) - ((content.author)), ((content.genre))((/collection))

One of the great things about Ember is that it comes with a built-in template engine called Handlebars. Templates are essentially the core magic of Ember. Typically in templates you surround a variable with some string. In Handlebars this is 2 curly braces.

Ember began life as a SproutCore library developed by Apple as the core for their online applications such as Mobile Me. SproutCore also included a set of widgets not found in Ember. Ember only includes provisioning for form elements because they can be very dynamic. In the case of our template, or view, we use Ember buttons. This allows him to do all the hard work for us. It takes a target (in our case, booksController) and an action. So when someone clicks the button, Ember will work with the loadBooks method of the Welcome.booksController object.

The second part is a little more difficult, but I'm sure you can figure it out. In Ember, a collection is simply a pointer to a group of data, in our case again Welcome.booksController . At the beginning of the article, I wrote that linked data is one of the reasons I was interested in Ember. And here we can see all its power. Content simply points to the content variable in the booksController , while Binding is the magic dust. Adding Binding to the end of most attributes tells Ember that you want to do two-way binding. You change the value on one side and the other will update. Finally, collections allow you to set base tag, in our case it's simple bulleted list(UL tag).

By the way, the # and / symbols tell Handlebars that this is only a part (block) of the view.

Inside the collection is the “meat” of our templates. Notice how we mix HTML and tags inside our templates. Convenient, isn't it? Another subtlety is that Ember does not need to explicitly specify opening or closing tags for a list. It will add them automatically because it knows we are using a bulleted list. Launch the application and you will see a lonely button that needs friends. Clicking the button makes it miserable because we don't have a loadBooks method yet. How about adding it and loading some data?

Welcome.booksController = Ember.ArrayController.create(( content: , loadBooks: function())( var self = this; $.getJSON("data/books.json", function(data) ( data.forEach(function(item) ( self.pushObject(Welcome.Book.create(item)); ) ));

Remember when we said that models can contain arbitrary methods? Everything in Ember can contain arbitrary code, including the ArrayController. Now, when you load your page and click the “Load Books” button, the loadBooks method will be called, which will load some of my favorite books. That's all for this simple example. I hope you enjoyed it and give Ember a chance. You can

These days, complex Javascript applications can be seen everywhere. Over time, they become more and more complex and it is no longer acceptable to simply write a chain of callback functions in jQuery. Javascript programmers are gradually learning what regular developers have known for decades. Organization and efficiency can play an important role in development. Thus, Javascript MVC frameworks like Backbone, Knockout and Ember have emerged to fill the void between beginners, intermediate and experienced developers. They offer different features and functionality that will suit different people, depending on their needs.

I consider myself a pretty good developer... far from the best, but I can work with existing technologies that I use in my developments. I kept an eye on these frameworks and Backbone and Ember came up for me. I played around with Backbone, even bought a video tutorial on it. He's good, but I still find it difficult to force myself to think like him. I heard about Ember just a few months ago and it's just going from strength to strength. It offers a lot of the features that I need and I decided to see how it suits me. Ember provides several key features that I find very attractive, the main one being data binding. You simply create a variable, and when the value of that variable changes, whatever part of your application that monitors that variable is updated. This would find its use, for example, in chats, etc.

At the moment, the main disadvantage of Ember compared to Backbone is that the latter has a lot of tutorials, articles and ready-made projects on Github. While on Ember you can find very few materials on the net that immediately show all its internals, but miss the very basics. So my goal is to write a tutorial that will help you start using Ember now. Well, among other things, I am writing this article to consolidate my own knowledge.

Ember.js is built on MVC (Model-View-Controller) architecture and you just have to divide your code into 3 parts:

M = Model – similar to an array. This is where the data that will be used by your application is stored.
V = The View is the visual part of your application - forms, lists, etc.
C = Controller – Think of the controller as a traffic controller. It manages the interaction between other parts of the application. When the user clicks on the button, the controller determines which view should be loaded, which in turn determines which model to use to save the data.

Welcome = Ember.Application.create();

Welcome = Ember.Application.create(( ready: function())( alert("You've done it!"); ) ));

Welcome.Book = Ember.Object.extend(( title: null, author: null, genre: null ));

Welcome.booksController = Ember.ArrayController.create();

Welcome.booksController = Ember.ArrayController.create(( content: ));

((#view Ember.Button target="Welcome.booksController" action="loadBooks")) Load Books ((/view)) ((#collection contentBinding="Welcome.booksController" tagName="ul")) ((content .title)) - ((content.author)), ((content.genre))((/collection))

The second part is a little more difficult, but I'm sure you can figure it out. In Ember, a collection is simply a pointer to a group of data, in our case again Welcome.booksController . At the beginning of the article, I wrote that linked data is one of the reasons I was interested in Ember. And here we can see all its power. Content simply points to the content variable in the booksController , while Binding is the magic dust. Adding Binding to the end of most attributes tells Ember that you want to do two-way binding. You change the value on one side and the other will update. Finally, collections allow you to set a base tag, which in our case is simply a bulleted list (UL tag).

By the way, the # and / symbols tell Handlebars that this is only a part (block) of the view.

Remember when we said that models can contain arbitrary methods? Everything in Ember can contain arbitrary code, including the ArrayController. Now, when you load your page and click the “Load Books” button, the loadBooks method will be called, which will load some of my favorite books. That's it for this simple example. I hope you enjoyed it and give Ember a chance. You can download the example source code on Github.

Wait another minute. If you're like me, you still have questions. Many questions. I wrote this article because I had questions and it took me hours to find answers. Most of the questions I had were actually answered in this article. If you still have questions, then you can. If I don't know the answer, I will find it and answer you.

At the moment there are a huge number JavaScript libraries, designed to manipulate the DOM. However, when it comes to the need to build a single-page application, many frameworks are blown away.

It's not that libraries like jQuery can't be used to build complex single-page applications. They were simply created for other purposes and can only manage states, interfaces and routes using special plugins. Agree that this is not the most The best decision. In my opinion, to solve a problem you need to use the appropriate tools.

Ember.js is exactly what we need when it comes to complex single-page applications. With its help, you can create complex applications. The developers based it on the ability to work according to the MVC principle.

The main goal of these articles will be to get to know Ember.js, its various aspects and capabilities. Today we will start with general concepts, but in the future we will begin to implement examples.

Let's get started!

Basics

The first thing you need to understand is that Ember.js is a framework for creating non-traditional websites. Frameworks like jQuery and Mootools are more suitable for classic websites. Applications built on top of Ember.js are more like desktop applications.

As I mentioned earlier, Ember.js uses MVC as its code distribution system. If you know nothing at all about MVC, then you need to read the most simple article, where the work according to this scheme is described. If you have used Backbone.js before, then Ember.js will not be difficult for you to understand.

Templates are very common in Ember.js and are powered by the Handlebars library. With its help, we can write templates to generate dynamic HTML code. Using Ember.js, we will transfer data to the template. Below is an example template for displaying users in an unordered list:

Hello, ((name))!

The #each keyword means a regular loop that will loop through the records from the people variable. With expressions like ((name)), we will extract necessary information. More complex examples, we'll look into it later.

Handlebars is a really good template engine that can be used separately from Ember.js. You can find more information on their official website.

Setting up Ember

Ember.js is powered by other libraries, so you will need to include jQuery and Handlebars. Stop! Didn't I earlier say that jQuery and Ember are intended for different purposes? Yes, but in reality the situation looks a little different: the development team decided not to reinvent the wheel. They chose jQuery to do what it does best: manipulate the DOM. They were guided by similar thoughts when connecting Handlebars.

In fact, you don't have to go to different sites to get the library links you need. You can find everything you need on the Ember.js page on Github. Download Starter-kit and get:

Ember 1.0 RC1
Handlerbars 1.0 RC3
jQuery 1.9.1

All these files are immediately distributed into folders. For our application, it is best to create own file. Let's call it app.js:

Ember Features

Before writing any code, it's better to first know the basic features of Ember.js

Templates

As I said earlier, when working with Ember, templates are often used. Here is an example of connecting a template:

((firstName)) ((lastName))

We write all this directly to HTML document. Then, when the page launches, Ember will start its mechanisms and all the templates will be filled with information. In this example, we print the values of two variables: ((firstName)) and ((lastName)).

Routes

The router helps react to changes in application state and connect necessary resources, depending on the page navigation. Possible operations: extracting data from the model, passing it to controllers, views and templates.

Routing is accomplished by creating routes for specific parts of your application. Routes define sections of your application, as well as the urls associated with them. The URL is the key object for determining what state the application needs to display to the user.

App.Router.map(function() ( this.route("about"); // Takes us to "/about" ));

The behavior of the route (transferring data from the model) is defined using a global Ember object that is responsible for navigating the application. An example of extracting data from a model looks like this:

App.EmployeesRoute = Ember.Route.extend(( model: function() ( return App.Employee.find(); ) ));

As soon as the user goes to the “/employees” address, the router will make a call to the model and pull out a list of employees.

Models

Models are intended for acceptance or return object representations data that is used in our application. It could just be an array or a JSON response from a third party PHP file. The Ember Data library provides a good API for mapping and updating data.

Controllers

Controllers are designed to store objects and interact with models. They act as intermediaries, accessing the model and passing data to views and templates. Templates must always be connected to the controller.

You should be well aware that the controller is designed to distribute the data it receives from the model.

In controllers, you can record other data that the application needs, but should not be sent to the backend for storage.

Representation

Within Ember.js, views are designed to track user events and transform them into what you need to make your application responsive. If the user clicks the button to delete a contact, the view will track this event and tell the application what state it should go to.

Naming rules

Using Ember.js, you can reduce the amount of code by setting up an object naming system for yourself. Depending on how you name the route, the name of the controller, model, view, and template will depend. For example, we created the route “employees”:

App.Router.map(function() ( this.resource("employees"); ));

I'll name my components like this:

Route: App.EmployeesRoute
Controller: App.EmployeesController
Model: App.Employee
View: App.EmployeesView
Template: employees

This naming convention is convenient for several reasons. First, we immediately see the semantic relationship between the components. Secondly, Ember will be able to independently create objects that will be missing. All this is possible when the application is initialized:

Var App = Ember.Application.create();

One line defines the relationships between controllers, objects, views and templates:

Route: App.ApplicationRoute
Controller: App.ApplicationController
View: App.ApplicationView
Template: application

When navigating to “/employees”, Ember activates other resources:

App.EmployeesRoute
App.EmployeesController
employees template

If there are no such objects in the application, Ember will create them, but will not output anything until you create a model that returns the data for output. This is why component naming conventions are very important. It will help Ember determine which resources to connect without manual configuration.

What's next?

That's all for today. We got acquainted with Ember.js and its components. In the next parts of this series of articles we will deal practical use this library and in practice we will try much of what Ember provides us.