Håller förnärvarande på med examensarbete på C-nivå med Qben, det går framåt även om det känns som att vi har slackat en hel del men vi kommer bli klara, no doubt!

Min (nya) relation till Javascript

Min relation till JavaScript har förändrats en hel del sedan den första kursen inom det, och nu känner jag att jag inte enbart kommer använda det genom jQuery för animeringar och effekter.

Efter att ha spenderat den här läsperioden med Backbone så har det faktiskt blivit en god kompanjon inom webbutvecklingen. Jag har implementerat ett antal olika applikationer efter att ha skrivit klart min Todo applikation för kursen, bland andra så har jag skrivit en egen kontakt applikation som finns här och så har jag skrivit ett antal andra ”lek” applikationer bara för att lära mig använda Backbone ännu mer.

Jag har även experimenterat en del med att använda MongoDB (Hosting lösning från MongoHQ) där jag lärde mig hur man kan implementera ett ”mini-api” i PHP för att CRUD mot en bakomliggande databas. Det som förvånade mig mest med detta var hur enkelt det var att implementera användandet av en bakomliggande databas i modellerna/collectionerna, endast en url egenskap behövdes sättas och så fick PHP sköta resten. Det som underlättade ännu ett snäpp till var att Backbone automatiskt skickade rätt HTTP headers (GET, POST, PUT, DELETE) så att man endast behövde kolla vilken request typ headern bestod av för att kunna utföra de olika CRUD funktionerna. Mycket Smidigt!

Kursen

Jag tycker att kursen har varit väldigt rolig, främst så har det varit väldigt givande för min relation mot Javascript men den har även hjälpt mig förstå kraften med att planera och identifiera objekt, metoder, moduler och funktioner inom en applikation innan själva implementeringen drar igång. Detta såg jag som en klar fördel, eftersom det klart blev enklare att veta hur allting skulle fungera och hur applikationen som helhet skulle se ut.

Kontakten med David har varit väldigt god, vi har flera gånger spenderat lång tid med långa samtal kring buggar, funderingar, lösningar osv. Och i vissa fall har vi båda nästan blivit skalliga hehe.

Sammanfattning

Kursen har gett mig mycket, både i planeringsstadiet och själva implementationsstadiet. Det jag känner har varit mest givande är min nya relation med Javascript och den kommer jag att fortsätta utveckla i framtiden så mycket jag bara kan, bara baka ihop allting jag kan och skapa något jag verkligen kan vara stolt över.

Min tanke är att använda mig utav Addy Osmanis TodoMVC projekt som är en Todo-applikation skriven i många olika ramverk och tekniker inom JavaScript. Du kan kika på projektet här. Det är fler utvecklare inblandade i projektet men Addy är lead.
Tanken är helt enkelt att jämför de olika implementationerna mellan hur applikationen är implementerad i Backbone och Spine. Jag kommer inte fördjupa mig någonting i Hur Spine används utan enkelt försöka förklara skillnaderna i varje Modell, Vy och Controller på en grundläggande nivå.

Eftersom SpineJS är CoffeScript så passar det bra att nämna min grundläggande artikel om CoffeScript.

Modell

Vi börjar med att kika på vad det är för skillnad på modellerna i Backbone respektive Spine.

Model i Backbone

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

var Todo = Backbone.Model.extend({
 
    // Default attributes for the todo.
    defaults: {
      content: "empty todo...",
      done: false
    },
 
    // Ensure that each todo created has `content`.
    initialize: function() {
      if (!this.get("content")) {
        this.set({"content": this.defaults.content});
      }
    },
 
    // Toggle the `done` state of this todo item.
    toggle: function() {
      this.save({done: !this.get("done")});
    },
 
    // Remove this Todo from *localStorage* and delete its view.
    clear: function() {
      this.destroy();
    }
 
  });

Model i Spine (Tyvärr så har itne WP-Syntax stöd för CoffeScript)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class window.Task extends Spine.Model
  @configure 'Task', 'name', 'done'
  @extend Spine.Model.Local
 
  validate: ->
    'Task name is required' unless $.trim(@name)
 
  @active: ->
    @select (task) -> !task.done
 
  @done: ->
    @select (task) -> !!task.done
 
  @destroyDone: ->
    task.destroy() for task in @done()

Backbone modellen ser ganska identisk ut med hur vi har gjort under kursen med våra egna applikationer så där behöver väl jag inte nämna någonting speciellt, förutom ett annat sätt att sätta default-värden på modellerna vilket jag inte visste att man kunde göra på detta vis. Vi kan även notera här att @ används istället för att this (t.ex. this.egenskap => @egenskap). Även om syntaxen verkar vara lite klurig att läsa/förstå så går det enkelt när man har läst på om hur CoffeScript fungerar och dess syntax.

Router/Controller

Vad jag kan se i Backbone implementationen av Todo applikationen så finns det ingen router, så denna kan jag inte göra någon jämförelse mot, däremot kan jag nämna att SpineJS använder sig utav controllers.

app.coffe – Huvudcontroller för applikationen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

class TaskApp extends Spine.Controller
  elements:
    '.items':                         'tasks'
    '.countVal':                      'counter'
    'a.clear':                        'clearCompleted'
    'form#new-task input[name=name]': 'newTaskName'
 
  events:
    'submit form#new-task': 'new'
    'click a.clear':        'clearCompleted'
 
  constructor: ->
    super
    Task.bind 'create', @renderNew
    Task.bind 'refresh', @renderAll
    Task.bind 'refresh change', @renderCounter
    Task.bind 'refresh change', @toggleClearCompleted
    Task.fetch()
 
  new: (e) ->
    e.preventDefault()
    Task.fromForm('form#new-task').save()
    @newTaskName.val('')
 
  renderNew: (task) =>
    view = new Tasks(task: task)
    @tasks.append view.render().el
 
  renderAll: =>
    Task.each @renderNew
 
  renderCounter: =>
    @counter.text Task.active().length
 
  toggleClearCompleted: =>
    if Task.done().length
      @clearCompleted.show()
    else
      @clearCompleted.hide()
 
  clearCompleted: ->
    Task.destroyDone()
 
 
$ ->
  new TaskApp(el: $('#tasks'))

Efter att ha kikat på koden en snabbis så framgår det att upplägget för applikationen i både Backbone och Spine är väldigt likt. Controllern börjar med att definera vilka element som den ska använda sig utav, definerar events och har en constructor (motsvarighet till Backbones initialize) där han binder event för Task-objektet (De verkar inte finns någon motsvarighet till Backbone collections i Spine). Sedan är det helt vanliga funktioner enligt vanlig Backbone standard kan man säga. Vad jag kan se så händer det inget här som man inte kan förstå. Det ända jag kan notera i controllern är att den faktiskt mer liknar en Backbone vy än en Backbone router.

Vyer

Vi vet alla hur en vy i Backbone ser ut, men för att förenkla jämförelsen så kommer AppView:n här.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

// Our overall **AppView** is the top-level piece of UI.
  var AppView = Backbone.View.extend({
 
    // Instead of generating a new element, bind to the existing skeleton of
    // the App already present in the HTML.
    el: $("#todoapp"),
 
    // Our template for the line of statistics at the bottom of the app.
    statsTemplate: _.template($('#stats-template').html()),
 
    // Delegated events for creating new items, and clearing completed ones.
    events: {
      "keypress #new-todo":  "createOnEnter",
      "keyup #new-todo":     "showTooltip",
      "click .todo-clear a": "clearCompleted",
      "click .mark-all-done": "toggleAllComplete"
    },
 
    // At initialization we bind to the relevant events on the `Todos`
    // collection, when items are added or changed. Kick things off by
    // loading any preexisting todos that might be saved in *localStorage*.
    initialize: function() {
      _.bindAll(this, 'addOne', 'addAll', 'render', 'toggleAllComplete');
 
      this.input = this.$("#new-todo");
      this.allCheckbox = this.$(".mark-all-done")[0];
 
      Todos.bind('add',     this.addOne);
      Todos.bind('reset',   this.addAll);
      Todos.bind('all',     this.render);
 
      Todos.fetch();
    },
 
    // Re-rendering the App just means refreshing the statistics -- the rest
    // of the app doesn't change.
    render: function() {
      var done = Todos.done().length;
      var remaining = Todos.remaining().length;
 
      this.$('#todo-stats').html(this.statsTemplate({
        total:      Todos.length,
        done:       done,
        remaining:  remaining
      }));
 
      this.allCheckbox.checked = !remaining;
    },
 
    // Add a single todo item to the list by creating a view for it, and
    // appending its element to the `<ul>`.
    addOne: function(todo) {
      var view = new TodoView({model: todo});
      this.$("#todo-list").append(view.render().el);
    },
 
    // Add all items in the **Todos** collection at once.
    addAll: function() {
      Todos.each(this.addOne);
    },
 
    // Generate the attributes for a new Todo item.
    newAttributes: function() {
      return {
        content: this.input.val(),
        order:   Todos.nextOrder(),
        done:    false
      };
    },
 
    // If you hit return in the main input field, create new **Todo** model,
    // persisting it to *localStorage*.
    createOnEnter: function(e) {
      if (e.keyCode != 13) return;
      Todos.create(this.newAttributes());
      this.input.val('');
    },
 
    // Clear all done todo items, destroying their models.
    clearCompleted: function() {
      _.each(Todos.done(), function(todo){ todo.clear(); });
      return false;
    },
 
    // Lazily show the tooltip that tells you to press `enter` to save
    // a new todo item, after one second.
    showTooltip: function(e) {
      var tooltip = this.$(".ui-tooltip-top");
      var val = this.input.val();
      tooltip.fadeOut();
      if (this.tooltipTimeout) clearTimeout(this.tooltipTimeout);
      if (val == '' || val == this.input.attr('placeholder')) return;
      var show = function(){ tooltip.show().fadeIn(); };
      this.tooltipTimeout = _.delay(show, 1000);
    },
 
    toggleAllComplete: function () {
      var done = this.allCheckbox.checked;
      Todos.each(function (todo) { todo.save({'done': done}); });
    }
 
  });

En helt vanlig Backbone vy.

Nu blir det lite repetition här men det är för att (som jag nämnde ovan) att controllers i Spine verkar fungera som vyer också. Nedan kommer samma controller som ovan:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

class TaskApp extends Spine.Controller
  elements:
    '.items':                         'tasks'
    '.countVal':                      'counter'
    'a.clear':                        'clearCompleted'
    'form#new-task input[name=name]': 'newTaskName'
 
  events:
    'submit form#new-task': 'new'
    'click a.clear':        'clearCompleted'
 
  constructor: ->
    super
    Task.bind 'create', @renderNew
    Task.bind 'refresh', @renderAll
    Task.bind 'refresh change', @renderCounter
    Task.bind 'refresh change', @toggleClearCompleted
    Task.fetch()
 
  new: (e) ->
    e.preventDefault()
    Task.fromForm('form#new-task').save()
    @newTaskName.val('')
 
  renderNew: (task) =>
    view = new Tasks(task: task)
    @tasks.append view.render().el
 
  renderAll: =>
    Task.each @renderNew
 
  renderCounter: =>
    @counter.text Task.active().length
 
  toggleClearCompleted: =>
    if Task.done().length
      @clearCompleted.show()
    else
      @clearCompleted.hide()
 
  clearCompleted: ->
    Task.destroyDone()
 
 
$ ->
  new TaskApp(el: $('#tasks'))

Det finns även en till controller i Spine applikationen som definerar en controller för varje task-object, som fasktiskt verkar användas som en vy här innuti renderNew funtionen. Jag hade nog mer valt att kalla den för en sorts partiel vy, men det är nog för att jag kommer från Backbone och hade säkerligen tyckt att Backbone gör det konstigt om jag kommit från Spine.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

class window.Tasks extends Spine.Controller
  ENTER_KEY  = 13
  ESCAPE_KEY = 27
 
  elements:
    'form.edit': 'form'
 
  events:
    'click a.destroy':            'remove'
    'click input[type=checkbox]': 'toggleStatus'
    'dblclick .view':             'edit'
    'keypress input[type=text]':  'finishEditOnEnter'
    'blur input[type=text]':      'finishEdit'
 
  constructor: ->
    super
    @task.bind 'update', @render
    @task.bind 'destroy', @release
 
  render: =>
    @replace $('#task-template').tmpl(@task)
    this
 
  remove: ->
    @task.destroy()
 
  toggleStatus: ->
    @task.updateAttribute 'done', !@task.done
 
  edit: ->
    @el.addClass('editing')
    @$('input[name=name]').focus()
 
  finishEdit: ->
    @el.removeClass('editing')
    @task.fromForm(@form).save()
 
  finishEditOnEnter: (e) ->
    if e.keyCode in [ENTER_KEY, ESCAPE_KEY] then @finishEdit()

Här känner jag även att, med utgångspunkt från min Todo-applikation, att det här borde finnas direkt på modellen och inte på en controller/vy. Men allt beror självklart på hur man väljer att implementera sin applikation.

Slutsats

Efter att ha läst på, och skrivit en artikel om grunderna i CoffeScript, och sedan kikat igenom koden för Backbone respektive Spine så känner jag att implementationerna är nästan identiska med varandra. Detta kanske beror på att de är skriva av samma person/personer men jag trodde faktiskt först att det skulle vara större skillnad syntax och struktur mässigt än vad det faktiskt var.

Jag känner att man blir lite små förvirrad över vad som egentligen är en vy och vad som är en controller i Spine, kanske faller det på valet av hur applikationen är implementerad men jag blev lite förvirrad just när det gäller dessa två typer av objekt. Enligt den här implementationen så framgår det ganska klart och tydligt att controller är en typ controller och vy, och att det inte direkt finns någon uppdelning av dessa.

Med en del Backbone kunskap och en grundläggande överblick över hur CoffeScript fungerar så kan jag klart och tydligt se att Spine implementationen klart är mycket mer lättläst och enklare att förstå. Detta beror antagligen mest på skillnaden i hur syntax ser ut i CoffeScript som Spine är skrivet i, det ger klara fördelar om man kan syntaxen, framför allt så sparar det en hel del tråkiga klammrar och långa filer.

Jag kommer nog definitiv att kika mer på Spine/CoffeScript och börja skriva applikationer i detta språk, men först måste jag få upp en fungerande Node server som inte riktigt gick som jag tänkt förra gången jag försökte mig på detta.

I den här artikeln så tänkte jag bara gå igenom skillnaderna mellan CS och JavaScript, mest för utbildningssyfte men även som en fördjupning av min jämförelse mellan Todo Backbone och Todo SpineJS (Som är skrivet i CS).

Ett måste för att kunna kompilera CS är NodeJS. Jag kommer endast att gå igenom lite grundläggande syntax i CS så som variabler, funktioner, loopar, object, arrayer och villkorliga tilldelningar (If, else.. ).

CoffeScript

CoffeScript, tillskillnad från vanlig JavaScript, använder sig utan mellanslag (whitespace) för att avgränsa kod block. Man behöver inte använda sig utav semikolon (;) för att avsluta rader, och måsvingar/klammerparanteser {} blir ett minneblott då man istället använder sig av indentering. CS är helt enkelt mycket enklare att läsa utan massa kodblock med konstiga klammrar och indenteringar.

Funktioner

Alla vet vi väl hur det ser ut när man definerar en funktion i JavaScript, om inte så kommer en påminnelse här.

1
2
3
4
5
6
7
8
9

var cube, square;
 
square = function( x ) {
    return x * x;
}
 
cube = function( x ) {
    return square( x ) * x;
}

Förstår du inte detta, så har du nog kommit helt fel. Men, hur definerar jag samma funktion i CS? Jo då, så här:

1
2
3
4
5

square = ( x ) ->
    x * x
 
cube = ( x ) ->
    square( x ) * x

Ganska simpelt va? Sparar en del onödiga tecken i källkoden, även om den automatiskt kommer kompileras till vanliga javascript för använding.

Default värden för funktioner har man tidigare behövt skriva på de sättet att man först kollar om det variablen inte är null, om den är det så sätter man ett default värde, i CS är det enklare och fungerar så här:

1
2

orderDrink = ( sizeOfCup, drink = "coffe" ) ->
    "I would like a #{sizeOfCup} with #{drink}"

I princip identiskt med hur man skulle sätta ett default värde i t.ex. PHP. Notera även sättet att skriva ut variabler i strängar.

Objekt och arrayer

Objekt och arrayer fungerar likadant som vanligt i JavaScript, så det här borde inte vara allt för svårt att förstå.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Array
playlist = ["Rededication to my Ex", "Mo money mo problems"]
 
// Objekt
albums = { Lloyd : "Untitled", BIG : "Life after death" }
 
// Du beöver inte använda dig utav komma (,) när du definerar element
// i arrayer eller objekt, det går lika bra med whitespace.
numbers = [
    1, 0, 0, 1
    0, 0, 0, 1,
    1 1 1 0
]
 
// Ytterliggare objekt.
artists = 
    Tupac:
        album : 'All eyes on me'
        year : 1996
        label : 'Death Row Records'
    Game:
        album : 'The R.E.D Album'
        year : 2011
        label : 'Geffen/Aftermath'

Villkorliga tilldelningar

Det mesta i CoffeScript är verkligen lättläst, speciellt if..else-satser.

1
2
3
4
5
6

mood = topOfTheWorld if finished
 
if finished and topOfTheWorld
   goBuyABeer()
else
   tryAgain()

Det måste vara en av de kortaste if satserna jag sett! Nedan följer motsvarigheten i ren JavaScript. Skillnaden i läsbarheten är verkligen enorm.

1
2
3
4
5
6
7
8
9
10
11
12

var mood, topOfTheWorld, finished;
 
if ( finished ) {
    mood = topOfTheWorld;
}
 
if ( finished && topOfTheWorld ) {
    goBuyABeer();
}
else {
    tryAgain()
}

Loopar

Vi alla vet hur jobbiga, i vissa fall, utmannande For-loopar kan vara, men vet ni vad? De blir också enklare i CoffeScript.

1
2
3
4
5
6
7
8

// Loopa igenom food och skicka till eat() för varje element i 
 
arrayen. 
eat food for food in ['cerial', 'cheese', 'wine']
 
// Loopa igenom måltider och plugga på i, skicka till menu()
courses = ['greens', 'caviar', 'truffles', 'roast']
menu i + 1, dish for dish, i in courses

Operatorer och alias

För att läsa mer om de olika operationerna och aliasen som finns i CoffeScript, besök den här sidan.

Slutsats

Nu har jag inte gått in på djupet och undersökt exakt hur CS fungerar, men jag hoppas i alla fall att ni har fått en hum om vad det går ut på och hur enkelt och lättläst det är. Nu har jag endast skrapat lite på ytan och inte kikat på några större applikationer skrivna i CS men det är därför jag har skrivit den här artikeln, för att bilda mig en grundläggande förståelse över syntaxen och hur den användas. Nu ska denna lärdom appliceras genom att Todo SpineJS av Addy Osmani ska undersökas, och jämföras med samma applikation i Backbone.

Källa: coffescript.org

Försökte få upp en NodeJS server på min windows maskin men tyvärr så får jag bara fram ‘Undefined’ hur jag än försöker så kanske har jag gjort någonting fel? Det återstår att se men ska försöka fördjupa mig inom Addy Osmanis TodoMVC. Då specifik inriktat på skillnaden mellan Todo applikationen i Backbone och Spine.

Tagit bort ”överlödiga” jquery selectorer och lagt dess i create direkt istället.

‘artistAdded’-eventet har jag ändrat eftersom du inte behöver en artistModel där, eller du använder den inte i vilket fall.

Ändrat sättet du skickar in din artistCollection till newArtist-vyn. Efterosm du endast hanterar en collection i denna vy så är det rekommenderat att använda { collection : this.artistCollection } i denna istället för att behöva skapa en egen definerad variabel.

Hela pull requesten kan ses här.

Innehåll:

1. Planering
2. Implementation
• Backbone & Underscore
• Events – It’s tricky.. sometimes
3. localStorage
4. Kollaborering
5. slutsats

Anledningen till att jag valde att göra en ”simpel” Todo applikation är för att det kändes som det enklaste sättet att lära sig ett nytt ramverk. Man får lära sig arbeta med vyer, events, CRUD och får en grundläggande förståelse för hur Backbone fungerar.

Planering

Planeringsstadiet i kursen kändes som ett bra moment, man fick tänka igenom alla objekt och funktioner innan man ens hade börjat koda någonting. Det är faktiskt väldigt ovanligt för mig som webbutvecklare som inte riktigt varit med i skarpa projekt och därför skippar planeringsstadiet i varje ”privat” projekt men jag ser klart fördelen med att göra detta och jag ska försöka bättra mig på den fronten.

Implementation

Nästa steg var att börja implementera min planerade applikation. Det var här problemen, självklart, började dyka upp. Först upplevde jag en hel del problem med att förstå hur require.js fungerar men att ha läst igenom Organizing your application using Modules (require.js) så klarnade det hela väldigt mycket faktiskt.

Backbone & Underscore

Nu gällde det bara att förstå sig på Backbone i sig, så där fick jag även spendera några timmar med att läsa på och testa olika implementationer för att få en bättre förståelse. Implementationen gick vidare och jag fick väldigt konstiga och kluriga buggar som både jag och David fick sitta och försöka lösa väldigt länge men felsökning är alltid roligt, i rimliga mått.

Events – It’s tricky.. sometimes

Det klurigaste, men även det smidigast när förståelsen var på plats, var helt klart events och hur man ska jobba med dessa. Det finns t.ex flera olika lösningar för att ta bort en modell som man klickat på, men vad är det smidigaste sättet? Jag valde att implementera en vy för varje enskild Todo som gjorde att jag kunde koppla ett klick event till det elementet som i sin tur gjorde att jag bara kunde köra this.model.destroy();

1
2
3

delete : function() {
  this.model.destroy();
}

localStorage

Jag använde mig utav localStorage som lagring för den här applikationen men har de senaste dagarna även hittat en, i brist på annan kunskap, lösning för att koppla på MongoDB som lagring genom att lägga en url-egenskap på modellen/collectionen som sedan går via ett php script för att hämta data från en MongoDB databas. Denna funktionalitet är inte implementerad i min applikationen utan testad för ”utbildningssyfte”. Eventuell vidare utveckling av applikationen är att implementera en lösning för att applikationen ska använda MongoDB för att spara data externt och när användaren är online, men samtidigt använda localStorage på varje enskild klient för att kunna köra applikationen offline med.

Kollaborering

Jag har ännu inte hunnit göra så mycket i kollaboreringsstadiet förutom det jag nämner i föregående inlägg – kollaborering – pollthingy, vilket var väldigt enkelt att implementera. Sen var det inte heller några större svårigheter att använda github för kollaboreringen, det fungerade väldigt smidigt och har fått mig att inse kraften i github, faktiskt så pass att jag hellre kör det nu än någon annan versionhanterings lösning som t.ex Google Code genom SVN.

Slutsats

Ja, då var vi här.. Allt som allt så har hela projektet varit roligt att genomföra, klurigt, utmanande men samtidigt väldigt givande. Det känns skönt att ha fördjupat sig lite mer i ett javascript ramverk för att lära sig göra ”riktiga” applikationer med det istället för att bara använda javascript för t.ex. valdering av formulär och lite snygga animeringar. Känns som att jag fick upp ögonen för javascript som ett programmeringsspråk ännu mer än tidigare, men det kommer nog aldrig riktigt ersätta kärleken för PHP eller ASP.NET.

Dock, så har jag faktiskt börjat skriva om mina senaste applikationer som t.ex Chatter i Backbone, men jag har ännu inte kommit speciellt långt i utvecklingen.

Summa summarum, Backbone, underscore, require kommer definitivt komma till användning i mina framtida applikationer.

Appen är en simpel men bra skriven Poll-app för att skapa egna polls.
De ändringar jag har implementerat i applikationen är:

Added validation to the PollModel and the AnswerModel.
Try-catch for validation on create view.
Validation errors show in alert-boxes.
Removed all cluttred conlogs across the application.
Changed the add method to the application from this.collection.add => this.collection.create because .add did not run the validate method.

Se pull request.

Att utföra en fork var vädligt enkelt, smidigt och genialt! Sedan var det vara att skapa ett lokalt repo för fork:en och så var man igång, precis som vanligt.

Även en pull request var jätte enkel att göra, genom webbgränssnittet på github så var det bara att klicka på pull request på sitt egna repo (en fork skapar ett eget repo av det ursprungliga repot) och skriva lite kommentarer och skicka iväg requesten. Riktigt smidigt och jag ska lätt börjar använda github mer och mer för egna projekt.

Har även gjort en hel del styling och färdigställt det mesta i applikationen. Det som är kvar är ett event som behöver triggas när en användare att markera en uppgift som completed, så behövs TaskCollection sorteras igen.

Inte så mycket kod att visa idag känner jag. Har även passat på och skriva dokumentationen för applikationen, som finns här, har även skrivit dit lite tips på framtida vidareutveckling inför nästa (läs nuvarande) steg i kursen.

1

    this.collection.bind( 'all', this.render, this );

Denna lösningen hittade jag efter lite sökande på nätet, jag har dock stött på den tidigare men inte velat använda den eftersom den faktiskt inte specificerar vilket typ av event och därför har jag sett det som ”fulkod”. Men nu får det fungerar som en nödlösning eftersom inget annat jag testat har fungerat.

Har även implementerat ett sätt att visualisera en todo som är Done. Detta enkelt genom att ett change event triggas på todon och ändrar helt enkelt css attributet background.