javascript on Andrés Álvarez

Django AJAX Search With Elasticsearch

Wed, 10 Jan 2018 00:00:00 +0000

In this post I want to go over how I implemented a very neat AJAX search using Elasticsearch in Django. Let's get started!

The Search Template

The starting point of our search feature will be the search template. That is, the template that contains the input field where the user will type in the search keywords.

This template is extremely simple and does not need a <form> tag. I will create it as a partial under templates/search.html:

{% csrf_token %}
<input id="search" name="q" placeholder="Search...">

Notice how we have given the input a name with the value of q. This will be important when our view receives the query from this input field.

I can then render this partial in the main template like this:

{% include 'search.html' %}

Easy Notification System in Rails Part 3

Tue, 12 Sep 2017 00:00:00 +0000

Read part 1 and part 2 of this series

In this post, we will be sending automatic e-emails every time notifications are created.

Creating the Mailer

We will work with one mailer that will send e-mails for every notification that is created. We can generate our mailer with this command:

rails g mailer NotificationsMailer

Our mailer will contain an action for each notifiable type that works with notifications in our application. In this series, we've been using comments and posts as examples.

Easy Notification System in Rails Part 2

Tue, 05 Sep 2017 00:00:00 +0000

Read Part 1 of this series here

In Part 1 we learned how to setup our models and controllers to create notifications using callbacks in our application. Then we displayed these notifications in a Bootstrap 3 navbar using JQuery written in CoffeeScript.

In this post we will be adding more functionality to our notification system.s

Mark as Read Feature

We will be adding a feature that allows the current user to mark a notification as read as well as all notifications, in the following manner:

For a single notification, it should be marked as read when it is clicked from the list of notifications.
For all notifications, they should be marked as read when a specific button is pressed.

Setting up the Routes

Let's begin adding the necessary routes. In part 1 we defined a notifications resource. We will add a collection POST route and a member POST route of the same name:

# config/routes.rb
Rails.application.routes.draw do
  # ...

  resources :notifications, only: [:index] do
    post :mark_as_read, on: :collection
    post :mark_as_read, on: :member
  end

end

Easy Notification System in Rails

Mon, 04 Sep 2017 00:00:00 +0000

Having a notification system is very common for a web application. In this post I will go over how to implement your own simple and easy notification system for your Rails application.

This post is heavily inspired by Chris Oliver's In-App Navbar Notifications tutorial, with a few personal changes and additions.

Read part 2 of this series.

Models and Routes

Before starting with the models, lets quickly define the application resources in our routes:

# config/routes.rb
Rails.application.routes.draw do

  devise_for :users

  resources :posts do
    resources :comments
  end

  resources :notifications, only: [:index]

end

The Notification Model

We will manually generate the notification model which will handle the storing of notifications in the database. We can generate a very basic model like this:

rails g model Notification recipient_id:integer actor_id:integer read_at:datetime action:string notifiable_id:integer notifiable_type:string

Here is an explanation for some of the fields for the above model:

recipient_id: Represents the user in your application which will receive the notification.
actor_id: Represents the user in your application which triggered the notification.
read_at: The time when the notification was read. A value of nil is used for unread notifications.
notifiable_id: The object that represents this notification (a post, comment, etc). This will be a polymorphic association.
notifiable_type: Type of the notifiable object. This is usually represented by a humanized (and optionally, internationalized) string form of the object's class.

Select2 With Simple Form in Rails

Mon, 14 Aug 2017 00:00:00 +0000

Select2 is a great JQuery plugin that customizes your select boxes to give a better user interface and experience.

Recently while working on a Rails project, I was experiencing some problems when using Select2 and Simple Form in my view.

In the view, I want to use Select2 to search for people in a Person table in the application's database. Select2 should use AJAX to hit a controller's action that performs the search. The user can then select one of the results found and it will be added to the field as a token (this is a multiple select field).

The controller action looks something like this:

def search
  @people = Person.all.where('name LIKE ? OR last_name LIKE ?',
    "%#{params[:q]}%", "%#{params[:q]}%")

  respond_to do |format|
    format.json { render json: @people.map { |p| { id: p.id, full_name: p.full_name } } }
  end
end

Reworking Ace's HAML Syntax Highlighting

Mon, 10 Apr 2017 00:00:00 +0000

Ace is a great web text editor and the default editor for Cloud 9 IDE. I have been using it for many years without any complaints at all. However I was not very satisfied with the HAML syntax highlighting, which seemed to have some problems caused by indentation when highlighting some tokens. Additionally, it didn't support correct highlighting of some HAML stuff such as HAML comments (which begin with -#) or block comments.

This is how Ace's HAML syntax highlighting issues look like:

I proceeded to study Ace's logic for syntax highlighting. It consists basically on a lexer that reads the input through different regular expressions and proceeds to different stages depending on the regular expression caught. Basically, a state machine. The source where this happens is found in lib/ace/mode/haml_highlight_rules.js

Defining States

A few states have to be defined to represent where the lexer currently “stands” in regards to the code. For example, entering a multi-block comment could represent entering a new state, since everything parsed in this state would belong to this block comment until the block ends, this will also mean another change of state.

In Ace, all syntax highlighting lexers must begin with a start state. From this state we can switch to other defined states. The example below shows how we begin from the start state and can jump to a comment block state when the code matches a regular expression that represents this:

this.$rules = {
    "start": [
        {
            token: "comment.block", // multiline HTML comment
            regex: /^\/$/,
            next: "comment"
        },
        {
            token: "comment.block", // multiline HAML comment
            regex: /^\-#$/,
            next: "comment"
},

/* ... */

Notice that we define 2 different comment types, since HAML supports HAML (not rendered in HTML) and HTML (rendered in HTML) comments. Both of these different regular expressions will make the lexer parse them as comment.block tokens, and will also make the lexer jump to a comment state, denoted by the next keyword.

Using Rails With Webpack in Cloud 9

Mon, 03 Apr 2017 00:00:00 +0000

The rails/webpacker project allows integration of Webpack with a Rails application. However, setting this up in a Cloud 9 development environment needs a few tweaks to be able to work correctly. This post explains how to achieve this.

Creating the Application

We will first create a regular Rails application and then use the webpacker gem to install Webpack.

rails new webpack-app

Add the gem to Gemfile:

# Gemfile

gem 'webpacker', github: 'rails/webpacker'

Install Webpacker

rails webpacker:install

JavaScript Gotchas for Beginners

Fri, 06 Jan 2017 00:00:00 +0000

When starting to learn JavaScript, there are a few details and gotchas that are always important to remember. Memorizing and understanding these concepts will make you a better and faster JavaScript programmer overall and it is why I am listing a few of these concepts (which are best learned at the beginner level) in this post.

The Global Object

The global scope is the space in which global variables live and it can also be approached as an object. Each global variable is present as a property of this object. In browsers, the global scope object is stored in the window variable:

var v = 10;
console.log("v" in window);
// > true
console.log(window.v);
// > 10

Custom Pages in Zenoss

Mon, 26 Dec 2016 00:00:00 +0000

In a previous post I talked about how to create custom navigation links in Zenoss using a ZenPack. However we didn't get to creating the custom pages that these links would link to. This is what we will learn today.

Page Viewlets

Previously we created navigation item viewlets, this time we will be creating page viewlets. These type of viewlets allow us to create and insert new custom pages into Zenoss where we can display custom content. To create a new page, we add the following code to browser/configure.zcml:

<browser:page
  name="secondaryPage"
  for="*"
  permission="zenoss.View"
  template="templates/my_template.pt"
  />

It is important that the name attribute matches the URL of the navigation link we created previously. Another important attribute is the template attribute, this is a special file that will represent the base markup of the page using a combination of HTML, TAL, and METAL.

Also let's not forget to create a necessary python init file:

touch browser/__init__.py

Extending Zenoss Navigation Bars

Wed, 21 Dec 2016 00:00:00 +0000

It is possible to extend the functionality of Zenoss's navigations from within our custom ZenPacks. This means that we can add or remove links to the navigation bars we frequently use to access the infrastructure page or event console.

configure.zcml

Zenoss ZenPacks can contain a file in the ZenPack top directory called configure.zcml. I've mentioned and talked about this particular file in previous posts. This file basically acts as a configuration glue between back-end functions and front-end components.

It is in this file where we will declare and create new navigational links from our ZenPack.

~> In this post we assume that the ZenPack is created using zenpacklib, which is a Python library that makes creating ZenPacks much easier. Zenpacklib also makes the integration between the back-end and front-end much easier as well.

Usually this file begins with some required boilerplate code:

configure.zcml:

<?xml version="1.0" encoding="utf-8"?>
<configure
  xmlns="http://namespaces.zope.org/zope"
  xmlns:browser="http://namespaces.zope.org/browser"
  xmlns:zcml="http://namespaces.zope.org/zcml">

  <!-- Our custom code here -->
  <include package=".browser" />
</configure>

Custom Zenoss API Endpoints

Tue, 20 Dec 2016 00:00:00 +0000

In a previous post I went over the Zenoss JSON API and how it works inside the Zenoss Core. In this post we will apply the concepts learned in that post in order to create custom API endpoints within Zenoss, which can be accessed by the JavaScript front-end, curl, API clients, etc. All this new functionality added from a basic ZenPack.

Creating an Endpoint

Assuming that we are starting with a new and fresh ZenPack created with zenpacklib, we will proceed to create a simple endpoint.

Let's go ahead and create a file named api.py (can be any name) under the ZenPack's top directory. In this file we will import necessary modules, implement interfaces, and define our routers and facades. If you still don't know what routers and facades are and what they do, I suggest you first take a look at The Zenoss JSON API post.

First, let's take a quick look at the imports:

import os.path
from urlparse import urlparse
import subprocess

from zope.event import notify
from zope.interface import implements
from ZODB.transact import transact

from Products.ZenUtils.Ext import DirectRouter, DirectResponse
from Products import Zuul
from Products.Zuul.catalog.events import IndexingEvent
from Products.Zuul.facades import ZuulFacade
from Products.Zuul.interfaces import IFacade
from Products.Zuul.utils import ZuulMessageFactory as _t
from Products.ZenUtils.Utils import zenPath

Some imports are probably not needed, but the ones that are of our interest are imports such as DirectRouter and DirectResponse, which you might remember from the previous post. Additionally we are also importing the necessary facade, events, and interfaces imports.

The Zenoss JSON API

Thu, 24 Nov 2016 00:00:00 +0000

The Zenoss JSON API allows us to obtain very important information of what is going on in Zenoss, such as device information and events. This API can be queried using cURL or with some wrappers provided by Zenoss, available in languages such as Bashscript, Python, and Java.

The API documentation can be downloaded here. In the documentation you can see the available endpoints and methods that can be used to obtain the data we need.

In this post I will cover how the Zenoss back-end JSON API works, and how the Zenoss's front-end (made using ExtJS) interacts with it.

~> Even though Zenoss calls its API a JSON API (Simply because it returns data in JSON format), the API is not JSON API specification compliant.

Querying the API

To see the API in action, we can begin by making a simple query using cURL. Let's say we want to obtain all the available information of a specific device:

curl -u "admin:zenoss" -X POST -H "Content-Type: application/json" -d '{"action": "DeviceRouter", "method": "getInfo", "data": [{"uid": "/zport/dmd/Devices/Server/SSH/Linux/NovaHost/devices/$DEVICE_IP"}], "tid": 1}' http://$ZENOSS_HOST:8080/zport/dmd/device_router

The above request will return the information of the device in JSON format, assuming that we replace $ZENOSS_HOST with the IP address of our Zenoss server, and $DEVICE_IP with the IP address of the device we want to query.

This is all fine if all we need is querying the API and nothing else. But what if we really want to know how the API back-end works? How the endpoints are created? What are routers?

This is what we are gonna learn next.

Modifying the Zenoss Infrastructure Grid

Thu, 10 Nov 2016 00:00:00 +0000

Continuing from my previous post, where I explained how to modify the device detail bar from a ZenPack using ExtJS, in this post I will explain how we can modify the device list grid shown in the infrastructure page.

The Infrastructure Grid

This is the table in the infrastructure page that shows all devices being monitored by Zenoss. Default columns include device name, device class, IP address, production state, and events, as shown in the image below:

However it would be nice to also include the power status we added to the device detail bar in the previous post, maybe even add the ping status as well (why Zenoss doesn't do this by default is beyond me).

DevicePanels.js

The source code for the grid is found in $ZENHOME/Products/ZenUI/browser/resources/js/zenoss/DevicePanels.js. A quick glance at it and you will quickly find the definitions of the columns I mentioned earlier, defined in an array called deviceColumns.

Modifying the Zenoss Device Detail Bar

Tue, 08 Nov 2016 00:00:00 +0000

The Zenoss Core ExtJS graphic user interface is divided into many different components. In this post I will go over on how we can modify the device detail bar to display additional custom information for devices, by creating a custom ZenPack.

Zenoss Core 4 uses ExtJS 4 JavaScript framework to manage all the user interface components. These components can be found in $ZENHOME/Products/ZenUI3/browser/resources/js/zenoss, and as you would expect, the device detail bar component is also located there.

The Device Detail Bar

This is the detail bar located on the device view page which shows the device's icon, name, events, status, production state, and priority. The JavaScript source code for this component can be found in DeviceDetailBar.js

However since we are going to extend this component through a ZenPack, we will not modify that source. Instead, we will add new code to use ExtJS to add our custom data displays.

Extending The Component, Through ZenPacks

Let's assume we are starting with a freshly created ZenPack, which adds a new power_status integer field to certain devices, according to its zenpack.yaml file:

# ...

classes:
  CustomDevice:
    base: [zenpacklib.Device]
    label: Custom Device
    properties:
      power_status:
        type: boolean

What we want is to display this value in the device's detail bar, similar to the device's ping status display.