Templates

Read more about the article Structure of Open Event Frontend

Structure of Open Event Frontend

In Open Event Frontend, new contributors always fall into a dilemma of identifying the proper files where they have to make changes if they want to contribute. The project structure is quite complex and which is obvious because it is a large project. So, in this blog, we will walk through the structure of Open Event Frontend. Following are the different folders of the project explained: Root: The root of the project contains folders like app, config, kubernetes, tests, scripts. Our main project is in the app folder where all the files are present. The config folder in the root has files related to the deployment of the app in development, production, etc. It also has the environment setup such as host, api keys, etc. Other files such as package.json, bower.json, etc are basically to store the current versions of the packages and to ease the installation of the project. App: The app folder has all the files and is mainly classified into the following folder: adapters components controllers helpers Initializers mixins models routes serializers services styles templates transforms utils The folders with their significance are listed below: Adapters: This folder contains the files for building URLs for our endpoints. Sometimes it happens to have a somewhat customised URL for an endpoint which we pass through adapter to modify it. Components: This folder contains different components which we reuse in our app. For example, the image uploader component can be used at multiple places in our app, so we keep such elements in our components. This folder basically contains the js files of all the components(since when we generate a component, a js file and a hbs template is generated). Controllers: This folder contains the controller associated with each route. Since the main principle of ember js is DDAU i.e data down actions up, all the actions are written in the files of this folder. Helpers: Many a time it happens that, we want to format date, time, encode URL etc. There are some predefined helpers but sometimes custom helpers are also needed. All of them have been written in helpers folder. Initializers: This folder has a file for now called ‘blanket.js’ which basically injects the services into our routes, components. So if you want to write any service and want to inject it into routes/components, it should go in here. Mixins: In EmberJS the Mixin class can create objects whose properties and functions can be shared amongst other classes and instances. This allows for an easy way to share behavior between objects as well as design objects that may need multiple inheritance. All of them used for the application are in the mixins folder. Models: This folder contains the schema’s for our data. Since we are using ember data, we need to have proper skeleton of the data. All of this goes it this folder. Observing this folder will show you some models like user, event, etc. Routes: This folder contains the js files of the routes created. Routes…

Continue ReadingStructure of Open Event Frontend
Read more about the article Handlebars.js used in Open Event Web App

Handlebars.js used in Open Event Web App

I recently started working in the Open Event Webapp project. One of the initial issues that I took up was a trivial UI bug. It was about adding sponsor names beneath sponsor images for better representation. The issue can be found here. On reading up the code base and exploring the project a bit, I came across a new template - Handlebars.js. Handlebars is a template which has it’s base with the Mustache templating language. One of the early discoveries that I made with Handlebars.js was the use of {{ }} and {{{ }}} and the basic difference between them. In general, all Handlebar.js expressions, just like in Mustache templating, are written between {{ }} or {{{ }}} type of brackets. That is how I learned to identify and distinguish Handlebars from core HTML, even though they are inter-linked. The official Handlebars documentation describes Handlebars expressions in the following way: “ A handlebars expression is a {{, some contents, followed by a }} ” Getting started with Handlebars.js Installation: For a basic Linux installation, type the following in your command line: npm install --save handlebars Including Handlebars in HTML: <script src="handlebars-v4.0.10.js"></script> Handlebars templates are often stored in .hbs files for better readability and accessibility. The Open Event Webapp project consists of a handlebars .hbs file for each of the tracks, events, rooms, schedule, sessions and speakers templates. These can be found here, that is under src/backend/templates folder. Difference between {{ }} and {{{ }}}:  Handlebars enables developers to print raw HTML tags or code with the help of {{{ }}}. On the contrary, if you don’t want to print HTML (which is usually the case), use {{ }}. For better understanding, let’s take an example. If our JS has an object that looks something like: $(function () { var templateScript = $("#title-template").html(); var temp = Handlebars.compile(templateScript); var Title= { “title”: <a> Handlebars</a> } Then, HTML of the following kind will help to distinguish the {{ }} and {{{ }}} brackets. <script id=”title-template” type=”text/x-handlebars-template”> {{title}} {{{title}}} </script> //the first line will contain an anchor tag with the name “Handlebars” //the second line will contain “<a>Handlebars</a>” Block helpers in Handlebars: Block helpers are identified by a ‘ #’ and they help to define and access custom iterators. Handlebars allow calling JavaScript functions with the help of ‘helpers’. It doesn’t allow direct JavaScript code in the HTML with templates. We can create our own helpers using Handlebars.registerHelper () in our JavaScript. We generally pass a function to the helper. A good example was provided in the Handlebars.js documentation: Handlebars.registerHelper('noop', function(options) { return options.fn(this); }); By default, Handlebars helpers take the current context as the context to pass(“this”). Other fields are overshadowed. Incase, we want to access one of the fields that is masked by the default “this” context, we have to use a path reference. Iterations using helpers: Helpers can be a great way  to iterate over lists or objects. I will demonstrate it with an example from the Open Event Webapp project.…

Continue ReadingHandlebars.js used in Open Event Web App