| 1. Introduction | ||
|---|---|---|
| Prev | Next |
This User Guide covers the Chaupal container for JAVA P2P applications, with full support for the JXTATM specification. The JXTATM specification defines a set of requirements that are needed to implement a peer-to-peer (P2P) network, and currently hosts two implementations, for the JAVA and C programing languages.
The JP2P container provided by project Chaupal contains a set of light-weight OSGI bundles that allow JXTATM to run in an OSGI container. The JP2P container does not depend on on any third party library other than JAVATM , so there is no dependency on JXTATM as well.
Besides the container, Chaupal provides tools to configure P2P applications with minimal effort, and to monitor the P2P network that is designed.
In the following we will make extensive use of the free E-book "Practical
JXTA II" to demonstrate the various configuration options of
the Chaupal container
This tutorial assumes that you have a good understanding of the Eclipse IDE and OSGI . For those who need to brush up on the basics, the following article from Lars Vogel provides an excellent reference.
| Prev | Next | |
| Chaupal User Guide | Home | 2.2 Creating a Simple Chaupal Project |
Hosted on GitHub Pages � Theme by orderedlist


Equipment
To climb safely, you will need a few pieces of basic equipment. Most rock climbing gyms will rent this equipment to you. You can also buy your own equipment from an outdoor gear store like REI, or look for used gear on Craigslist. I highly recommend using rental gear first, before you buy. That will give you a change to find out what you like. Remember, you can don't have to buy everything at once.


LATEST NEWS
123
456
Ver 0.5 → Fix two frams in about me page. Read it
Details:
- Fix headshot and content frames' alignment.
- Put education part in about me page.
Ver 0.4 → Working on about me page. Read it
Details:
- Create the navigation bar.
- Center everything.
- About me page: create the headshot frame and content frame.
Ver 0.2 → Build the basic structure of index page. Read it
Details:
- Make the top bar
- Make the banner
- Create a center area and leave white space on left and right side.


outside
outside
inside
space
css escapes
second copy for testing plural findElements
second copy
Here's a checkbox:
One
Two
Four
Still learning how to count, apparently
Here's a checkbox:
One
Two
Four
Still learning how to count, apparently
One
Two
Four
Still learning how to count, apparently
hello world
hello world
hello world


A Developer
Web Developer || Digital Marketer || Wordpress Developer
I like to keep it simple. My goals are to focus on typography, content and conveying the message that you want to send.
I'm a developer, so I know how to create your website to run across devices using the latest technologies available.


Wind Chaim Name Photo Frame Teddy Bouquet
Rs.1000.00 Rs.2500.00 Rs.3200.00
Photo Wall Hanging Open letter Box Heart Foldable Card
Rs.1200.00 Rs.1800.00 Rs.1200.00
Hexagon Explosion Box 501 Reason Box Collage Bouquet
Rs.1500.00 Rs.1400.00 Rs.3500.00
Photo Wall Clock Small Chocolate Box Chocolate Bouquet(V1)
Rs.1500.00 Rs.1000.00 Rs.3500.00
Punch Box+8Roshers Waterfall Card Couple Name Collage
(Bouquet) Rs.800.00 Rs.2000.00
Rs.4000.00
Photo Wall Hanging Wind Chaim NewsPaper Print(1)
Rs.1000.00 Rs.1200.00 Rs.800.00
Initial letter NewsPaper Print(2) Photo Clock(1)
(photo frame) Rs.1000.00 Rs.1500.00
Rs.1000.00
Zigzag Card(1) Zigzag Card(2) Photo collage Frame
Rs.800.00 Rs.1200.00 Rs2000.00
Magic Cube Increasing Photo Collage Greeting Card
Rs.1500.00 Rs.2500.00 Rs.500.00
Open Letter Box Flower Hexagon Chocolate Bouquet
Rs1800.00 (explosion box) Rs.3500.00
Rs.1500.00
Infinity Photo Card Photo Calendar Name Collage
Rs.1200.00 Rs.2800.00 Rs.2500.00
Photo Bouquet(2) Heart Collage Frame Changable photo Frame
Rs.3500.00 Rs.2000.00 Rs.2000.00
Puzzle Photo Frame Infinity Photo Box Squash Card
Rs.800.00 Rs.1800.00 Rs.1200.00
Cake Surprise Name Scrapbook Photo Reel
Rs.3800.00 Rs.3500.00 Rs.2200.00


Hello everyone, I hope you are doing well during these time. In this post, we're going to look at how to build a facial expression recognition project from scratch using PyTorch. We'll start from simple task such as downloading dataset, dataset preparation to writing our own custom CNN and a build a ResNet-9 for our use case. We'll also experiment with different learning rate schedulers. This article assumes you have some basic knowledge of how PyTorch works. Hope you enjoy it.
This post is a part of my final project for the free course provided by jovian.ml - Pytorch: zero to gans. The notebook accompanying this post: github
The goal of this project is to classify facial expressions into various categories such as anger, fear, surprise, sadness, happiness and so on. Specifically we are going to classify are datasets into 7 categories such as:
The dataset used for this project can be downloaded from here. This dataset consists of 48x48
pixel
grayscale images of faces. The faces have been automatically registered so that the face is more or less centered
and occupies about the same amount of space in each image.
Necessary imports:
Now that we know the goal of this project, let's start with the very first step of any machine learning
project i.e. preparing our dataset. After downloading the data, we can see that our data is in a .csv
file. To use this .csv file we can use the Pandas
function read_csv(..) to load the
data into memory.
We can see that our .csv file contains 3 columns:
Traininig
, PrivateTest
,
PublicTest
. It states which rows are to be used for training and testing purpose.We're going to combine together the Training
and PublicTest
rows and use them as
training and validation set, splitted in an 80-20 proportion. We'll use the
PrivateTest
rows as our test dataset.
Taking a quick peek at the countplot for the emotion
column we can see that there
is heavy class imbalance in our dataset. To remedy this, we'll use different data transformations techniques
available in pytorch.
One simple thing we can do is merge the Angry
and Disgust
class into one as both as
highly related. Doing this we can decrease some of the imabalance as the Disgust
class had the lowest
number of datapoints.
We can do so by:
Updating the emotions dictionary:
Let's first extract the pixel values for each row from pixels column.
Steps:
Doing so our dataset dataframe object will now contain 2306 rows, with 2304 columns for pixels, 1 for emotion and 1 for Usage.
Finally now we can now create our custom Dataset class that will come in handy for applying data augmentation and for building our dataloaders. Here we are simply defining methods that will, on each call by the Dataloader help in retreiving the labels y i.e. the emotion and the pixel values i.e. our X values reshaped as a 48x48 matrix as a single tuple of (X, y). Doing this, we can freely define our augmentation methods without worrying about the implementation details. The augmentation for each image can be directly applied during a iteration.
There's a whole list of different augmenations we can apply to our images they can be found here.
For this project I chose to go with some basic augmentaions such as:
Note that, in every machine learning task we apply transformations only to the training set and not the validation or test set with exception such as normalization, converting to tensors. This is because we want to pretend that the validation & test data are new, unseen data. We use the validation & test dataset to get a good estimate of how our model performs on any new data.
From quora
"The training and testing data should undergo the same data preparation steps or the predictive model will not make sense. This means that the number of features for both the training and test set should be the same and represent the same thing. If your input is an image and you did pre-processing steps like resizing, background subtraction, normalization, etc, the same steps should be done to the test set. If you did data transformation, such as PCA, random projection etc, then the test set must be transformed using the parameters of the training set and then passed to the classifier."
Straight from the documentaion:
Combines a dataset and a sampler, and provides an iterable over the given dataset.
The DataLoader supports both map-style and iterable-style datasets with single or multi-process loading, customizing loading order and optional automatic batching (collation) and memory pinning.
We'll create 3 helper functions to fetch dataset and return dataloader for each set:
To use the power of GPU's we have to first move our data and models that we're going to create onto the
available gpu.
To do this we have to:
to_device
that iterates over the passed data and loads it into GPU
memory.DeviceDataLoader
that wraps our dataloader and uses the recursive function defined
to move the data to GPU when accessed.Get the current device in use:
Finally, we've arrived to the exiting part everyone likes, the Building models. For this project I used two models:
We'll divide this section into two parts:
Parent Class by definition means a class that contains some properties or methods that are common to all the
inhereting child classes. For our use case we'll create an ImageClassificationBase
class that
itself inherits from the nn.Module
class from PyTorch. This class will contain some methods that can
be used by the child classes such as:
training_step
- method used to perform operations during the training step for the model.validation_step
- methods used to evaluate our model on the validation set.get_metrics_epoch_end
- contains operations that when called after training or validation step
for a single epoch, returns the metrics such as accuracy, loss,
val_accuracy, val_loss.epoch_end
- prints the current epoch metrics.The great thing about this class is that it can be used for any image classification problem in PyTorch with little to no updation necessary.
Metric: Using the good old accuracy
.
ResNets architectures by design uses skip connections in residual blocks, because of these skip connections, we can propagate larger gradients back to initial layers avoiding vanishing gradients and these layers also could learn as fast as the final layers, giving us the ability to train deeper networks.
Here, I've updated the default ResNet9 architecture to accomodate for the fact that we have a grayscale
dataset.
We can simply do thid by updating the in and out channels in each conv_block
, I've also added an
additional Linear
layer classifier block.
(open the image in a new tab and hover over the blocks to see how they are defined.)
Building block of our ResNet9 architecture:
The ResNet9 model class:
Let's build a CNN model to compare with the ResNet9 model
In both of these classes we can see a forward
method. This method is called by the
training_step
method of the BaseClass using self(inputs)
. This is because when
we inherited the nn.Module
class in the BaseClass, it expects the forward
method in it to be overriden. Doing so provide us with the functionality to directly call the model (self) and
pass it any arguments like self(inputs)
, it'll internally call the model's forward method
and pass it input parameters. We can then choose what we want to do within forward
method as seen in
both the ResNet9 class and EmotionRecognition class.
We're nearly at the end of project but first we need to define some helper functions to bind together all the above defined functions and classes.
fit_model
function which is reponsible for training and saving the best model.evaluate
function for evaluating the validation set.load_best
helper function to load our best model for evaluating the test set.generate_prediction
function for generating predictions on the test set using the best model.
end-to-end
function that binds all these functions in a simple single call requiring the name
of the model to use and training parameters as a dictionary.evaluate
, fit_model
load_best
and generate_predictions
plotting
end-to-end
| model | Epochs | >LR | Test accuracy |
|---|---|---|---|
| Emotion Recognition | 20 | None | 0.659 |
| ResNet9 (current) | 20 | None | 0.651 |
| Resnet9 | 20 | OneCycleLr | 0.327 |
| Emotion Recognition | 20 | OneCycleLr | 0.26 |
| Emotion Recognition | 30 | None | 0.67 |
| ResNet9 | 30 | None | 0.66 |
| Emotion Recognition | 30 | ReduceLROnPlateau | 0.664 |
| ResNet9 | 30 | ReduceLROnPlateau | 0.683 |
We've covered a lot of ground in this tutorial. Here's quick recap of the topics:
dataset
class.torch.transforms
.DeviceDataLoader
class for our Dataloader
to move our data
to the GPU.nn.Module
class and also created a BaseClass
that can be
used for any image classification model.


Rabbit Hole Reports
Chindraba's Adventures in Computing
Contact Me
Where to find me
The Stack Exchange Network of Q&A Sites
Currently active profiles
⊞
≣
Keybase
As Chindraba
Direct Contact
About you
Your name (or pseudonym):
Your email address:
Your country:
Reason for contact?
Cheers & Jeers
Just sayin'
Shout-out
Bug hunting
Reasons O' My Own
What's your real reason?
Let loose your inner Shakespear
Where did you find the bug?
And lucky winner is?


Item 6.f.ii.
Use the model to predict the tuition cost for a student entering a public two-year college in the academic years \(2050\)-\(2051\text{,}\) \(2100\)-\(2101\text{,}\) and \(1900\)-\(1901\text{.}\)


{% extends 'template-lab-4b.html' %} {% set mainClasses = 'nhsuk-u-padding-top-0' %} {% block pageTitle %} Symptoms - NHS {% endblock %} {% block beforeContent %} v> {% endblock %} {% block content %}
Most headaches go away on their own and are not a sign of something more serious.
Headaches can last between 30 minutes and several hours.
drink plenty of water
get plenty of rest if you have a cold or the flu
try to relax – stress can make headaches worse
take paracetamol or ibuprofen
do not drink alcohol
do not skip meals (even if you might not feel like eating anything)
do not sleep more than you usually would – it can make the headache worse
do not strain your eyes for a long time – for example, by looking at a screen
You or your child has a sever headache and:
Also get an urgent GP appointment or call 111 if your child is under 12 and has any 1 of the following:
You can call 111 or get help from 111 online.


--- title: "4.5 — Imperfect Competition: Monopolistic Competition & Oligopoly — Class Content" citeproc: false bibliography: ../../static/bib/references.bib csl: ../../static/bib/chicago-syllabus-no-bib.csl output: blogdown::html_page: template: ../../pandoc/toc-title_html.template toc: true editor_options: chunk_output_type: console ---
Today we finally return to finish our tour of industrial organization, i.e. the types of markets by competitiveness.
We first cover monopolistic competition, a much more realistic model of most firms in the real world, where firms have some market power, but are not the only producer in their industry. To model them, we blend elements of monopoly with elements of perfect competition. In the short-run, we model the firm as a monopoly acting like any monopolist would, but in the long run, there is free entry and exit, so other entrants reduce the demand for any one firm’s product (and make it more elastic) so that firms’ economic profits go to zero.
 While some industries in the real world are indeed dominated by a small number of firms, this type of model is applicable well beyond industries with a small number of firms, as to understand the strategic nature of firm decisions, we introduce game theory into our models.
You are done with graded homeworks for the semester! However, homework 6 is available for you to practice the topics of Unit 4 for the final exam.
Turn in Exam 1 and Exam 2 corrections by the last day of class.
Don’t forget your Op-Ed is due by Friday May 14.


A website that helps you determine the competition in an area
Are you thinking about opening a business but not sure about the local competition? Using this tool allows you to see what type of business are located in a given area. The following are available business categories:
+Food and Restaurants
+Clothing and Attire
+Electronical Goods
+Goods for Homes
Using data compiled from Capitol One and and visually mapped with Omnisci, aspiring business owners are able to visualize where the competion will be held and see where the demand for their services would be the greatest.
Using data compiled from Capitol One and and visually mapped with Omnisci, aspiring business owners are able to visualize where the competion will be held and see where the demand for their services would be the greatest.
The following is a compiled visualization of the data from the sources provided. Number sales and money earned is dependent factor of time. Also included is a heat map in order to better locate which area has a saturated market and what is untapped.
This was project a for the 2019 DFW Hackathon. Special thanks to Omnisci and Capital One for contributing the resources to help accomplish this.


Custom Prefix for your server
Mai wants everyone to customize the bot to their own tastes, hence, Mai allows server administrator to add their own personal prefix.
You can check the prefix as well as the custom prefix you set just by typing prefix wherever Mai is in, and she will reply what is her prefix and the prefix you set, if you have one.
To set the prefix, just use the command m!setprefix <desired prefix>
. Prefix cannot be more than 5 characters long.
After you set your custom prefix, the default prefix will still be usable. There is no way to remove the default prefix at all. Mai's developer reserves the right to revert any prefixes that may violate Discord's Term of Service and/or Mai's Term of Service.
You can change the custom prefix anytime by using the same command again. Note that only users with 'ADMINISTRATOR'
permissions may use this command.


Learning a skill is very recommended in our today's world, and MAKE-UP ARTISTRY is one of the most trending and in-demand skills in the world right now.
Enrolling for our beginner-friendly make-up course will guarantee everything you need to be taught in order to be the best make-up artist in your circle.
Our Course Includes:
So what exactly are you waiting for? Enroll for the Seven.Glam Make Up Course and start monetizing your skill
Apply By Sending Us A WhatsApp Message!
Send us in the format below


Front-end Architect
I’m Harry; a 22 year old designer, developer, writer, and speaker from the UK. I am a Senior UI Developer for BSkyB.
I write, speak and tweet about CSS architecture, maintainable and scalable front-ends, object oriented CSS and more.
I created inuit.css—a small yet powerful CSS framework built on Sass—and pr.ofile.me, a toolkit for building digital, mobile optimised business cards like this one.
I’m all over the internet. If you want to get in touch with me I’d recommend tweeting at me or emailing me You can also follow my nerdery, articles, projects and more on:


Documentation
Epoxy.Model
The Epoxy Model object extends Backbone.Model, providing a new model abstract to be extended into your application.
The Epoxy model introduces computed attributes on top of Backbone's native model attributes. Computed attributes operate as accessors and mutators, where a computed attribute will get an assembled value derived from other model attributes, and will set one more more mutated values derived from an input. Computed attributes are virtualized properties of the model: they may be get and set just like normal model attributes, and will trigger "change" events on the model when modified, however they do not exist within the model's attributes table, nor will they be saved with model data. Computed model attributes exist only in memory for the lifespan of a model instance. Computed attributes bind themselves to their dependencies and will update themselves in response to any of their dependencies changing, and then in turn trigger their own "change:attribute" event on the model.
extend
Backbone.Epoxy.Model.extend(properties, [classProperties])
Extends the Epoxy.Model constructor for use in your own implementation.
mixin
Backbone.Epoxy.Model.mixin([target])
Generates an abstract of Epoxy.Model methods for mixin with your Model classes.
_.extend( MyModel.prototype, Backbone.Epoxy.Model.mixin() );
// or:
Backbone.Epoxy.Model.mixin( MyModel.prototype );
When initializing your model instances, you'll need to manually resolve the Epoxy constructor options and then call initComputeds to reproduce Epoxy model setup.
constructor
new Backbone.Epoxy.Model([attributes], [options])
Creates a new Epoxy.Model instance. When constructed, computeds may be passed as an options property for direct assignment to the model. A constructed model will automatically initialize all computed property definitions.
addComputed
model.addComputed(name, params) or...
model.addComputed(name, getter, [setter], [*deps])
Adds a computed attribute to the model. Computed attributes operate as accessors and mutators, where a computed attribute will get an assembled value derived from other model attributes, and will set one more more mutated values derived from an input. Computeds bind themselves to their dependency attributes and will update themselves in response to any of their dependencies changing, then in turn trigger their own "change:attribute" event on the model.
The addComputed method is called with an attribute name and a params object defining the following:
- get: Required function; invoked in context of the model. This getter function assembles its value based on other model attributes (native or computed), and then returns the generated value. If a deps param is also specified, then the dependency array will be mapped and injected as arguments into the getter function. Note that a getter function should always reference other model attributes using the model's get method (for automatic dependency mapping).
- [deps]: Optional array. An array of attribute names that the getter function depends on. When defined, the dependency attributes will be mapped and injected as arguments into the getter function. Technically this manual property mapping is only required if your getter contains unreachable values that would be missed by automatic dependency mapping (discussed below).
- [set]: Optional function; invoked in context of the model. A mutator function which receives a raw input value, and returns an object defining new key/value pairs to be merged into the model. Computed attributes declared without a set function are read-only.
Note that the get and set functions are invoked in the context of their parent model, so referencing this within their scopes refers to the model.
var model = new Backbone.Epoxy.Model({price:100});
model.addComputed("formattedPrice", {
deps: ["price"],
get: function( price ) {
return "$"+ price;
},
set: function( value ) {
return {price: parseInt(value.replace("$", ""))}
}
});
alert( model.get("formattedPrice") ); // '$100'
model.set("formattedPrice", "$150");
alert( model.get("price") ); // 150
Automatic Dependency Mapping
In the above example, ["price"] is manually declared as a dependency of the computed getter (meaning the getter will need to update itself when "price" changes). While this manual declaration is a nice safety net, we could also exclude the deps param and just get the price attribute instead, allowing automatic dependency mapping to discover attribute relationships.
Automatic dependency mapping works using the get method wrapper of the Epoxy.Model. While generating a computed attribute's initial value, the Epoxy.Model registers all attribute names requested from all Epoxy.Model instances, and binds the computed attribute accordingly. Automatic mapping works great given the following:
- All model references (the parent model, or others) are instances of Epoxy.Model.
- All model attributes are accessed using their model's get method.
- All get calls are free of conditional logic (keep reading...)
Regarding conditional get calls: this situation may create unreachable getters that cannot be automatically mapped. Consider the following BROKEN example:
var model = new Backbone.Epoxy.Model({
shortName: "Luke",
fullName: "Luke Skywalker",
active: false
});
// BROKEN:
model.addComputed("displayName", function() {
return this.get("active") ? this.get("fullName") : this.get("shortName");
});
See the error in the above example? The fullName and shortName attributes are accessed conditionally, therefore one will be unreachable while mapping dependencies. To fix this, we could either manually declare dependencies, or else get all dependencies as local variables prior to conditional logic, like so:
// FIXED:
model.addComputed("displayName", function() {
var fullName = this.get("fullName");
var shortName = this.get("shortName");
return this.get("active") ? fullName : shortName;
});
Storing Raw Values
A lesser use-case for computed attributes is the storage of additional raw model values. When a value is assigned to a computed, that value may be get and set through the model and will trigger change events, however it will not be stored in the model's attributes table, nor saved with model data. Raw values are defined as a computed attribute with a single {value:'myValue'} param.
var model = new Backbone.Epoxy.Model();
model.addComputed("rawValue", {value: 100});
alert( model.get("rawValue") ); // 100
model.set("rawValue", 200);
alert( model.get("rawValue") ); // 200
Use the computeds hash to automatically initialize computed attributes on your model instances.
clearComputeds
model.clearComputeds()
Removes all computed properties on the model and cleans up their bound events. Cleared computeds will no longer exist on the model, so will no longer be accessible or trigger events. Be sure to call clearComputeds when deprecating an Epoxy model without specifically calling its destroy method.
computeds
model.computeds
A hash table declaring computed attributes to be automatically added to a model instance by initComputeds. Uses addComputed to create computed attributes. Computeds may be declared with a computed params object, or as a getter function (uses automatic dependency mapping).
var ComputedModel = Backbone.Epoxy.Model.extend({
defaults: {
firstName: "Luke",
lastName: "Skywalker"
},
computeds: {
fullNameParams: {
deps: ["firstName", "lastName"],
get: function( firstName, lastName ) {
return firstName +" "+ lastName;
},
set: function( value ) {
var first = value.split(" ")[0];
var last = value.split(" ")[1];
return {firstName: first, lastName: last};
}
},
fullNameGetter: function() {
return this.get("firstName") +" "+ this.get("lastName");
}
}
});
destroy
model.destroy([options])
Override wrapper for the Backbone Model's native destroy method. This wrapper cleans up Epoxy model configuration, then defers to the Backbone Model's native destroy method. If you'd like to clean up a model without completely destroying it, use the clearComputeds method.
get
model.get(attribute)
Override wrapper for the Backbone Model's native get method. This override allows native model attributes and Epoxy computed attributes to be accessed through a common API.
The Epoxy get method will first check for a computed attribute, then defers to the Backbone Model's native get method if no computed value was found. Remember that a computed attribute overrides a native attribute with the same name, so be mindful of naming collisions.
getCopy
model.getCopy(attribute)
Gets a model attribute value (native or computed), and performs a shallow copy on any non-primitive values returned. This is useful for getting copies of Object and Array values that you plan to modify outside of the model, then resubmit with changes (remember that "change" events only trigger for non-primitive values when their identity changes). The modifyArray and modifyObject methods may also be used to perform object changes internally within the model.
hasComputed
model.hasComputed(attribute)
Returns true if the model has a computed attribute with the specified name. Note that the Backbone Model's native has method is NOT modified by Epoxy, so will still only report on the presence of Backbone-native model attributes.
initComputeds
model.initComputeds()
Clears all computed model attributes, then builds all computed attributes defined in the model's computeds hash. This method is automatically called by the Epoxy model constructor after initializing the model, therefore you should only need to call this manually when using Epoxy as a mixin library.
modifyArray
model.modifyArray(attribute, arrayMethod, [*args])
Performs an internal update on a stored Array model attribute (native or computed) using a standard JavaScript array modifier (pop, push, reverse, shift, slice, sort, splice, and unshift), then triggers a change event for the modified model attribute. Invoke with the model attribute name to modify, a string of the array method name to call, and any additional arguments to be passed into the array method. Returns any results from the array method. Calling modifyArray on a non-array attribute will take no action.
var model = new Backbone.Epoxy.Model({wordList:[]});
model.modifyArray("wordList", "push", "deathstar");
alert( model.get("wordList").length );
modifyObject
model.modifyObject(attribute, objectProperty, value)
Performs an internal update on a stored Object model attribute (native or computed), then triggers a change event for the modified model attribute. Invoke with the model attribute name to modify, a property name to set on the object, and a value to set as the object property. Setting undefined to a property will delete it from the object. Returns the modified object. Calling modifyObject will only take action on model attributes with an assessed type of "object".
var model = new Backbone.Epoxy.Model({ wordsDict:{} });
model.modifyObject("wordsDict", "deathstar", true);
alert( model.get("wordsDict").hasOwnProperty("deathstar") );
removeComputed
model.removeComputed(attribute)
Removes a computed attribute by name, and cleans up all bound listeners. A removed computed property will no longer exist within the model, so may no longer be accessed or trigger events.
set
model.set(attributes, [options])
Override wrapper for the Backbone Model's native set method. This override allows basic model attributes and Epoxy computed/computed attributes to be accessed through a common API.
The Epoxy set method will first check for a computed attribute, then defers to the Backbone Model's native set method if no computed was found. Remember that a computed attribute overrides a native attribute with the same name, so be mindful of naming collisions.
toJSON
model.toJSON([options])
Override wrapper for the Backbone Model's native toJSON method. Allows an optional {computed:true} param to be passed, specifying that computed attribute values should be included in the returned data.
Epoxy.View
The Epoxy View object extends Backbone.View, providing a new view abstract to be extended or mixed into your application.
The Epoxy View provides elegant and extensible hooks for binding data sources (Backbone.Model and/or Backbone.Collection instances) directly to DOM elements. When data attributes change, they will automatically trigger refresh of all bound view elements; seamlessly updating the view without requiring a complete render pass.
Also note that an Epoxy view may bind to a native Backbone.Model instance, or to an Epoxy.Model with specialized computed attributes. Because both model types operate with a common API, the Epoxy View does not depend on its Epoxy.Model counterpart to support model bindings. Therefore, you're free to exclude Epoxy.Model resources from your project if you just want view binding features.
extend
Backbone.Epoxy.View.extend(properties, [classProperties])
Extends the Epoxy.View constructor for use in your own implementation.
mixin
Backbone.Epoxy.View.mixin([target])
Generates an abstract of Epoxy.View methods for mixin with your View classes.
_.extend( MyView.prototype, Backbone.Epoxy.View.mixin() );
// or:
Backbone.Epoxy.View.mixin( MyView.prototype );
When initializing your view instances, you'll need to manually resolve the Epoxy constructor options and then call applyBindings to reproduce Epoxy view setup.
constructor
new Backbone.Epoxy.View([options])
Creates a new Epoxy.View instance. The following attributes may be passed as options for direct assignment to the view instance: viewModel, bindings, bindingFilters, bindingHandlers, bindingSources, and/or computeds.
binding context
{$model:model, $collection:collection, [*attributes], [*computeds]}
To establish bindings, an Epoxy view generates a binding context with routers mapping all available data sources, model attributes, and computed properties of the view. This compiled binding context serves as a router table for exchanging values between data sources and the view. Live values may be read and written through the binding context using the view's getBinding and setBinding methods.
As noted above, a binding context includes three sets of resources:
- Data Sources: these are instances of Backbone.Model and/or Backbone.Collection that provide themselves and their attributes to the view for binding. By default, an Epoxy view looks for three potential data sources: the view's model property, viewModel property, and its collection property. References to these data sources are automatically configured in the binding context as $model, $viewModel, and $collection. Additional models and collections may be added through the bindingSources hash, and will be added to the context as "$sourceName".
- Model Attributes: all Backbone.Model data sources will have their model attributes added to the binding context as well. For the view's primary model and viewModel properties, all attributes will be added using their normal names (ie: "attribute"). For additional models defined through bindingSources, each model's attributes will be aliased as "source_attribute". Note that instances of Epoxy.Model will provide aliases to ALL attributes, including their computeds.
- Computed View Properties: all computed property functions defined in the view's computeds hash are the final values added into the binding context.
Be mindful of naming conflicts within the binding context. Attributes of the model, viewModel, and view computeds are all aliased with their normal names. Therefore, specificity in naming is strongly encouraged.
applyBindings
view.applyBindings()
Removes any existing view bindings, then applies all bindings defined within the view's bindings object. All bindings are established using the view's $el as the display target, and the view's model, collection, and/or bindingSources properties as the data sources (see binding context for more information). A view with invalid display or data targets will apply no bindings. If the bindings object is a string, that string will be used as an attribute selector query for extracting bindings from the view's $el container.
The applyBindings method is automatically called by the view constructor after the view's initialize method runs. This allows the initialize step to make adjustments within the view prior to bindings being applied. You generally shouldn't need to call applyBindings manually.
Also note that view bindings are baked at the time they are applied. All relationships between data sources and the view are established during this binding step and can only be reconfigured by unbinding and rebinding the view.
bindingFilters
view.bindingFilters
A hash table defining a view's custom binding filters. Binding filters are used to format model data for display within the view. While Epoxy includes a core set of basic binding filters for common formatting operations; developers are also encouraged to extend their views with custom binding filters as needed.
Filters are added with a name string and a filter function or methods object. All filter arguments are pre-processed, so you may safely use conditional logic in filters without breaking automated dependency maps. All filtering functions are called anonymously and operate in global scope.
A one-way filter is defined with a name and a getter function. This getter function requests one or more values from the model, formats them, and then returns the result to the bound view:
var BindingView = Backbone.Epoxy.View.extend({
bindingFilters: {
yourName: function( firstName, lastName ) {
return "Your name is: "+ firstName +" "+ lastName;
}
}
});
The above filter definition would be bound as:

A two-way filter is defined with a methods object that provides filtering functions for getting/setting a value. A two-way filter may only apply to a single bound model value. The two-way getter function passes a formatted value from the model to the view, while the setter function passes the counter-formatted value from the view to the model:
var BindingView = Backbone.Epoxy.View.extend({
bindingFilters: {
myFilter: {
get: function( value ) {
// Format the value as it passes from the model to the view...
return value;
},
set: function( value ) {
// Format the value as it passes from the view to the model...
return value;
}
}
}
});
bindingHandlers
view.bindingHandlers
A hash table defining a view's custom binding handlers. Binding handlers are used to apply binding data to elements in the view. While Epoxy includes a core set of basic binding handlers for managing an element's content and formatting, developers are encouraged to extend their views with customized binding handlers as needed.
To declare binding handlers, define a new property on the bindingHandlers hash with a params object defining set and get function properties:
var BindingView = Backbone.Epoxy.View.extend({
bindingHandlers: {
printList: {
set: function( $element, value ) {
$element.text( value.join(",") );
},
get: function( $element, value, event ) {
return $element.text().split(",");
}
}
}
});
- set: Required function, invoked in context of the binding. This function is used to WRITE data from the model into the view. The set function receives two arguments: a jQuery representation of the bound element, and the model attribute value to be written into the view. The set function returns nothing.
- [get]: Optional function, invoked in context of the binding. This function is used to READ data from the view to be sent to the model. The get function receives three arguments: a jQuery representation of the bound element, the current model value that will be changed (useful for comparison purposes), and the event (if any) that has triggered the getter to run. The get function should return a value to replace the current bound model attribute. When modifying Object and Array values, be sure to make changes to a copy of the current value, then submit that back to the model.
While declaring a display-only binding handler (one-way binding), you may declare its setter function directly on the bindingHandlers hash:
var BindingView = Backbone.Epoxy.View.extend({
bindingHandlers: {
printList: function( $element, value ) {
$element.text( value.join(",") );
}
}
});
bindings
view.bindings
A hash declaring the view's element-to-attribute binding scheme, or a string defining an element attribute to query from the view's DOM. All bindings are established using the view's $el reference as the display target, and the view's binding context as the data provider. A view missing its $el property and/or valid binding data will apply no bindings.
The bindings hash syntax keeps all binding declarations within the view. The bindings object declares a set of key/value pairs, where the key defines an element query, and the value defines the element's model bindings. A custom ":el" pseudo-selector may be used for the view's main $el member:
var BindingView = Backbone.Epoxy.View.extend({
model: new Backbone.Model({firstName:"Luke", lastName:"Skywalker"}),
bindings: {
":el": "toggle:true",
"input.first-name": "value:firstName,events:['keyup']",
"input.last-name": "value:lastName,events:['keyup']"
}
});
Alternatively, you may choose to follow the popular convention of declaring bindings directly within the DOM using element attributes, at which time the bindings property should define the attribute name to query for. Epoxy specifies "data-bind" by default. All philosophical opinions aside, this technique works just as well as view-based declarations. Getting into philosophy, this method creates a bizarre (albeit handy) relationship between JavaScript mechanics and raw display. Ultimately, the choice is yours as to which method works best for your purposes.
View for attribute binding declarations:
var BindingView = Backbone.Epoxy.View.extend({
el: "#binding-view"
model: new Backbone.Model({firstName:"Luke", lastName:"Skywalker"}),
bindings: "data-bind"
});
DOM for attribute binding declarations:

First: <input type="text" data-bind="value:firstName,events:['keyup']">

Last: <input type="text" data-bind="value:lastName,events:['keyup']">

bindingSources
view.bindingSources
A hash table defining additional binding sources to be added to the view's binding context. Binding sources are instances of Backbone.Model and/or Backbone.Collection. By default, an Epoxy view configures two potential binding sources: the view's model and collection properties are automatically added to the binding context under the aliases $model and $collection. Additional model and collection data sources may be specified within the bindingSources hash; these additional data sources will be added into the binding context under the alias $sourceName.
Additionally, model data sources provide aliases to all of their attributes within the binding context. In the case of the default $model data source, all model attributes are aliased within the binding context using their normal attribute name. For additional model sources added through the bindingSources hash, model attributes are added under the alias source_attribute. This avoids attribute naming conflicts while binding multiple models of the same type.
// Epoxy view specifying five data sources:
var BindingView = Backbone.Epoxy.View.extend({
model: new Backbone.Model({name: "Luke Skywalker"}),
collection: new Backbone.Collection(),
bindingSources: {
han: function() { return new Backbone.Model({name: "Han Solo"}) },
obiwan: function() { return new Backbone.Model({name: "Obi-Wan Kenobi"}) },
users: function() { new Backbone.Collection() }
}
});
// Resulting binding context (psudocode):
{
$model: <Backbone.Model>,
$collection: <Backbone.Collection>,
$han: <Backbone.Model>,
$obiwan: <Backbone.Model>,
$users: <Backbone.Collection>,
name: <$model.name>,
han_name: <$han.name>,
obiwan_name: <$obiwan.name>
}
A note about Collection sources: Epoxy bindings do not register a "change" event on collection sources to avoid generally superfluous updates. Instead, you may manually trigger an "update" event on a collection source to refresh its bindings.
computeds
view.computeds
A hash table defining a view's computed properties. Computed view properties act as custom data routers: they assemble custom values from data available in the binding context, and route formatted values. While this is conceptually similar to computed model attributes, computed view properties are unique in that they do not store their own data, nor do they trigger any events; they simply act as pass-throughs for modifying context data using the view's getBinding and setBinding API methods. Computed view properties are an excellent place to assemble view-specific display values and/or markup.
Computed view properties may be declared with a computed params object, or as a getter function (uses automatic dependency mapping). Computed view functions are called in the context of the view, so referencing this refers to the parent view.
var MyView = Backbone.Epoxy.View.extend({
el: "#my-view",
computeds: {
priceParams: {
deps: ["price"],
get: function( price ) {
return "$"+ price;
},
set: function( value ) {
this.setBinding("price", value.replace("$", ""));
}
},
welcomeGetter: function() {
var name = this.getBinding("firstName");
return name ? "Welcome back, "+name : "Hello!";
}
}
});
When declaring a computed view property using a params object, the following options may be provided:
- get: Required function; invoked in context of the view. This getter function assembles its value based on other data in the view context, then returns the generated value. If a deps option is also specified, then the dependency values are mapped and injected as arguments into the getter function. If dependencies are not manually specified, then the getBinding method must be used for data access (for automatic dependency mapping).
- [deps]: Optional array. An array of context attribute names that the getter function depends on. When provided, these dependency values will be mapped and injected as arguments into the getter function.
- [set]: Optional function; invoked in context of the view. A function that receives an input value for storage. The set method provides no protocol for data storage – storage is entirely dependent on your setter implementation. Use setBinding to write data into view sources. Computed view properties declared without a set function are read-only.
Automatic dependency mapping with computed views
Like computed model attributes, computed view properties must map dependencies between view bindings and their underlying data values to keep the display in sync. You may manually declare dependencies using a params object (see above), or use the following guidelines for automatic dependency mapping:
- When getting and/or setting data within a computed function, always use the getBinding and setBinding view methods to make sure context data is mapped while being accessed. Getting and setting data through other protocols (such as direct model access) will fail to map dependencies.
- Keep getBinding and setBinding calls outside of conditional logic blocks. Conditional logic may prevent mapping methods from being reached, therefore it's safest to collect mapped values into local variables before performing conditional logic with them.
getBinding
view.getBinding(attribute)
Gets data through the view's binding context. The getBinding method may request any data attribute name available to binding declarations. This applies to data sources (referenced as "$source"), model attributes (referenced as "attribute" or "source_attribute"), and computed view properties.
remove
view.remove()
Override wrapper for the Backbone Views's native remove method. This override calls removeBindings, then defers to the Backbone View's native remove method.
removeBindings
view.removeBindings()
Removes and cleans up all bindings applied to the view. All binding hooks will be nullified, leaving the view's DOM elements formatted in their final bound state. The removeBindings method is automatically called with the remove method. Be mindful that you should manually call removeBindings when deprecating an Epoxy view without specifically calling its remove method.
setBinding
view.setBinding(attribute, value)
Sets data through the view's binding context. The setBinding method may submit data to any model attribute name available to binding declarations. The submitted data value will pass through binding context routers for storage in the connected data model.
setterOptions
view.setterOptions
Specifies an options object to be passed into all bound setters within the view. This equates to calling model.set({attrs}, {options}) in two-way bindings. Additionally, you may define an Epoxy-specific {save:true} option to have bound setters write to the model via the save method rather than with set (setterOptions will also be passed into the save method).
viewModel
view.viewModel
References a model for storing view-specific data. This may be an instance of Backbone.Model or Epoxy.Model, and may be passed into the view through constructor options. A view model instance and all of its attributes will be added to the view's binding context for use in bindings. While there is nothing exceptionally unique about this model instance, it offers a compositional benefit for organizing stateful and operational data within a view structure.
View Binding Handlers
Binding handlers are used to interchange model data with elements in the view. The Epoxy View includes default binding handlers for common tasks such as managing a bound element's content, class, and style. However, don't feel limited to just Epoxy's out-of-the-box binding handlers. You may easily define your own binding handlers within a view.
One or more binding handlers may be applied to an element as a comma-separated properties list (here shown using DOM attribute bindings):

In the above example, "text:" and "attr:" are binding handlers, while "linkText" and "linkUrl" are the bound model attributes assigned to them. In the case of the "attr" handler, its value is a hash of attribute names, each with an associated model value.
Be aware that binding declarations are parsed as JavaScript Object bodies, therefore a binding declaration must conform to proper JavaScript syntax. To give due credit, Epoxy's binding system is modeled after the clever technique used in Knockout.js. However, Epoxy deliberately limits some of Knockout's free-form binding allowances, such as inline concatenation (which becomes overly technical within the presentation layer, IMHO). If you're coming from Knockout, don't expect to write as much inline binding JavaScript.
attr
read-onlydata-bind="attr:{name:modelAttribute,'data-name':modelAttribute}"
Binds model attribute values to a list of element attributes. Attribute bindings are defined as a hash of key/value pairs, where each key defines an element attribute and the model reference defines the attribute value. Attribute keys may be defined as strings.
checked
read-writedata-bind="checked:modelAttribute"
Binds checkbox and radio elements to the model. The binding behavior differs slightly for various element/value combinations:
- Radios: a bound radio element will become checked when the element's value matches the bound model attribute. Checking a radio will set its value to the bound model attribute.
- Checkbox arrays: when a checkbox element is bound to an Array model attribute, the element will be checked while its value exists within the value array, and unchecked while its value is absent from the array. Likewise, toggling the element's checked property will add and remove its value from the bound array. Keep in mind that arrays modified within a native Backbone.Model will NOT trigger a "change" event unless the array instance is changed. Using an Epoxy.Model computed will help here by managing object copies, and by performing array comparisons by content.
- Checkbox toggles: when a checkbox element is bound to a primitive model attribute (types String, Boolean, or Number), the element will be checked based on a loosely-typed assessment of the model attribute's truthiness. When the element's "checked" status is toggled, it will submit a Boolean value back to the model attribute.
classes
read-onlydata-bind="classes:{active:modelAttr,'is-active':modelAttr}"
Toggles a list of element class names based on the truthiness of their bound model attributes. Class bindings are defined as a hash of key/value pairs, where each key defines a class name and is value references a model attribute that will be loosely-type checked for truthiness; truthy attributes will enable their class, while falsey attributes will disable their class. Class name keys may be defined as strings.
collection
read-onlydata-bind="collection:$collectionSource"
Manages the display of a Backbone.Collection. The bound collection must specify a Backbone.View constructor for displaying its models, at which time the collection handler will manage adding, removing, resorting, and resetting a list of those views to synchronize the display of the collection's contents. The collection binding performs discrete view management, where collection models will be assigned a single view instance for their lifespans, rather than re-rendering all collection views in response to changes. You may choose to use an Epoxy.View constructor for the display of individual collection items, allowing each collection view item to bind to its respective model.
The collection binding requires the following setup:
- The binding must target a Backbone.Collection data source available within the binding context.
- The bound view must provide a property called itemView, which defines a Backbone.View constructor for rendering collection items. This item will receive a collectionView option when constructed that references the parent view.
// View for individual collection items:
var ListItemView = Backbone.View.extend({
tagName: "li",
initialize: function() {
this.$el.text( this.model.get("label") );
}
});
// Collection defining a Model and View:
var ListCollection = Backbone.Collection.extend({
model: Backbone.Model
});
// Binding view for list of collection items:
var ListView = Backbone.Epoxy.View.extend({
el: "

",
itemView: ListItemView,
initialize: function() {
this.collection = new ListCollection();
this.collection.reset([{label: "Luke Skywalker"}, {label: "Han Solo"}]);
}
});
var view = new ListView();
Note that the collection binding does not register a "change" event on its collection to avoid generally superfluous updates. Instead, you may manually trigger an "update" event on the collection to refresh its bindings. For a working demonstration of the collection binding, see the Epoxy ToDos demo.
css
read-onlydata-bind="css:{color:modelAttribute,'font-size':modelAttribute}"
Binds a list of CSS styles to model attributes. CSS style bindings are defined as a hash of key/value pairs, where each key defines a CSS style name and the model attribute defines the style's literal value. CSS keys may be defined as strings.
disabled
read-onlydata-bind="disabled:modelAttribute"
Toggles a form element's "disabled" property based on a loosely-typed assessment of the bound model attribute's truthiness. A truthy value disables the element (inversion of the enabled handler).
enabled
read-onlydata-bind="enabled:modelAttribute"
Toggles a form element's "disabled" status based on a loosely-typed assessment of the bound model attribute's truthiness. A truthy value enables the element (inversion of the disabled handler).
events
read-onlydata-bind="events:['keydown','focus']"
The events handler is a special binding used to parameterize what DOM events will trigger changes for read-write element bindings. By default, all read-write bindings will subscribe to their bound element's "change" event to trigger model updates. You may bind additional DOM event triggers for the element by listing them in the events array.
html
read-onlydata-bind="html:modelAttribute"
Sets the element's HTML content to the bound model attribute value. Uses the jQuery html method.
options
read-onlydata-bind="options:arraySource"
Binds a <select> element's options to an array data source. The bound data source may be an Array object, or a Backbone.Collection instance from which the models array will be used. Array contents may be formatted using one of the following methods:
- ["Luke", "Han", "Leia"] : Primitives list. Given an array of primitives, options will be created using the array values as both the text and value for each option.
- [{label:"Luke", value:"1"}, {label:"Leia", value:"2"}] : Label/value pairs. Given an array of objects, options will be created using each object's label and value properties as the text and value of each option. These property names may be adjusted globally through binding config.
- Backbone.Collection : Models list. The collection's models array will be used as the array source. Options will be created using each model's label and value attributes as the text and value of each option. These attribute names may be adjusted globally through binding config. An Epoxy.Model may be used to virtualize these values as computed/computed attributes if needed. Note that the options binding does not register a "change" event on its collection to avoid generally superfluous updates. Instead, you may manually trigger an "update" event on the collection to refresh its bindings.
defaults: {
list1: ["Luke"],
list2: [{label:"Luke", value:"0"}],
list3: new Backbone.Collection( {models:[{label:"Luke", value:"0"}]} )
}
// list1: <option value='Luke'>Luke</option>
// list2: <option value='0'>Luke</option>
// list3: <option value='0'>Luke</option>
To manage a <select> element's default first option and/or empty state, you may choose to also include the optionsDefault and/or optionsEmpty helper bindings.
optionsDefault
read-onlydata-bind="options:opts,optionsDefault:modelAttribute"
Defines a default option made available at the top of a <select> element in addition to the options list. This binding must be used in tandem with the options binding. The optionsDefault value will appear as the first and/or only item in the select, regardless if the options list has content. The optionsDefault value may be formatted using one of the following methods:
- "Default Value" : Given a primitive value (string, number, or boolean), the default option will be created using the primitive as both text and value of the option.
- {label:"Default", value:""} : Given an object, the default option will be created using the object's label and value properties as the text and value of the option.
- Backbone.Model : Given a Backbone Model, the default option will be created using the model's label and value attributes as the text and value of the option. An Epoxy.Model may be used to virtualize these as computed/computed attributes if needed.
defaults: {
default1: "Choose...",
default2: {label:"Choose...", value:""},
default3: new Backbone.Model({label:"Choose...", value:""})
}
// default1: <option value='Choose...'>Choose...</option>
// default2: <option value=''>Choose...</option>
// default3: <option value=''>Choose...</option>
You may also choose to declare optionsDefault as a static object within a binding declaration, as in:
data-bind="value:val,options:opts,optionsDefault:{label:'Choose...', value:''}"
optionsEmpty
read-onlydata-bind="options:opts,optionsEmpty:modelAttribute"
Defines a placeholder option to apply to an empty <select> element, and automatically disables the select element while displaying this placeholder. This must be used in tandem with the options binding, and is generally only needed when there is no default option. The empty placeholder option may be formatted using one of the following methods:
- "Placeholder Value" : Given a primitive value (string, number, or boolean), the placeholder option will be created using the primitive as both text and value of the option.
- {label:"None", value:""} : Given an object, the placeholder option will be created using the object's label and value properties as the text and value of the option.
- Backbone.Model : Given a Backbone Model, the placeholder option will be created using the model's label and value attributes as the text and value of the option. An Epoxy.Model may be used to virtualize these as computed/computed attributes if needed.
defaults: {
empty1: "None",
empty2: {label:"None", value:""},
empty3: new Backbone.Model({label:"None", value:""})
}
// empty1: <option value='None'>None</option>
// empty2: <option value=''>None</option>
// empty3: <option value=''>None</option>
You may also choose to declare optionsEmpty as a static object within a binding declaration, as in:
data-bind="value:val,options:opts,optionsEmpty:{label:'none', value:''}"
template
read-onlydata-bind="template:$source"
The template binding extracts its element's HTML content while initializing, and then parses that content into an Underscore template using the bound data. You have some options on how both the template string and the bound data sources are defined.
Defining the template string
When the template binding initializes, it will extract content from its element to use as the template string. However, to safeguard against malformed HTML within the DOM, the template binding will first search its element for a

<template><%= firstName %> <%= lastName %></template>

If a


#* If required, the server may render this HTML page in an end-user's browser to obtain user's consent for IdP-initiated SLO. *# #set( $messageKeyPrefix = "idp.slo.confirm.page.template." ) #if ($cancelled) #set( $title = "title.cancelled" ) #else #set( $title = "title" ) #end