Temat: Python + AngularJS w miejsce Django
Hm... jakby to powiedzieć... zawsze system pisany od zera jest bardziej seksowny. Problem w tym, że bardzo często się potem okazuje, że przepisywanie to jednak była ślepa uliczka, bo nowa wersja wprowadzi masę błędów i inne działanie, które może frustrować użytkowników. No ale to jest decyzja biznesowa. Z drugiej strony przepisywanie Netscape'a to też była decyzja biznesowa.
Problemów z zarządzaniem modelem z poziomu Django nie rozumiem, nigdy nie miałem z tym problemu, chociaż modele potrafiły być zakręcone i, niestety, z cyklicznymi zależnościami.
Problemu z widokami też nie rozumiem. Stawiam na to, że albo ktoś nie wiedział jak zaimplementować to poprawnie, albo są jakieś okrutnie ciężkie warunki brzegowe, które nagle zaatakowały i nie da się ich obejść.
Tak czy siak rozumiem, że przepisanie aplikacji oznacza też zrobienie całkiem nowego modelu, który nie będzie miał błędów obecnego. To zawsze jest plus nowej implementacji.
A co do django + angular. Od ponad roku grzebię w tym i jak do tej pory zrobiłem, albo też brałem udział w zrobieniu, kilka totalnie zakręconych stron, których zawartość się zmienia dynamicznie zależnie od zmian na kilku innych komputerach.
Jedyny problem jaki był, to kwestia szablonów djangowych i integracja ich z angularem. Problem jest taki, że zrobiłem to źle. Starsza wersja Django do umieszczenia zawartości zmiennej w szablonie używa
{{ var }}. Angular tak samo. Problem się pojawił, jak użytkownik wchodzi na stronę, generowany jest html, częściowo ze zmiennymi z django, częściowo ze zmiennymi z angulara. Rozwiązanie jest proste: można zmienić w django, albo angularze, {{ na coś innego. W moim przypadku było za późno zanim to znalazłem i zamiast tego mam pełno kodu w stylu
{% verbatim %}{{angular_variable}} {% endverbatim %} {{ django_variable }}. Nowsza wersja Django pozwala na używanie innych szablonów, jak np. jinja, może to ułatwi życie, nie wiem.
Co do komunikacji, to z jednej strony mamy normalny szablon djangowy, który generuje htmla, który ładuje pliki z javascriptem. Potem mamy kod a angularze, który wysyła requesty do tej samej aplikacji djangowej i gada sobie z nią jsonem (w obie strony, wysyłany jest json, odbierany jest json, albo też tradycyjnie: wysyłany jest request GET i odbierany jest json). Mamy też otwarty websocket, który pozwala na to, że inna aplikacja (tak wyszło że inna i do tego napisana w pants, równie może być to ta sama aplikacja djangowa) może wysyłać do tej aplikacji angularowej informacje na temat tego co się dzieje i aplikacja może coś innego pokazać.
Angular jest świetny, bo pozwala na ładne ułożenie kodu, kod jest krótki i czysty. Problem z Angularem jest taki, że można łatwo zrobić taki bałagan, że potem wszelkie poprawki to koszmar.
No i jest świetny, bo wystarczy zmienić zmienną w javascripcie, a na stronie wszystko się automagicznie aktualizuje.
To co potrzebujecie do przepisania tej aplikacji, to przede wszystkim ktoś, kto zna Angulara. Nie może to być ktoś, kto dopiero się go uczy, bo będzie bałagan i za rok znowu będzie trzeba wszystko przepisywać. Angular ma niski próg wejścia, bierzemy sobie jeden plik, robimy jeden kontroler i jazda. Jak aplikacja jest bardziej skomplikowana, to trzeba użyć serwisów i dyrektyw, a to już jest o wiele bardziej problematyczne.
Jak dla mnie to taki system musi być jak Ogr. Znaczy się musi mieć warstwy. Musi być angular + html + css. Musi to gadać z dobrze zdefiniowanym API przez http (najlepiej jak angular będzie dostawał jsona, to ułatwia życie). Po drugiej stronie http wtedy może być cokolwiek. Nawet django. A pod tym czymś, dobrze zdefiniowany model w bazie.
Jak architekt narzeka na zarządzanie modelem, to może model jest do dupy, a nie samo Django. Czy model się drastycznie zmieni jak interfejs będzie w angularze? Dlaczego? To może zmienić go już teraz?
Czysto pythonowy kod nie ma nic do rzeczy jeśli chodzi o angulara. Wystarczy, że wyśle mu jsona z odpowiednim nagłówkiem, co jest dość ważne, bo wtedy automagicznie w angularze całość będzie obiektem javascriptowym.
Teraz będę pewnie robił (albo tez ktoś inny) te moje stare systemy angularowe od zera. Będzie też django. Będzie też angular i jquery. Komunikacja będzie przez websocket i requesty http gadające jsonami. Angular nie powinien w ogóle rozumieć modelu danych, który jest w bazie, zamiast tego powinien mieć własny model, który będzie wyświetlany na stronie. I dzięki takiemu rozdzieleniu warstw, będzie można zmieniać potem model danych w bazie, a angular może tego nawet nie zauważyć.
пропозиції роботи
