- 5주차 배운점 목차
[이번주 배운점]
팀 프로젝트를 하며 장고에 대해 배운 포인트들을 적어보겠다.
<model 작성시>
- 모델 속성인 blank=True, null=True는 짝꿍처럼 쓰인다.
blank는 빈칸으로 입력을 허용한다는 뜻이다.
그러니 null이 입력될 가능성이 생기고 null=True를 줘야하는 것이다.
이게 없을경우 이번주에 자주 봤던 NOT NULL 규칙 위반이 된다.
null을 대신 하는 방법이 하나 있다.
default 값을 주는 것이다.
default는 빈칸 입력이거나 입력이 없을 경우 기본으로 주는 값이 된다.
deault를 주었을 경우 null=True는 없어도 된다. (완벽히 대체하기 때문이다.)
<admin 페이지에 리스트 모양 정하기>
class UserModelAdmin(admin.ModelAdmin):
list_display = ('id', 'username', 'bio')
admin.site.register(UserModel, UserModelAdmin)admin.py에 이런 식으로 작성하여,
admin페이지에서 모델을 조회할때,
리스팅 될 항목을 정할수 있다.
list_display_link를 이용해 링크가 동작할 필드들을 정할수도 있다.
(기본적으로는 id만 링크가 동작한다.)
(사진같은 경우 클릭하면 해당 사진 url로 이동하며 사진을 볼수있다.)
list_filter를 주면 모델 조회페이지 오른쪽 편에 필터창이 생긴다.
이걸 이용해 원하는 정보만 필터링해서 볼수있다.
(링크와 필터옵션은 트윗에만 적용했다. 트윗이 정보량이 많기 때문이다.)
<view 작성없이 로그인/로그아웃>
기본 로그인/로그아웃을 쓸때는 view또한 기본을 쓸수있다.
이럴 경우 view의 작성이 아예 필요 없다.
즉, 이미 만들어진 view가 있다.
urls.py에서 이렇게 작성해주면 된다.
from django.contrib.auth import views as auth_views
from . import views
path('login/', auth_views.LoginView.as_view(template_name='user/login.html'), name='login'),
path('logout/', auth_views.LogoutView.as_view(), name='logout'),장고.contrib.auth가 제공하는 views가 있고,
거기에 LoginView와 LogoutView가 있다.
흥미로우면서 꼭 기억해야할 두가지 포인트는,
모듈을 임포트할때 그냥 views로 하면 우리가 작성한 views와 이름이 충돌한다.
views를 완전히 대체할게 아니라면(우리의 작성내용이 있다면)
임포트뒤에 as를 붙여서 불러오는 이름을 바꿔줘야한다.
아래에 보면 바꿔준 이름으로 기능을 동작해준다.
또 로그인의 경우 우리가 만든 페이지로 이동하게 하려면,
template_name='템플릿 위치' 속성을 줘야한다.
그래야 우리가 만든 html을 불러와 로그인 동작을 해준다.
창을 보여주고 로그인 입력시 동작까지 해주니 꽤 스마트한 동작이다.
(template_name속성을 주지 않을시 기본 제공 페이지가 열린다.)
<context 변수명이 일관성을 가져야 하는 이유>
template html마다 DTL로 가져오는 인스턴스를 부르는 이름이 여러개라면 헷갈릴것이다.
(같은 인스턴스일 경우 말이다.)
가져오는 게 같은 인스턴스 일경우 view 기능별로 다른이름을 쓰지 않도록 유의하자.
같은 인스턴스는 view나 페이지가 달라도 같은 이름을 쓴다면,
페이지를 편집할때 헷갈리지 않을 것이다.
def show_tweet(request):
all_tweet = TweetModel.objects.all().order_by('-created_at')
return render(request, 'tweet/home.html', {'all_tweet': all_tweet})
def detail_tweet(request, detail_id):
detail_tweet = TweetModel.objects.filter(id=detail_id).first()
tweet_comment = CommentModel.objects.filter(
tweet_id=detail_id).order_by('-created_at')
return render(request, 'tweet/detail_tweet.html', {'detail': detail_tweet, 'comment': tweet_comment})
def my_page(request, user_id):
user = UserModel.objects.get(id=user_id)
my_page = user.tweet.all().order_by('-created_at')
return render(request, 'tweet/my_page.html', {'my_tweet': my_page, 'my_page_user': user})위처럼 트윗이란 인스턴스를,
담는 변수이름은 다른게 view를 작성할때는 유리할것이다.
하지만 DTL에 실어주는 이름은 tweet으로 통일되어 있다면,
template을 작성할 때는 더 좋을 것같다.
추가적으로,
인스턴스 덩어리를 보낼 경우는 tweets 같은 복수형을 쓰고,
DTL로 for tweet in tweets로 쓴다면,
for문 안에서도 tweet이란 이름으로 통일되니 좋은 기법이 될것 같다.
다음 프로젝트 부터는 이렇게 이름을 정해둬야 겠다.
<여러가지 미리 정해둘것들>
- 브랜치 작명규칙.
브랜치 작명규칙은 마침 배웠었기에, 사전에 정해봤으나 잘 지키지 못했다.
- 파이썬과 html 포맷터.
포맷터는 정할생각을 못했다.
파이썬은 다들 autopep8을 사용하셔서 문제가 되지 않았으나,
html포맷이 문제였다.
파이참과 vscode의 기본 html포맷이 틀려서 들여쓰기, 줄맞춤이 달랐다.
심지어 허용하는 코드작성법도 틀리다.
그래서 html파일의 경우 머지하실 때 변경사항이 실제 변경내용보다 더 많이 잡혔다.
줄맟춤이 바뀐 부분 등이 다 변경으로 잡힌 것이다.
실제 뭐가 바뀐건지 알아보기 어려운 요소가 되었다.
- 더 좋은것은 커밋, 풀리퀘스트를 할때
작업자가, 내 변경사항들만 커밋에 포함되었는지 직접 검토를 하고 커밋을 하는 것이다.
그렇지 않았을 경우 풀리퀘스트를 보낼때도 한번더 검토하게 되어있다.
이때라도 되돌리면 되겠다.
pull리퀘스트를 받았을때라도, 불필요한 변경내용이 많다면 pull리퀘스트를 기각하면 된다.
- 이런 깃 협업에 대해서도 규칙을 정하는게 좋겠다.
이번에는 직접 하면서 배우는 경험이였다고 생각해야겠다.
나도 몇차례 풀리퀘스트를 드리며 실수를 했다.
(이번주 배운점에도 적었었다)
- 병합을 어디서 할건지도 고민스럽다.
각 작업자가 최신 커밋과 자기의 작업내용을 병합한뒤 pr을 할것인지,
main브랜치 담당자가 각자 밀어준 pr을 병합하며 충돌을 해결할 것인지다.
이번엔 하다보니 전자의 방법을 하게 되었다.
작업내용 대해서는 작업자가 잘 알다보니 자연스레 그렇게 하게 된것이다.
원래라면 main담당자가 병합을 하는게 맞는 것일까?
게다가 짧은 시간안에 동시다발적으로 코딩과 병합을,
진행을 하다보니 그런것 같기도 하다.
결론, 팀원분들 모두 열심히 해주셔서,
프로젝트를 빠르게 끝낼 수 있었다.
수월하고 여유롭게 마친것 같아 기쁘다.
단순히 빠르게 끝낸게 아니라 배운 내용의 적용과 응용도 많았고,
새로운 기능도 여러가지 들어가 있어서 좋다.
(프로젝트 시연영상을 찍었는데 찍고나니 꽤 재밌다.)