This blog article will illustrate how the creation of the view route for sessions is done and how the sessions API is integrated with it on Open Event Frontend, which allows for the sessions and their associated data to be displayed. Also, it illustrates how the template for my-sessions is modified to make it possible to reuse it for the view route with desired changes.
The primary end point of Open Event API with which we are concerned with for fetching the the session details is
GET /v1/sessions/{session_identifier}
For displaying the complete session information on the view route, the session type, speakers and session track are also required. All of these extra attributes have a relationship with a given session and hence can be fetched in a single query. Thus the model for the route is defined as follows:
The view route is located at app/routes/my-sessions/view and the parent route, app/routes/my-sessions has another sub route within it called list. The list route shows upcoming and past sessions to the user based on the params passed to it. Thus a navigation is required to alternate between those two routes. However, this navigation should not be present in the view route. Thus the template my-sessions.hbs is modified as follows:
Based on the state property of the session, the label displaying the status is appropriately coloured wherein green, yellow and red colours denote accepted, pending and rejected sessions respectively. Since most of the fields of the session model are optional in nature, all of the them are subjected to conditional checks for existence.
Badgeyay project is divided into two parts i.e front-end with Ember JS and back-end with REST-API programmed in Python.
Badgeyay has many features related to enhancement in the generation of badges. It gives the choice of uploading data entries i.e by CSV or manually. There are options available for choosing Badge Background and font specifications. But there is an important feature missing which will make the service more user-friendly in terms of creation of badges for different types of events i.e, Badge Size.
Badge Size feature is implemented in Backend. I need to send the data in the backend in the desired format for creation of Badges with different sizes.
In this Blog, I will be discussing how I implemented Badge Size feature in Badgeyay Frontend in my Pull Request.
Let’s get started and understand it step by step.
Step 1:
Create Badge Size component with Ember CLI.
$ ember g component badge-component/badge-size
Step 2:
Write the HTML required in the badge-size component:
Open Event Frontend allows the organizer of an event to customise the sessions and speakers form using the custom form API. While creating the event the organiser can select the form fields which he wants to place in the sessions and speakers form. This blog will illustrate how a form to edit the details of a speaker is created. Only those fields are included which were included by the person who created the event during the sessions and speakers creation section.
The first step is to retrieve the fields of the form. Each event has custom form fields which can be enabled on the sessions-speakers page, where the organiser can include/exclude the fields for speakers & session forms.
A query is written in the javascript file of the route admin/speakers/edit to retrieve the required details and create a form. The second query helps to determine the speaker id and include the model of speaker and the attribute values of the speaker with that specific id.
In the frontend we call the form of session and speakers. With the speaker-id being passed from the route, a form is created with the values entered by the user during the speaker creation and the other attributes marked included in the session-speakers wizard.
This blog article will illustrate how validations are added to a form in Open Event Frontend, in a standard format. The form to Edit a Speaker is created in the route /event/<event_identifier>/speakers/edit. For the creation of a form an ember component is generated.
$ ember g component forms/events/view/edit-speaker
This command results in the generation of:
An ember component edit-speaker.js to add the validation rules of the form.
A handlebar edit-speaker.hbs where the HTML code is written.
First the form for editing a speaker is created. All the fields are added.
<form class=”ui form {{if isLoading ‘loading’}}” {{action ‘submit’ on=’submit’}}>
Then validation rules for the fields included in the form are added in the component. The validations of a form are stored as objects, where the identifier attribute determines which field to apply the validation conditions to. The rules array contains all the rules to be applied to the determined object. Within rules, the type represents the kind of validation, whereas the prompt attribute determines what message shall be displayed in case there is a violation of the validation rule. These validations are in turn implemented by the FormMixin.
import { protocolLessValidUrlPattern, validTwitterProfileUrlPattern } from ‘open-event-frontend/utils/validators’;
export default Component.extend(FormMixin, {
getValidationRules() {
return {
inline : true,
delay : false,
on : ‘blur’,
fields : {
email: {
identifier : ’email’,
rules : [
{
type : ’empty’,
prompt : this.get(‘l10n’).t(‘Please enter your email ID’)
},
{
type : ’email’,
prompt : this.get(‘l10n’).t(‘Please enter a valid email ID’)
}
]
},
twitter: {
identifier : ‘twitter’,
optional : true,
rules : [
{
type : ‘regExp’,
value : validTwitterProfileUrlPattern,
prompt : this.get(‘l10n’).t(‘Please enter a valid twitter url’)
},
{
type : ‘regExp’,
value : protocolLessValidUrlPattern,
prompt : this.get(‘l10n’).t(‘Please enter a valid url’)
}
]
},
website: {
identifier : ‘website’,
optional : ‘true’,
rules : [
{
type : ‘regExp’,
value : protocolLessValidUrlPattern,
prompt : this.get(‘l10n’).t(‘Please enter a valid url’)
}
]
}
}
};
}
Then for adding the validation for the URLs of the speaker’s website and his twitter account regular expressions are used. They are used to perform pattern-matching.
export const validTwitterProfileUrlPattern = new RegExp(
‘^twitter\\.com\\/([a-zA-Z0-9_]+)$’
);
export const protocolLessValidUrlPattern = new RegExp(
‘^’
// user:pass authentication
+ ‘(?:\\S+(?::\\S*)?@)?’
+ ‘(?:’
// IP address exclusion
// private & local networks
+ ‘(?!(?:10|127)(?:\\.\\d{1,3}){3})’
+ ‘(?!(?:169\\.254|192\\.168)(?:\\.\\d{1,3}){2})’
+ ‘(?!172\\.(?:1[6-9]|2\\d|3[0-1])(?:\\.\\d{1,3}){2})’
// IP address dotted notation octets
// excludes loopback network 0.0.0.0
// excludes reserved space >= 224.0.0.0
// excludes network & broacast addresses
// (first & last IP address of each class)
+ ‘(?:[1-9]\\d?|1\\d\\d|2[01]\\d|22[0-3])’
+ ‘(?:\\.(?:1?\\d{1,2}|2[0-4]\\d|25[0-5])){2}’
+ ‘(?:\\.(?:[1-9]\\d?|1\\d\\d|2[0-4]\\d|25[0-4]))’
+ ‘|’
// host name
+ ‘(?:(?:[a-z\\u00a1-\\uffff0-9]-*)*[a-z\\u00a1-\\uffff0-9]+)’
// domain name
+ ‘(?:\\.(?:[a-z\\u00a1-\\uffff0-9]-*)*[a-z\\u00a1-\\uffff0-9]+)*’
// TLD identifier
+ ‘(?:\\.(?:[a-z\\u00a1-\\uffff]{2,}))’
// TLD may end with dot
+ ‘\\.?’
+ ‘)’
// port number
+ ‘(?::\\d{2,5})?’
// resource path
+ ‘(?:[/?#]\\S*)?’
+ ‘$’, ‘i’
);
Resources
EmberJS Mixins–Official ember documentation: https://guides.emberjs.com/v2.2.0/models
FOSSASIA‘s Open Event Frontend uses the Ember Models Table for rendering all its tables. This provides features like easy sorting, pagination etc. Another major feature is that it can be modified to meet our styling needs. As we use Semantic UI for styling, we added the required CSS classes to our table.
In version 1 this was done by overriding the classes, as shown below :
But in version 2, some major changes were introduced as follows:
All partials inside a models-table were replaced with components
models-table can now be used with block content
New themes mechanism introduced for styling
Here, I will talk about how the theming mechanism has been changed. As I mentioned above, in version 1 we used custom classes and icons. In version 2 the idea itself has changed. A new type called Theme was added. It provides four themes out of the box – SemanticUI, Bootstrap4, Bootstrap3, Default.
We can create our custom theme based on any of the predefined themes. To suit our requirements we decided to modify the SemanticUI theme. We created a separate file to keep our custom theme so that code remains clean and short.
The last three are same as customClasses and customIcons and customMessages in version 1. Components is the map for components used internally in the models-table. In case you need to use a custom component, that can be done as follows:
Make a new JavaScript file and provide its path in your theme file.
Now just create the theme file object and pass it to themeInstance in the ui-table file (can also be passed in the template and the controller, but this has to be done for each table individually).
Hence, version 2 introduces many new styling options and requires some refactoring for those who were using version 1. It is totally worth it though considering how easy and well managed it is now.
This blog article will illustrate how to edit a Session in Open Event Frontend, for which a nested route /sessions/edit/<session_id> had to be created. Further an Edit Session Form was created on that route to use the patch end-point of the sessions API of Open Event API.
To get started with it, we simply use the ember CLI to generate the routes
$ ember generate route events/view/sessions/edit
Now router.js file is changed to add the session_id. The router.js file should be looking like this now.
This means that our routes and sub routes are in place. We are using ember CLI to generate these routes, that means, the template files for them generate automatically. Now these routes exist and we need to write the data in the templates of these routes which will get displayed to the end user.
The routes are nested, the content of the parent route can be made available to all the children routes via the outlet in ember js.
Next, we go to the template file of sessions/edit route which is at templates/events/view/sessions/edit.hbs which displays an Edit Session form.
<form class=”ui form {{if isLoading ‘loading’}}” {{action ‘submit’ on=’submit’}}>
After the editing of different attributes is done Save Session button is clicked for which the action is defined in the controller /controllers/events/view/sessions/edit.js. The patch endpoint was called and the details of the attributes changes were saved.
This blog article will illustrate how the sanitizer service works in Open Event Frontend, which allows the frontend to sanitize or clean any piece of text which can cause potential vulnerabilities in the application. To quote the official ember guides:
“An Ember.Service is a long-lived Ember object that can be made available in different parts of your application.”
Thus the chief advantage the service offers is, that the service once injected in the application can be called at any place in the templates without an explicit import.
For instance, in the route `coc`, the templates make use of the servcie as
{{sanitize model.codeOfConduct}}
The core of the sanitizer service is comprised of npm sanitize-html module. The sanitize-html is a powerful module which offers an extensive set of features and customisations to deal with cleaning of html embedded text. The service efficiently exposes these features to the app, and wraps its features in various functions to offer several methods which can be used to handle html text.
The options parameter of the service allows properties like allowedTags and and allowedAttributes which remove the specified tags and attributes from the text respectively. The transformTags property replaces the specified left hand side tags to the corresponding right hand side tags.
These are the generic requirements of the app and hence are exposed via tha purify method of the service. The purify method returns the sanitized string based on the configuration in the options parameter. Alternatively the strip method does not make use of the options parameter and rather passes a custom set of options with empty values for allowedTags and allowedAttributes. This method is used to completely remove any html tags or attributes from the text.
The service can be used outside of the templates in a controller or a component.
For instance the css helper uses the service to clean any text of html tags passed as a css property. The CSS helper is defined as follows.
This blog article will illustrate how the Speakers API is integrated in Open Event Frontend, which allows for the speakers and their associated data to be displayed in the speakers table. Also, it illustrates how the basic semantic UI table is converted into an ember model table to accommodate the fetched data from the API. Our discussion primarily will involve the app/routes/events/view/speakers route to illustrate the process.
The primary end point of Open Event API with which we are concerned with for fetching the the speaker details is:
GET /v1/events/{event_identifier}/speakers
First we need to formulate the filters options while making the API call. There are several tabs present which display all the sessions in a particular state i.e. pending, rejected, accepted and all. Thus the formulated filter options stored in the variable filterOptions are as follows:
let filterOptions =[];
if(params.speakers_sessions_state ==='pending'){
filterOptions =[{
name : 'state',
op : 'eq',
val : 'pending'}];
}elseif(params.speakers_sessions_state ==='accepted'){
filterOptions =[{
name : 'state',
op : 'eq',
val : 'accepted'}];
}elseif(params.speakers_sessions_state ==='rejected'){
filterOptions =[{
name : 'state',
op : 'eq',
val : 'rejected'}];
}else{
filterOptions =[];
}
Next we need to formulate the required query to actually make the API call. It is important to note here that there is a column for sessions of the speaker in the speaker table. Sessions are a related field for a user and hence we will make use of the include clause while generating the query, Similarly we will make use of the filter clause to pass on the filter options we generated above in filterOptions.
Since the speakers are being fetched for a particular event, and we are in that event’s dashboard, the speakers in question have a hasMany relationship with the aforementioned event. Thus we can make use of the model already fetched in the view route. So the final query call will be as follows:
The page[size] option in the query is for implementing pagination, it ensures that at max 10 speakers are returned at once.
Next, we need to convert the existing table to an ember model table. For this the first step is to delete the entire original table along with the dummy data in it. The events-table ember table component will be re-used to form the base structure of the table as follows:
Final steps of conversion table to ember table involve defining the columns of the table. They will be defined in the usual manner, with mandatory title and name attributes. In case the display requirements of the data are in mere simple text, calling a template for displaying the text is not required, however for more complex natured values in the columns, it is advisable to make use of the component, and the technical logic can be handled in the component template itself. For instance, one such field on the speakers table is sessions which are related records and were included especially in the query call. They are not directly accessible by their field names. Thus they must be referred as a child of the record object.
{{#each record.sessions as |session|}}{{session.title}}{{/each}}
Similarly the template for the actions column will have to be created as it requires complex logic to implement actions on those buttons. After defining all the columns in the controller, the final columns are as follows:
columns: [{
propertyName : 'name',
title : 'Name'},
{
propertyName : 'email',
title : 'Email'},
{
propertyName : 'mobile',
title : 'Phone'},
{
propertyName : 'sessions',
title : 'Submitted Sessions',
template : 'components/ui-table/cell/events/view/speakers/cell-simple-sessions',
disableSorting : true},
{
propertyName : '',
title : 'Actions',
template : 'components/ui-table/cell/events/view/speakers/cell-buttons'}]
After performing all these steps, the static table which was holding dummy data has been converted into an ember table and thus features like inbuilt pagination, searching etc. can be used.
Badgeyay project is divided into two parts i.e front-end with Ember JS and back-end with REST-API programmed in Python.
Badgeyay frontend has many features like Login and Sign up features and Login with OAuth and the most important, the badge generation feature is also up and running but the important thing from the User’s perspective is to get notified of all the actions performed in the application so that user can proceed easily further after performing a specific action in the Application..
In this Blog, I will be discussing how I integrated ember-notify in Badgeyay frontend to notify user about the actions performed in my Pull Request.
Ember-notify displays a little notification message down the bottom of our application.
Let’s get started and understand it step by step.
Step 1:
This module is an ember-cli addon, so installation is easy:
npm install ember-notify --save-dev
Step 2:
Inject the notify service in the controller of the template. Here, I will showing how I added it in showing Log In and Logout messages and you can check the whole code in my Pull request for other controllers also.
// controllers/login.js import Ember from 'ember';
import Controller from '@ember/controller';
const { inject } = Ember;
exportdefault Controller.extend({
session : inject.service(),
notify : inject.service('notify'),
..........
this_.transitionToRoute('/');
this_.get('notify').success('Log In Successful');
}).catch(function(err) {
console.log(err.message);
this_.get('notify').error('Log In Failed ! Please try again');
});
............
this_.transitionToRoute('/');
this_.get('notify').success('Log In Successful');
})
.catch(err => {
console.log(err);
});
}).catch(function(err) {
console.log(err.message);
this_.get('notify').error('Log In Failed ! Please try again');
});
..........
// controllers/logout.jsimport Ember from 'ember';
import Controller from '@ember/controller';
const { inject } = Ember;
exportdefault Controller.extend({
session : inject.service(),
notify : inject.service('notify'),
beforeModel() {
returnthis.get('session').fetch().catch(function() {});
},
actions: {
logOut() {
this.get('session').close();
this.transitionToRoute('/');
this.get('notify').warning('Log Out Successful');
}
}
});
I have implemented ember-notify for Logging In and Out feature & in the similar way I have implemented it for other controllers and complete code can be seen in my Pull Request.
Step 3::
Now run the server to see the implemented changes by following command.
$ ember serve
Navigate to localhost and perform login and logout actions to see the changes.
Successful Log In
Successful Log out
Successful CSV Upload
Now, we are done with the integration of ember-notify in Badgeyay frontend to notify user about the actions performed in the Application.
Badgeyay project is now divided into two parts i.e front-end of Ember JS and back-end with REST-API programmed in Python.
After a discussion, we have finalized to go with Semantic UI framework which uses simple, common language for parts of interface elements, and familiar patterns found in natural languages for describing elements. Semantic allows to build beautiful websites fast, with concise HTML, intuitive javascript and simplified debugging, helping make front-end development a delightful experience. Semantic is responsively designed allowing a web application to scale on multiple devices. Semantic is production ready and partnered with Ember framework which means we can integrate it with Ember frameworks to organize our UI layer alongside our application logic.
In this blog, I will be discussing how I added Log In and Signup Forms and their validations using Semantic UI for badgeyay frontend in my Pull Request.
Let’s get started and understand it step by step.
Step 1:
Generate ember components of Login and Sign up by using the following command :
$ ember generate component forms/login-form
$ ember generate component forms/signup-form
Step 2:
Generate Login and Sign up route by following commands.
$ ember generate route login
$ ember generate route signup
Step 3:
Generate Login and Sign up controller by following commands.
$ ember generate controller login
$ ember generate controller signup
Step 4:
Now we have set up the components, routes, and controllers for adding the forms for login and Sign up. Now let’s start writing HTML in handlebars, adding validations and implementing validations for the form components. In this blog, I will be sharing the code of Login form and actions related to logging In of user. You can check the whole code my Pull Request which I have made for adding these Forms.
You must be logged in to post a comment.