08-editing-posts.md.erb

---
title: Post 수정
slug: editing-posts
date: 0008/01/01
number: 8
contents: post를 수정하는 폼을 추가한다.|수정 권한을 설정한다.|수정될 수 있는 속성을 제한한다.
paragraphs: 29
---

이제 우리는 post를 등록할 수 있다. 다음 단계는 이들을 수정하고, 삭제하는 것이다. 이를 처리하는 UI 코드는 비교적 단순하니, 이 시점에서 미티어의 사용자 권한 제어방식에 대하여 알아보자.

먼저 라우터를 열어보자. Post 수정 페이지에 접근하는 route를 추가하고 그 데이터 컨텍스트를 설정한다:

~~~js
Router.configure({
  layoutTemplate: 'layout',
  loadingTemplate: 'loading',
  waitOn: function() { return Meteor.subscribe('posts'); }
});

Router.map(function() {
  this.route('postsList', {path: '/'});

  this.route('postPage', {
    path: '/posts/:_id',
    data: function() { return Posts.findOne(this.params._id); }
  });

  this.route('postEdit', {
    path: '/posts/:_id/edit',
    data: function() { return Posts.findOne(this.params._id); }
  });

  this.route('postSubmit', {
    path: '/submit'
  });
});

var requireLogin = function() {
  if (! Meteor.user()) {
    if (Meteor.loggingIn())
      this.render('loading')
    else
      this.render('accessDenied');
  
    this.stop();
  }
}

Router.onBeforeAction(requireLogin, {only: 'postSubmit'});
~~~
<%= caption "lib/router.js" %>
<%= highlight "14~17" %>

### Post 수정 템플릿

이제 템플릿에 초점을 맞춘다. `postEdit` 템플릿은 비교적 표준적인 폼이다:

~~~html
<template name="postEdit">
  <form class="main">
    <div class="control-group">
        <label class="control-label" for="url">URL</label>
        <div class="controls">
            <input name="url" type="text" value="{{url}}" placeholder="Your URL"/>
        </div>
    </div>

    <div class="control-group">
        <label class="control-label" for="title">Title</label>
        <div class="controls">
            <input name="title" type="text" value="{{title}}" placeholder="Name your post"/>
        </div>
    </div>

    <div class="control-group">
        <div class="controls">
            <input type="submit" value="Submit" class="btn btn-primary submit"/>
        </div>
    </div>
    <hr/>
    <div class="control-group">
        <div class="controls">
            <a class="btn btn-danger delete" href="#">Delete post</a>
        </div>
    </div>
  </form>
</template>
~~~
<%= caption "client/views/posts/post_edit.html" %>

그리고 `post_edit.js` 매니저는 다음과 같다:

~~~js
Template.postEdit.events({
  'submit form': function(e) {
    e.preventDefault();
    
    var currentPostId = this._id;
    
    var postProperties = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    }
    
    Posts.update(currentPostId, {$set: postProperties}, function(error) {
      if (error) {
        // display the error to the user
        alert(error.reason);
      } else {
        Router.go('postPage', {_id: currentPostId});
      }
    });
  },
  
  'click .delete': function(e) {
    e.preventDefault();
    
    if (confirm("Delete this post?")) {
      var currentPostId = this._id;
      Posts.remove(currentPostId);
      Router.go('postsList');
    }
  }
});
~~~
<%= caption "client/views/posts/post_edit.js" %>

지금까지 대부분의 코드는 익숙하다. 첫째, 템플릿 헬퍼는 현재의 post를 가져와서 이를 템플릿으로 전달한다.

그리고 두 개의 템플릿 이벤트 콜백이 있다: 하나는 폼의 submit 이벤트를 처리하는 것이고, 다른 하나는 삭제 링크의 click 이벤트를 처리하는 것이다.

삭제 콜백은 정말 간단하다: 초기설정의 클릭 이벤트를 중지시키고, 삭제여부를 다시 확인한다. 확인을 하면, 템플릿의 데이터 컨텍스트에서 현재 post의 ID를 얻어서, 해당 post를 삭제한 다음, 사용자를 홈페이지로 리다이렉트 처리한다.

수정 콜백은 약간 더 길지만, 훨씬 복잡한 정도는 아니다. 초기설정 이벤트를 중지시킨 다음 현재 post를 얻은 후, 페이지에서 새로운 폼 필드값을 얻어 이를 `postProperties` 객체에 저장한다.

그리고는, 이 객체를 미티어의 `Collection.update()` Method로 전달한다. 그리고 수정이 실패하면 오류를 보여주는 콜백을 사용하고, 수정이 성공하면 post페이지를 다시 사용자에게 보여준다.

### 링크 추가

또한 post에 링크를 추가하여 사용자가 post 수정 페이지로 접근할 수 있는 방법을 제공한다:

~~~html
<template name="postItem">
  <div class="post">
    <div class="post-content">
      <h3><a href="{{url}}">{{title}}</a><span>{{domain}}</span></h3>
      <p>
        submitted by {{author}}
        {{#if ownPost}}<a href="{{pathFor 'postEdit'}}">Edit</a>{{/if}}
      </p>
    </div>
    <a href="{{pathFor 'postPage'}}" class="discuss btn">Discuss</a>
  </div>
</template>
~~~
<%= caption "client/views/posts/post_item.html" %>
<%= highlight "5~8" %>

물론, 다른 사용자의 수정 폼으로의 링크를 보여주길 원하지는 않는다. 이것이 `ownPost` 헬퍼가 필요한 이유다:

~~~js
Template.postItem.helpers({
  ownPost: function() {
    return this.userId === Meteor.userId();
  },
  domain: function() {
    var a = document.createElement('a');
    a.href = this.url;
    return a.hostname;
  }
});
~~~
<%= caption "client/views/posts/post_item.js" %>
<%= highlight "2~4" %>

<%= screenshot "8-1", "Post 수정폼." %>

<%= commit "8-1", "Post 수정폼을 추가했다." %>

수정 폼은 좋아 보이지만, 실제로는 지금 바로 무엇을 수정할 수는 없을 것이다. 무엇이 문제인가?

### 권한 설정

앞서 `insecure` 패키지를 제거하였기 때문에, 모든 클라이언트 쪽에서의 수정은 현재 거부되고 있다.

이를 고치기 위해서, 몇 가지의 권한 규정을 설정한다. 첫째, 새로운 `permissions.js` 파일을 `lib` 디렉토리에 만든다. 이 파일은 권한제어 로직을 먼저 구동한다(그리고 양쪽에서 이용할 수 있다):

~~~js
// check that the userId specified owns the documents
ownsDocument = function(userId, doc) {
  return doc && doc.userId === userId;
}
~~~
<%= caption "lib/permissions.js" %>

[Post 등록하기](/chapters/creating-posts)장에서, 우리는 새 post의 등록을 서버 (`allow()`를 지나치는) 메서드를 통해서만 등록을 하고 있었기 때문에 `allow()` 메서드를 제거했다.

그러나, 지금은 클라이언트로부터 post를 수정하고 삭제하려고 한다. 그러므로 `posts.js`에 `allow()` 블럭을 추가한다:

~~~js
Posts = new Meteor.Collection('posts');

Posts.allow({
  update: ownsDocument,
  remove: ownsDocument
});

Meteor.methods({
  ...
~~~
<%= caption "collections/posts.js" %>
<%= highlight "3~6" %>

<%= commit "8-2", "Post의 소유자를 검사하는 기본적인 접근권한 제어 기능을 추가했다." %>

### 수정 범위의 제한

단지 post를 수정할 수 있다고 해서, *모든* 속성을 수정할 수 있다는 의미는 아니다. 예를 들면, 사용자들에게 post 등록권한을 부여하지 않고, 등록한 post를 다른 사람에게 배정한다.

우리는 미티어의 `deny()` 콜백을 이용하여 사용자들이 특정한 필드만을 수정할 수 있게 한다:

~~~js
Posts = new Meteor.Collection('posts');

Posts.allow({
  update: ownsDocument,
  remove: ownsDocument
});

Posts.deny({
  update: function(userId, post, fieldNames) {
    // may only edit the following two fields:
    return (_.without(fieldNames, 'url', 'title').length > 0);
  }
});
~~~
<%= caption "collections/posts.js" %>
<%= highlight "8~13" %>

<%= commit "8-3", "Post의 특정 필드만 수정할 수 있게 허용한다." %>

`fieldNames` 배열은 수정될 필드 목록을 담고 있다. 그리고  [Underscore](http://underscorejs.org/)의 `without()` 메서드를 사용하여 `url`이나 `title`이 *아닌* 필드들을 담은 부분 배열을 리턴한다.

모두 정상이면, 그 배열은 비어있어야 하고, 길이는 0이어야 한다. 누군가 고약한 시도를 한다면, 그 배열의 길이는 1보다 클 것이고, 콜백은 `true`를 리턴한다(따라서 수정이 거부된다).

<% note do %>

### 메서드 호출 대 클라이언트에서의 데이터 가공

Post를 등록하기 위해서, 우리는 `post` 메서드를 사용하는 반면에, 이를 삭제하기 위해서는 `update`와 `remove`를 클라이언트에서 직접 호출하며 `allow`와 `deny`를 통해서 접근을 제어한다.

이런 방식이 언제 적절하고 어느 때 부적절할까?

일이 상대적으로 수월하고 규칙을 `allow`와 `deny`로 충분히 표현할 수 있다면, 클라이언트에서 직접 처리하는 것이 더 간단하다.

클라이언트에서 데이터베이스를 직접 조작하는 것은 즉시 인지할 수 있으며, (서버가 요청 처리를 실패했다고 리턴할 때) 실패 처리를 매끄럽게 한다는 것을 명심한다면 더 나은 사용자 경험을 구현할 수 있다.

그런데, 사용자의 권한을 넘는 작업(새로운 post의 등록일시를 저장하거나, 올바른 사용자에게 배정하는 것 같은)의 필요성을 느끼기 시작하는 순간, 메서드를 사용하는 것이 더 바람직하다.


메서드 호출은 다음의 몇 가지 시나리오에서 더 적합하다:

- 반응성과 동기화가 전파되는 것을 기다리기 보다는 콜백을 통해 값을 리턴하거나 알아야 할 필요가 있는 경우.
- 대형의 컬렉션을 전송하기에는 너무 부담되는 무거운 데이터베이스 함수의 경우.
- 데이터를 요약하거나 모으기 위한 경우(예, 수량, 평균, 합계 등).

<% end %>