Step by step guide for Beginners in Web Development for Open Event Frontend

Originally the frontend and backend of the Open Event Server project were handled by FLASK with jinja2 being used for rendering templates. As the size of the project grew, it became difficult to keep track of all the modifications made on the frontend side. It also increased the complexity of the code. As a result of this, a new project Open Event Frontend was developed by decoupling the backend and frontend of the Open Event Orga Server. Now the server is being converted fully into functional API and database and the open event frontend project is primarily the frontend for the Open event server API where organisers, speakers and attendees can sign-up and perform various functions.      The Open Event Frontend project is built on JavaScript web application framework, “Ember.js”. To communicate with the server API Ember.js user Ember data which is a data persistence module via the exposed endpoints. Suppose if you’re coming from the Android background, soon after diving into the web development you can relate that the web ecosystem is much larger than the mobile one and for the first timers it can be difficult to adopt with it because of the reason that in web there are multiple ways to perform a task which can be restricted to very few in the case of Android. For web applications, one can find that much more components are involved in setting up the project while in android one can easily start contributing to project soon after compiling it in Android Studio. One thing which is relatable for both the android and web development is that in the case of android one has to deal with the varying screen sizes and compatibility issue while in the web one has to deal with adding support for different browsers and versions which can be really annoying. Now let’s see how one can start contributing to the Open event frontend project while having no or a little knowledge of web development. In case if you’ve previous knowledge of JavaScript then you can skip the step 1 and move directly to another step which is learning the framework. (Here all the steps have been explained in reference if you’re switching from Android  to Web development.) Step 1. Learning the Language - JavaScript Now that when you’ve already put your feet into the web development it’s high time to get acquainted with the JavaScript. Essentially in the case of Ember which is easy to comprehend, you can though start with learning the framework itself but the executables file are written in JavaScript so to write them you must have basic knowledge of the concepts in the language. Understanding of JavaScript will help in letting know where the language ends and where the framework starts. It will also help in better understanding of the framework. In my opinion, the basic knowledge of JavaScript like the scope of variables, functions, looping, conditional statements, modifying array and dictionaries, ‘this’ keyword etc. helps in writing and understanding the…

Continue ReadingStep by step guide for Beginners in Web Development for Open Event Frontend

Adding dynamic segments to a route in Open Event Frontend Project

When we talk about a web application the first thing comes up is how to decide what to display at a given time which in most of the application is decided with the help of the URL. The URL of the application can be set either by loading the application or by writing the URL manually or may be by clicking some link. In our Open Event Frontend project which is written in Ember.js, an incredibly powerful JavaScript framework for creating web applications, the URL is mapped to the router handlers with the helper of router to render the template for the page, to load the data model to display, to navigate within the application or to handle any actions within the page like button clicking etc. Suppose the user opens the open event application for the very first time what s/he will see a page containing the list of all the events which are going to happen in the near future along with their details like event name, timings, place, tags etc. If the user clicks one of the events from the list, the current page will be redirected to the detailed specific page for that particular event. The behaviour of changing the content of the page which we observed during this process can be explained with the help of the dynamic segments concept. The dynamic segment is a section of the path for a route which changes based on the content of a page. This post will focus on how we have added dynamic segments to the route in the open event frontend project. Let’s demonstrate the process of adding the dynamic segments to the route by taking an example of sessions routes where we can see the list of all the accepted, pending, confirmed and rejected sessions along with their details. To add a dynamic segment, we need to have a route with path which we add to the route definition in app/router.js file this.route('sessions', function() { this.route('list', { path: '/:sessions_state' }); }); Dynamic segments are made up of a : followed by an identifier. Ember follows the convention of :model-name_id for two reasons. The first reason is that routes know how to fetch the right model by default if we follow the convention. The second is that params is an object, and can only have one value associated with a key. After defining the path in app/router.js file we need to add template file,  app/templates/events/sessions/list.hbs which contain the markup to display the data which is defined in the file, app/routes/events/sessions/list.js under the model hook of the route in order to display the correct content for the specified option. Code containing the markup for the page in app/templates/events/sessions/list.hbs file <div class="sixteen wide column"> <table class="ui tablet stackable very basic table"> <thead> <tr> <th>{{t 'State'}}</th> <th>{{t 'Title'}}</th> <th>{{t 'Speakers'}}</th> <th>{{t 'Track'}}</th> <th>{{t 'Short Abstract'}}</th> <th>{{t 'Submission Date'}}</th> <th>{{t 'Last Modified'}}</th> <th>{{t 'Email Sent'}}</th> <th></th> <th></th> </tr> </thead> <tbody> {{#each model as |session|}} <tr> <td> {{#if (eq session.state "confirmed")}}…

Continue ReadingAdding dynamic segments to a route in Open Event Frontend Project

Using semantic UI components in Open event frontend project

When we talk about reusability in terms of web application framework then Ember has a significant role. It provides a lot of components which can be reused again in different scenarios inside the project. Along with reusability if we bring responsiveness in the picture then Semantic UI has no match. It is an open source HTML/CSS framework having self-explanatory syntax for building the user interface. It helps in building the responsive layouts which are written in the human-friendly HTML. Most of the class names are closer to normal spoken English words which seem to flow naturally and requires less to refer the documentation. For example, if we want to create a checkbox in semantic UI then we can simply use the following piece of code to create a checkbox. The table is collections of data which are grouped together and arranged in the rows. Semantic UI offers a variety of table layouts for creating the customised table according to the requirement. The table follows responsive behaviour where they automatically stack their layouts according to the mobile devices and using the keyword, ‘tablet stackable’ they can stack themselves for the tablet which helps in avoiding the overflow of UI in the small devices.Semantic UI offers 6 types of “Collections” which are breadcrumb, form, grid, menu, message and table. However, in this article, we’ll keep our focus on two main collections which have been widely used in the entire project Table and Grid. The grid is used to realign the space in the page. It divides the entire horizontal space into units called "columns" where all columns must specify their width as a proportion of the total available row width. The Semantic UI's by default theme uses 16 columns means it divides the entire space into 16 indivisible proportionate columns. Let’s illustrate how these grids and tables have been used in the Open Event Frontend project by taking example two scenarios where the tables and grid both have been used along with the code snippets for better understanding. Scenario 1: Suppose we are creating a new event and we want to add the list of sessions along with their details for the event which will be visible to the user while navigating through the public page of the event. The page where we will be making changes will be visible only to the person who will be creating the event and authorised to add, remove and edit the sessions. The page where we can create, modify and see the other details of the sessions look like this. Fig. 1: Table used in Session in event/event_id/sessions page As we can see in the above image that the entire data containing the session details of all, pending, accepted, confirmed and rejected sessions are wrapped around a row of 16 columns grid in the page. The table has been put on the grid which helps in managing the flow of the content. Also, after each column there is vertical spacing, added to separate each column,…

Continue ReadingUsing semantic UI components in Open event frontend project

Using Ember.js Components in Open Event Frontend

Ember.js is a comprehensive JavaScript framework for building highly ambitious web applications. The basic tenet of Ember.js is convention over configuration which means that it understands that a large part of the code, as well as development process, is common to most of the web applications. Talking about the components which are nothing but the elements whose role remain same with same properties and functions within the entire project. Components allow developers to bundle up HTML elements and styles into reusable custom elements which can be called anywhere within the project. In Ember, the components consist of two parts: some JavaScript code and an HTMLBars template. The JavaScript component file defines the behaviour and properties of the component. The behaviours of the component are typically defined using actions. The HTMLBars file defines the markup for the component's UI. By default, the component will be rendered into a 'div' tag element, but a different element can be defined if required. A great thing about templates in Ember is that other components can be called inside of a component's template. To call a component in an Ember app, we must use {{curly-brace-syntax}}. By design, components are completely isolated which means that they are not directly affected by any surrounding CSS or JavaScript. Let’s demonstrate a basic Ember component in reference to Open Event Frontend Project for displaying the text as a popup. The component will render a simple text view which will display the entire text. The component is designed with the purpose that many times due to unavailability of space we’re unable to show the complete text so such cases the component will compare the available space with the space required by the whole text view to display the text. If in case the available space is not sufficient then the text will be ellipsized and on hovering the text a popup will appear where the complete text can be seen. Generating the component The component can be generated using the following command: $ ember g component smart-overflow Note: The components name needs to include a hyphen. This is an Ember convention, but it is an important one as it'll ensure there are no naming collisions with future HTML elements.This will create the required .js and .hbs files needed to define the component, as well as an Ember integration test. The Component Template In the app/templates/components/smart-overflow.hbs file we can create some basic markup to display the text when the component is called. <span> {{yield}} </span> The {{yield}} is handlebars expressions which will be helpful in rendering the data to display when the component is called. The JavaScript Code In the app/components/smart-overflow.js file, we will define the how the component will work when it is called. import Ember from 'ember'; const { Component } = Ember; export default Component.extend({ classNames: ['smart-overflow'], didInsertElement() { this._super(...arguments); var $headerSpan = this.$('span'); var $header = this.$(); $header.attr('data-content', $headerSpan.text()); $header.attr('data-variation', 'tiny'); while ($headerSpan.outerHeight() > $header.height()) { $headerSpan.text((index, text) => { return text.replace(/\W*\s(\S)*$/, '...'); }); $header.popup({ position: 'top…

Continue ReadingUsing Ember.js Components in Open Event Frontend

Forms and their validation using Semantic UI in Open Event Frontend

A web form acts as a communication bridge that allows a user to communicate with the organisation and vice versa. In the Open Event project, we need forms so users can contact the organisation, to register themselves, to log into the website, to order a ticket or to query for some information. Here are a few things which were kept in mind before we designed forms in the Open Event Frontend Project: The forms were designed on the principle of keeping it simple which means that it should ask only for the relevant information which is required in actual. They contained the relevant fields ordered in a logical way according to their importance. They offered clear error messages instantly to give direct feedback and allow users to make instant corrections. The clear examples were shown in the front of the field. Proper spacing among the fields was maintained to display proper error messages to the respective form fields. The mandatory fields are highlighted using ‘*’ to avoid confusion. Proper colour combinations have been used to inform the user about the progress while filling the form. For eg. red for any ‘error or incomplete’ information while green signifies ‘correct’. Saving the current data in case the user has to go back to make any corrections later. Allowing to toggle through the form using the keyboard. The above designing principles helped in avoiding the negative user experience while using the forms. Let’s take a closer look at the form and the form validation in case of purchase a new ticket form on the Orders page in Open Event Front-end application. Creating a form Let’s start by writing some HTML for the form: <form class="ui form" {{action 'submit' on='submit' }}> <div class="ui padded segment"> <h4 class="ui horizontal divider header"> <i class="ticket icon"></i> {{t 'Ticket Buyer'}} </h4> <div class="field"> <label class="required" for="firstname">{{t 'First Name'}}</label> {{input type='text' name='first_name' value=buyer.firstName}} </div> <div class="field"> <label class="required" for="lastname">{{t 'Last Name'}}</label> {{input type='text' name='last_name' value=buyer.lastName}} </div> <div class="field"> <label class="required" for="email">{{t 'Email'}}</label> {{input type='text' name='email' value=buyer.email}} </div> <h4 class="ui horizontal divider header"> <i class="ticket icon"></i> {{t 'Ticket Holder\'s Information'}} </h4> {{#each holders as |holder index|}} <div class="inline field"> <i class="user icon"></i> <label>{{t 'Ticket Holder '}}{{inc index}}</label> </div> <div class="field"> <label class="required" for="firstname">{{t 'First Name'}}</label> {{input type='text' name=(concat 'first_name_' index) value=holder.firstName}} </div> <div class="field"> <label class="required" for="lastname">{{t 'Last Name'}}</label> {{input type='text' name=(concat 'last_name_' index) value=holder.lastName}} </div> <div class="field"> <label class="required" for="email">{{t 'Email'}}</label> {{input type='text' name=(concat 'email_' index) value=holder.email}} </div> <div class="field"> {{ui-checkbox label=(t 'Same as Ticket Buyer') checked=holder.sameAsBuyer onChange=(action 'fillHolderData' holder)}} </div> {{/each}} <p> {{t 'By clicking "Pay Now", I acknowledge that I have read and agree with the Open Event terms of services and privacy policy.'}} </p> <div class="center aligned"> <button type="submit" class="ui teal submit button">{{t 'Pay Now'}}</button> </div> </div> </form>   The complete code for the form can be seen here. In the above code, we have used Semantic UI elements like button, input, label, icon, header and modules like dropdown, checkbox to create the basic structure of…

Continue ReadingForms and their validation using Semantic UI in Open Event Frontend

Diving into the codebase of the Open Event Front-end Project

This post aims to help any new contributor to get acquainted with the code base of the Open Event Front-end project. The open event front-end is primarily the front-end for the Open Event API server. The project provides the functionality of signing up, add, update and view events details and many other functions to the organisers, speakers and attendees of the event which can be concert, conference, summit or a meetup. The open event front-end project is built on a JavaScript web application framework Ember.js. Ember uses a library Ember data for managing the data in the application and for communicating with server API via endpoints. Ember is a battery included framework which means that it creates all the boilerplate code required to set up the project and create a working web application which can be modified according to our needs. The open event front-end is primarily the front-end for the Open Event API server. The project provides the functionality of signing up, add, update and view events details and many other functions to the organisers, speakers and attendees of the event which can be concert, conference, summit or a meetup. The open event front-end project is built on a JavaScript web application framework Ember.js. Ember uses a library Ember data for managing the data in the application and for communicating with server API via endpoints. Ember is a battery included framework which means that it creates all the boilerplate code required to set up the project and create a working web application which can be modified according to our needs. For example: When I created a new project using the command: $ ember new open-event-frontend It created a new project open-event-frontend with all the boilerplate code required to set up the project which can be seen below. create .editorconfig create .ember-cli create .eslintrc.js create .travis.yml create .watchmanconfig create README.md create app/app.js create app/components/.gitkeep Installing app create app/controllers/.gitkeep create app/helpers/.gitkeep create app/index.html create app/models/.gitkeep create app/resolver.js create app/router.js create app/routes/.gitkeep create app/styles/app.css create app/templates/application.hbs create app/templates/components/.gitkeep create config/environment.js create config/targets.js create ember-cli-build.js create .gitignore create package.json create public/crossdomain.xml create public/robots.txt create testem.js create tests/.eslintrc.js create tests/helpers/destroy-app.js create tests/helpers/module-for-acceptance.js create tests/helpers/resolver.js create tests/helpers/start-app.js create tests/index.html create tests/integration/.gitkeep create tests/test-helper.js create tests/unit/.gitkeep create vendor/.gitkeep NPM: Installed dependencies Successfully initialized git. Now if we go inside the project directory we can see the following files and folders have been generated by the Ember-CLI which is nothing but a toolkit to create, develop and build ember application. Ember has a runtime resolver which automatically resolves the code if it’s placed at the conventional location which ember knows. ➜ ~ cd open-event-frontend ➜ open-event-frontend git:(master) ls app config ember-cli-build.js node_modules package.json public README.md testem.js tests vendor What do these files and folders contain and what is their role in reference to the project, “Open event front-end”? Fig 1: Directory structure of the Open Event Front-end project Let's take a look at the folders and files Ember CLI generates. App: This is the heart of the…

Continue ReadingDiving into the codebase of the Open Event Front-end Project