Page 3

Editing a Note

So far, 100% of the interaction between the Model and View has been through the Controller’s listeners, but editing a note is going to happen a bit differently. Remember the comment I made at the end of the last page about loadNote()? When a new note is loaded – both when the app initializes and when adding new notes – a Note object is passed straight into the View’s loadNote() function:

this.loadNote = function(note){
    var dom = doms.get(note.getId());
        // build a new note item
        // and put it in the list
        dom = new $.NoteLI(note, that.showEditForm);
        doms.put(note.getId(), dom);

When that Note is loaded into the View, it’s stored in the NoteLI object that will represent that note in the UI’s list. The benefit to keeping a hold of that Note object is that when the edit form is submitted we can simply tell that Note object to update itself with new values:

function submitEditForm(){
    var note_id = $editform.find("#noteId").val();
    var dom = doms.get(parseInt(note_id));
    var subj = $editform.find(".subject").val();
    var body = $editform.find(".body").val();
    if(subj.length == 0){
        alert("Please enter a subject for your note");
        return false;
    return false;

That same Note object that was passed to the View in loadNote() is being edited on lines 84-86! And line 86 is what tells that Note to save itself to the DB. Let’s dive into that function and find out how that happens.

this.confirm = function(){

Pretty simple – the Note just tells the Model to update the Note, and that updateNote() function looks eerily similar to the addNote() function in the Model:

this.updateNote = function(note){
        url: 'ajax.php',
        data : { edit : true, 
                 note_id : note.getId(),
                 subject : note.getSubject(),
                 body : note.getBody() },
        type: 'POST',
        dataType: 'json',
        timeout: 1000,
        error: function(){
        success: function(data){
            if(data.error) return that.notifySavingFailed(note);

The Model runs through the exact same rigamarole as when adding a new Note: notify listeners, fire off an AJAX call, and notify listeners again when the response comes back.


So why didn’t we use the listener pattern to edit a note? I suppose we could have swapped out line 86 of the submitEditForm() to be a notify() function, instead of a confirm() function on the Note itself, and in all honesty that would have been a fine approach. I opted for the confirm() function on the Note object to make it more obvious that that exact Note object is changing – none other. the notify() functions that are written are either adding or removing notes, and Note objects are either created or destroyed. I didn’t want to confuse the issue that an edited Note by be replaced by some other one that’d be loaded in, but in the end, it’s a matter of preference.

So now the looming question is “but what happens when the AJAX for the edit fails? How do we recover?” And that’s the topic of the next page: When AJAX Fails.

Leave a Reply

Your email address will not be published. Required fields are marked *