Posty oznaczone etykietą angularjs

Angular w listopadowy wieczór

Nie mam słów i jestem zażenowany poziomem tzw. webdeveloperów portujących pluginy pod Angulara. Zdecydowana większość tego syfu to wrappery na ścierwo pisane pod jQuery. Tak, ścierwo, bo ta biblioteka sama w sobie jest jak lep na muchy, który przez swoją tandetną prostotę przyciąga tabuny amatorów przykładających swoje uszczerbione i ufajdane cegiełki do dziurawej budowli wznoszonej od lat przez nadęte i oderwane od rzeczywistości community open source. I mimo, że są perły pod jQuery, to tworząc soft pod Angulara używanie jQuery jest nadmiarem, naroślą, wrzodem na dupie i opuchlizną dręczącą i tak nie najlżejszy framework.

Jedyny sens jest portować tak, aby nie miały zależności od jQuery czy innych wynalazków tworzonych jako dodatek do HTML-a. Dlatego ciśną mi się na klawiaturę słowa: ludzie, przestańcie do cholery robić syf - albo robicie coś porządnie, albo nie róbcie tego wcale. Później mamy taki sektor IT, jaki sobie tworzymy. Poczytajta też Stack Overflow w tym temacie.

Czołem.

Django handler500, request.is_ajax() i AngularJS

Kolejny wypadek Django przy pracy, który powinien przekonać niedowiarków i wyznawców Django, że ten framework nadaje się do stawiania blogasków, ale niespecjalnie jako server side dla aplikacji.

handler500 i DEBUG=True

Przy włączonym DEBUG handlery 403,404 i 500 nie są używane. Do akcji wkraczają tzw. technical responses, które generują specjalny output dla poszczególnych błędów. Z reguły są one bardzo przydatne, ale pisząc server pod klienta w AngularJS w response otrzymujemy... piękny html ze stylami i css. Przeczytanie błędu graniczy z cudem, a zdevelopowanie poprawnej obsługi błędu w kliencie jest niemożliwe w trybie DEBUG. Niemożliwe, bo nie da się podmienić technical responses. Są one wołane w core handlerze, więc nie ma na to szans.

Możemy w konfiguracji podmienić exception filter, ale on jest używany przez exeption reporter a to na jego wymianie lub rozszerzeniu nam zależy, jeśli chcemy cokolwiek sensownego zrobić z obsługą błędów 403,404,500 w trybie DEBUG!

AngularJS i request.is_ajax()

Implementacja is_ajax() opiera się na jakiejś konwencji. Po pierwsze - skoro to konwencja, to powinno dać się ją zmienić na potrzeby projektu. Oczywiście nie da się, podobnie jak nie da się prosto wymienić klasy HttpRequest, w której podmieniłbym is_ajax (trzeba grzebać low-level na poziomie handlerów wsgi). Monkey patching mnie nie interesuje - readability counts.

Natomiast można skonfigurować AngularJS do współpracy ze zmaszczonym niespecjalnie rozsądnymi rozwiązaniami Django, wystarczy skonfigurować nagłówek:

angular.module('myApp').config(function($httpProvider) {
    $httpProvider.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
});

A co zrobili Django developers?

Ano dodali kiedyś takiego paszkwila w odpowiedzi na zgłoszenie:

if request.is_ajax():
    text = reporter.get_traceback_text()
    return HttpResponseServerError(text, content_type='text/plain')

Świetnie, ale to nie rozwiązuje problemu, bo:

  • HTTP_ACCEPT mam application/json i chcę mieć w response JSON z błędem (!!!)
  • niewiadomo jaki tekstowy response jest słabo parsowalny przez jakąkolwiek implementację JSON-a

Django developers są szczęśliwi i dumni ze swojego podejścia znanego jako "Django ethos". Sukcesów życzę i omijania Django w dużych projektach.

Django CSRF + AngularJS

Zapisuję w formie notatki, aby nikogo (w tym mnie) nie kusiło użycie csrf_exempt ;)

Dodanie obsługi CSRF w AngularJS 1.1.5+ polega na skonfigurowaniu nazw nagłówka i cookie:

.config(function($httpProvider) {
    $httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';
    $httpProvider.defaults.xsrfCookieName = 'csrftoken';
})