Post 수정

8

번역 완료율

이 장에서는:

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

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

    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'});
    
    lib/router.js

    Post 수정 템플릿

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

    <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>
    
    client/views/posts/post_edit.html

    그리고 post_edit.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');
        }
      }
    });
    
    client/views/posts/post_edit.js

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

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

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

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

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

    링크 추가

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

    <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>
    
    client/views/posts/post_item.html

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

    Template.postItem.helpers({
      ownPost: function() {
        return this.userId === Meteor.userId();
      },
      domain: function() {
        var a = document.createElement('a');
        a.href = this.url;
        return a.hostname;
      }
    });
    
    client/views/posts/post_item.js
    Post 수정폼.
    Post 수정폼.

    Commit 8-1

    Post 수정폼을 추가했다.

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

    권한 설정

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

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

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

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

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

    Posts = new Meteor.Collection('posts');
    
    Posts.allow({
      update: ownsDocument,
      remove: ownsDocument
    });
    
    Meteor.methods({
      ...
    
    collections/posts.js

    Commit 8-2

    Post의 소유자를 검사하는 기본적인 접근권한 제어 기능을 추가했다.

    수정 범위의 제한

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

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

    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);
      }
    });
    
    collections/posts.js

    Commit 8-3

    Post의 특정 필드만 수정할 수 있게 허용한다.

    fieldNames 배열은 수정될 필드 목록을 담고 있다. 그리고 Underscorewithout() 메서드를 사용하여 url이나 title아닌 필드들을 담은 부분 배열을 리턴한다.

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

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

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

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

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

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

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

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

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